Что такое полнотекстовый поиск vs LIKE

Я только что прочитал сообщение с упоминанием "полнотекстового поиска" в SQL.

Мне просто интересно, в чем разница между FTS и LIKE. Я прочитал пару статей, но не смог найти ничего, что объяснило бы это хорошо.

103
full-text-search sql sql-like

6 ответов

В общем, существует компромисс между "точностью" и "вспомнить все". Высокая точность означает, что представлено меньше нерелевантных результатов (без ложных срабатываний), в то время как высокая точность означает, что отсутствует меньше релевантных результатов (без ложных срабатываний). Использование оператора LIKE дает вам 100% точность без каких-либо уступок для отзыва. Средство полнотекстового поиска дает вам большую гибкость для настройки точности для лучшего запоминания.

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

оператор SQL LIKE может быть крайне неэффективным. Если вы примените его к неиндексированному столбцу, полное сканирование будет использоваться для поиска совпадений (просто как и любой запрос в неиндексированном поле). Если столбец индексируется, сопоставление может выполняться с ключами индекса, но с гораздо меньшей эффективностью, чем большинство поисков индекса. В худшем случае подобный шаблон будет иметь ведущие подстановочные знаки, которые требуют изучения каждого ключа индекса. Напротив, многие системы поиска информации могут обеспечить поддержку ведущих подстановочных знаков путем предварительной компиляции деревьев суффиксов в выбранных полях.

другие функции, типичные для полнотекстового поиска

  • лексический анализ или разметки-нарушение блок неструктурированного текста в отдельные слова, фразы и специальные символы
  • морфологические анализ, или варианты stemming-collapsing из данного слова в один индексный термин; например, лечить "мышей" и "мышь", или "электрификация" и "электрический" как то же самое слово
  • рейтинг-измерения сходство совпадающей записи с строка запроса
132

FTS включает индексирование отдельных слов в текстовом поле, чтобы сделать поиск по многим записям быстрым. Использование LIKE по-прежнему требует от вас поиска строк (линейных или подобных) в поле.

36

Как использует только подстановочные знаки, и не все, что мощный.

полный текст позволяет гораздо более сложный поиск, в том числе и, или, не, даже аналогичные результаты звучания (SOUNDEX) и многие другие элементы.

Я бы начал смотреть на SQL содержит () FREETEXT () и связанные полнотекстовые элементы поиска, чтобы помочь лучше понять, что доступно.

15

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

есть несколько преимуществ для полнотекстового поиска.

индексирование:

что-то типа:

где Foo нравится "%Bar"; Невозможно воспользоваться индексом. Он должен смотреть на каждую строку и видеть, соответствует ли она. Ля однако полнотекстовый индекс может. Фактически, полнотекстовые индексы могут предложить гораздо большую гибкость с точки зрения порядка совпадения слов, того, насколько близко эти слова друг к другу и т. д.

Stemming:

полнотекстовый поиск может содержать слова. Если вы ищете run, вы можете получить результаты для "ran" или "running". Большинство полнотекстовых движков имеют словари stem на разных языках.

Взвешенные Результаты:

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

недостатки:

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

полнотекстовые индексы также могут быть медленнее для обновления. Если данные изменения лот, могут быть некоторые индексы обновления отставания по сравнению со стандартными индексы.

14

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

Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}

теперь терм-матрица документа (член какого Терма какого документа) может быть представлена как:

t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}

когда приходит запрос с просьбой "получить мне все документы, содержащие слово / термин t1" - тогда набор документов {d1, d5, d9,.. dn} является возвращенный.

вы можете взломать де-нормализованную схему таблицы для хранения документов - каждая строка в таблице MySQL будет рассматриваться как" документ", а текстовый столбец может содержать абзац и т. д. Перевернутый индекс будет содержать термины как хэш-ключи и идентификаторы строк как идентификаторы документов.

помните, что этот SQL-запрос будет иметь более или менее O(1) производительность. Запрос будет независим от

  1. количество слов/терминов в тексте колонка
  2. количество строк/документов, соответствующих критериям
  3. длина слов / терминов

например, этот SQL может быть запущен, чтобы извлечь все строки, соответствующие данному слову XYZ:

SELECT * 
FROM   my_table 
WHERE  MATCH (my_text_column) against ('XYZ' IN boolean mode) ;

предостережение: если вы добавите ORDER BY в этот запрос, время выполнения будет зависеть от нескольких параметров, одним из которых является количество совпадающих строк/документов. Так что будьте осторожны.

подобное, однако, не имеет ничего общего с этим. Это вынужден линейно сканировать предложение / строку и находить все соответствующие термины. Добавление wild card добавляет беспорядок. Он отлично работает для небольших строк длины, как вы можете себе представить, но потерпит неудачу для более длинных предложений. И определенно не сопоставимы при наличии абзаца или целой страницы текста и т. д.

9

FTS является более эффективным, мощным (особенно для Word Breakers и stemming функциональных возможностей) ... но проверьте свои требования, потому что иногда DBs не поддерживают все языки, например MSSQL не поддерживает греческий (проверьте на этой страницеhttp://msdn.microsoft.com/en-us/library/ms176076 (v=sql.110).aspx)

3