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

Я только что прочитал сообщение, в котором упоминается «полнотекстовый поиск» в SQL.

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

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

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

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

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

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

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

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

Кроме того, из этого SO-ответа :

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

Индексация:

Что-то вроде:

WHERE Foo LIKE '%Bar';

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

Сдерживание:

Полнотекстовый поиск может определять слова. Если вы выполните поиск по запросу «бег», вы можете получить результаты по «бегу» или «бегу». Большинство полнотекстовых машин имеют базовые словари на разных языках.

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

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

Недостатки:

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

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

Like использует только подстановочные знаки, и это не так уж и важно.

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

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

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

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 будет считаться «документом», а столбец TEXT может содержать абзац и т. Д. Инвертированный индекс будет содержать термины как хеш-ключи и идентификаторы строк. как идентификаторы документов.

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

1. Количество слов / терминов в столбце ТЕКСТ
2. Количество строк / документов, соответствующих критериям
3. Длина слов / терминов

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

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

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

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

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