Нечеткий, поиск по шаблону с несколькими терминами: Перенос всех данных в одно свойство?

Question

В настоящее время я внедряю Elasticsearch в качестве интерфейса поиска в существующее приложение. Приложение представляет собой классическое 3-уровневое приложение с базой данных Oracle.

Я имею в Entity 'Человек' (таблица базы данных), со следующими признаками:

• первое имя
• Фамилия
• полное имя (содержит первое имя и фамилия сцеплены)
• человек-Nr.
• название компании
• Список адресов: улица, почтовый индекс, город, телефон и электронная почта.

До сих пор я помещал это 1: 1 в elasticsearch, для каждого db-столбца свойство в elasticsearch. Синхронизация и полная загрузка данных без проблем. Но я изо всех сил обеспечивая «хороший» опыт поиска, так как есть много различных вещей, чтобы обратить внимание на:

• нечеткого поиска (допуска одного или двух редактирования расстояния)
• поиска по шаблону (если я печатаю «Анж», он также должен найти результаты с «Angelina»)
• поиск E-Mail-адресов (я уже использую uax_url_email Tokenizer в сочетании с keyword типа данных)

насколько я могу сказать , multi_match, тип cross_fields - d, но он не может выполнять нечеткий поиск и подстановочный знак. тип best_fields также не является вариантом, потому что он не может выполнять групповой поиск (насколько я знаю?). most_fields также не подходит и phrase matching не может сделать нечеткость.

Из-за этого, я в настоящее время с помощью simple_query_string, например:

В поле поиска, я вхожу Tom fisher: Запрос в simple_query_string является:

(tom* | tom~1)+(fisher* | fisher~1) 

Мой вопрос теперь, будет это плохая идея, просто иметь на поле «entity_content», который содержит содержимое всех полей? Это было бы похоже на то, что у меня был .txt-документ со всей информацией о человеке.

• Каковы преимущества/недостатки?

Answer 1

По умолчанию Elastic имеет поле _all, которое уже является полем catch-all, например. вся информация хранится в этом поле, независимо от того, откуда оно взялось.

Поле _all может быть полезно, особенно при изучении новых данных с использованием простой фильтрации. Однако, объединяя значения полей в одну большую строку , поле _all теряет различие между короткими полями (более релевантными) и длинными полями (менее релевантными).Для случаев использования, где важно релевантность поиска, важно запросить отдельные поля конкретно.

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