Подстановочный запрос CloudSearch не работает с API 2013 после перехода с API 2011
Я недавно обновил экземпляр CloudSearch с 2011 года до API 2013 года. Оба экземпляра имеют поле с именем sid, которое представляет собой текстовое поле, содержащее двухбуквенный код, за которым следуют несколько цифр, например LC12345. С API 2011, если я запускаю поиск следующим образом:
q=12345*&return-fields=sid,name,desc
... я получаю 1 результат, и это здорово. Но результат результата LC12345 и так оно и было проиндексировано. Число 12345 больше нигде не отображается ни в одном из полей документа. Я не понимаю, почему это работает. Я могу только предположить, что этот тип запроса ищет любые термины в любых полях, которые даже содержат число 12345.
Причина, по которой я спрашиваю, заключается в том, что эта функция теперь нарушена, когда я выполняю запрос с использованием API 2013 Мне нужно использовать синтаксический анализатор структурированных запросов, но даже сопоставимый шаблонный запрос с использованием простого синтаксического анализатора не работает, например
q.parser=simple&q=12345*&return=sid,name,desc
... ничего не возвращает, хотя документ определенно есть, т.е. если я запрашиваю LC12345* он находит документ.
Если бы я мог понять, как заставить работать простой запрос, как это было раньше, это, по крайней мере, помогло бы мне начать делать то же самое со структурированным синтаксисом.
1 ответ
Почему не работает
CloudSearch v1 (2011) имел другой способ токенизации смешанных буквенно-цифровых строк. Вот логика, описанная в заархивированных документах (выделено мной).
Если строка содержит как буквенные, так и числовые символы и имеет длину не менее трех и не более девяти символов, буквенные и числовые части строки обрабатываются как отдельные токены. Например, строка DOC298 разбита на два термина: doc 298
Обработка текста в CloudSearch v2 (2013) следует текстовой сегментации Unicode, которая не определяет такое поведение:
Не разбивайте последовательности цифр или цифр рядом с буквами ("3a" или "A3").
Решение
Вы должны просто иметь возможность искать *12345 чтобы получить результаты с любым префиксом. Могут быть некоторые крайние случаи, такие как получение нежелательных результатов (вещи с более предыдущими цифрами, например, AB99912345); Я не знаю достаточно о ваших данных, чтобы сказать, являются ли это реальными проблемами.
Другой вариант - индексировать числовой префикс отдельно от алфавитного суффикса, но это дополнительная работа, которая может быть ненужной.
Я предполагаю, что вы используете Cloudsearch на английском языке, так что, возможно, это не ваша конкретная проблема, но также следите за стоп-словами в ваших поисковых запросах:
https://docs.aws.amazon.com/cloudsearch/latest/developerguide/configuring-analysis-schemes.html
В вашем примере слово "jo" является стоп-словом на датском и других языках, и, конечно же, поддерживаемые языки имеют словарь стоп-слов, в котором есть очень распространенные. Если вы не укажете язык в текстовом поле, это будет английский. Вы можете увидеть их здесь: https://docs.aws.amazon.com/cloudsearch/latest/developerguide/text-processing.html.