полнотекстовый поиск в базах данных

Question

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

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

Другой вопрос, который у меня есть, если у меня есть id, например abc/123.64664, который хранится в виде строки, есть ли преимущество в поиске такого столбца с FTS? Мне кажется, что индексирование не так много получается? Или я ошибаюсь? thanks

Answer 1

Elasticsearch может хранить индексированный документ, и вы можете получить его как часть результата запроса. Обычно ppl сохраняет исходные данные в обычном БД, это дает вам большую надежность и гибкость при переиндексации. Имейте в виду, что ES индексирует нереляционные данные. Вы можете иметь данные, хранящиеся в реляционном порядке, и создавать денормализованные документы для индексирования.

Что касается «а/123.64664» вы можете указательные как лексемы строки или вы можете настроить индекс для поиска префикса и т.д. Это до вас

Answer 2

(TL; DR) Не думайте о том, что ваши данные структурированы в вашем RDBS. Подумайте о том, что вы есть поиск.

---

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

Все это связано с ожидаемыми результатами поиска . Вы можете увеличить детализацию данных или - напротив - денормализовать его, чтобы родительский/связанный с ним контент записи отображался в записях, которые вы действительно хотите вернуть как часть поиска. Текстовая обработка (copyField, токенизация, предварительная обработка и т. Д.) Также там, где происходит множество модификаций контента, чтобы сделать запись доступной.

Иногда реляционные базы данных поддерживают полнотекстовый поиск. PostgreSQL становится все лучше и лучше. Но большую часть времени реляционные базы данных просто не обеспечивают достаточной гибкости для поддержки хорошего поиска, ориентированного на релевантность.

И, наконец, если исходная схема довольно сложна, имеет смысл использовать только поисковую систему, чтобы получить идентификаторы, соответствующие правому значению, а затем объединить их в код клиента с данными из исходных записей базы данных.