Практичный для использования фрагментов в качестве поискового запроса?

Question

Я пытаюсь реализовать тип-вперед в своем приложении, и у меня есть поиск, предлагающий работать с индексом диапазона элементов, как это рекомендовано в документации. Проблема в том, что она не подходит для моего использования.

Как никто, кто его использовал, знает, что он не вернет результаты, если строка поиска не находится в начале поиска содержимого. Запрет на использование ведущего и конечного шаблона не приведет к возврату того, что мне нужно.

Я думал вместо простого выполнения поиска, основанного на термине, а затем возвращал фрагменты результатов (усеченные в моем серверном коде) как предложения в моем типе вперед.

Поскольку у меня нет хорошего способа сравнения производительности, я надеялся на некоторое понимание того, будет ли это практичным, или если это будет слишком медленно.

Кроме того, поскольку он может возникнуть в ответах, да, я прочитал сообщение о «фрагментированных индексах диапазона элементов», но, будучи новым для MarkLogic, я не могу сделать головы или хвосты и не был способный адаптировать его к моему приложению.

Answer 1

Я написал сообщение блога Chunked Element Range Indexs и узнал в последнюю минуту, что мои показатели производительности были искажены удивительно большим документом в моем индексе. Когда я удалил этот большой документ, многие другие методы, такие как подстановочный знак, неожиданно стали намного быстрее. Это меня удивило, потому что все другие поисковые системы, которые я использовал, не могли предложить такую ​​быструю производительность и гибкость для сценариев с опережающим сценарием, особенно если я попытался ввести поиск по wild-card. Я решил не публично публиковать свой пост, но кто-то случайно сделал это для меня, поэтому мы решили оставить его там, так как он по-прежнему представляет действительный вариант.

Поскольку MarkLogic предлагает несколько подстановочных индексов, в этой области вы действительно можете многое сделать. Тем не менее, поисковые фрагменты не будут правильным способом сделать это, поскольку я считаю, что они добавили некоторые накладные расходы. Вызовите cts: поиск или один из других вызовов cts для соответствия лексике. Я предполагаю, что вы хотите cts: element-value-match. Это делает подстановочные знаки против индекса диапазона, так как все они в памяти, поэтому быстрее. Включите все ваши подстановочные индексы на свой дБ, если сможете.

Его следует вызывать из пользовательского сценария XQuery на HTTP-сервере MarkLogic. Я не рекомендую расширение REST, как обычно, потому что вам нужно быть как можно более ровным, чтобы выполнить большинство сценариев с приоритетом типа (то есть достаточно быстро).

Я предлагаю вам найти способы уменьшить набор значений в индексе диапазона до менее чем 100 000, чтобы было меньше, чем нужно, и вы не допускаете никаких нежелательных предложений. Кроме того, убедитесь, что вы отфильтровываете набор совпадений на основе остальной части запроса (если пользователь уже начал вводить другие слова или фразы). Убедитесь, что ваш HTTP-скрипт ограничивает количество предложений, возвращенных, поскольку пользователь обычно не может извлечь выгоду из длинного списка предложений. И создайте некоторые алгоритмы, чтобы ранжировать предложения, поэтому самые полезные из них выходят на вершину.Наконец, будьте очень, очень осторожны, чтобы не предлагать предложения, которые более отвлекают, чем полезно. Если вы собираетесь вводить своих пользователей в режим «впереди», это прервет их поиск и тренировку мысли, поэтому не прерывайте их, если вы собираетесь предлагать поисковые фразы, которые не помогут им получить то, что они хотят , Я видел это слишком часто, даже на крупных сайтах. Не делайте ввода вперед, если вы не хотите измерять использование этой функции и настраивать ее со временем или удалять, если это отвлекает пользователей.

Надеюсь, что это поможет!

Answer 2

Вы упомянули, что вы используете индекс диапазона, чтобы заполнить ваши предложения, но вы также можете использовать слова lexicons. Слова лексиконов будут давать предложения, основанные на токенизированных символьных данных, а не целые значения элементов (или json-свойств). Возможно, стоит посмотреть на это.

В качестве альтернативы, поскольку вы указываете подстановочные знаки, возможно, вас интересует cts:value-match. Он работает с значениями (а не словами) из индексов диапазона, но в качестве входных данных принимает выражение с дикой картой. Он будет работать намного лучше, чем подход с фрагментами, который должен будет поднять и обработать фактическое содержимое.

HTH!