Привет, Хабр! Наши друзья из Softpoint подготовили интересную статью о Microsoft SQL Server. В нем рассматриваются два практических примера использования полнотекстового поиска:
- Поиск по «бесконечным» строкам (например, по комментариям) в отличие от обычного поиска через LIKE;
- Поиск по номерам документов с префиксами.
Там, где обычно нельзя использовать полнотекстовый поиск: его затрудняют постоянные префиксы.
Анализируются два подхода: предварительная обработка номера документа и добавление собственной библиотеки разбиения по словам.
предоставляю слово автору Эффективный поиск гигабайт накопленных данных – это своего рода «Святой Грааль» учетных систем.
Все хотят найти его и обрести бессмертную славу, но в процессе поиска раз за разом оказывается, что единого чудо-решения не существует. Ситуация осложняется тем, что пользователи обычно хотят искать по вхождению подстроки — где-то оказывается, что нужный номер контракта «запрятан» в середине комментария; где-то оператор не помнит точно фамилию клиента, но запомнил, что его зовут «Алексей Евграфович»; где-то нужно просто опустить повторяющуюся форму собственности ПОЮБЛ и искать сразу по названию организации.
Для классических реляционных СУБД такой поиск — очень плохая новость.
Чаще всего такой поиск по подстроке сводится к методичному пролистыванию каждой строки таблицы.
Не самая эффективная стратегия, особенно если размер таблицы вырастет до нескольких десятков гигабайт. В поисках альтернативы я часто думаю о «полнотекстовом поиске».
Радость от поиска решения обычно быстро угасает после беглого анализа существующей практики.
Быстро становится понятно, что, согласно распространенному мнению, полнотекстовый поиск:
- Сложно настроить
- Медленно обновляется
- Зависает система при обновлении
- Имеет какой-то глупый необычный синтаксис
- Не находит то, что просят
Давайте разберемся, так ли страшен черт, как его малюют? И прежде чем мы углубимся в исследования, Давайте сразу договоримся о важном условии .
Система полнотекстового поиска может делать гораздо больше, чем обычный строковый поиск.
Например, вы можете составить словарь синонимов и использовать слово «контакт», чтобы найти слово «телефон».
Или искать слова, не учитывая их форму и окончания.
Эти опции могут быть очень полезны для пользователей, но в этой статье мы рассматриваем полнотекстовый поиск только как альтернативу классическому строковому поиску.
То есть, Будем искать только ту подстроку, которая будет указана в строке поиска , без учета синонимов, без приведения слов к «нормальной» форме и прочей магии.
Как работает полнотекстовый поиск MS SQL?
Из основного сервиса СУБД частично удалена функция полнотекстового поиска в MS SQL (ближе к концу статьи мы увидим, почему это может быть крайне полезно).Для поиска формируется специальный индекс со своей структурой, в отличие от обычных сбалансированных деревьев.
Важно, что для создания индекса полнотекстового поиска необходимо, чтобы в ключевой таблице существовал уникальный индекс, состоящий всего из одного столбца — именно по нему полнотекстовый поиск будет идентифицировать строки таблицы.
Часто таблица уже имеет такой индекс по Primary Key, но иногда его придется создавать дополнительно.
Заполнение индекса полнотекстового поиска происходит асинхронно и вне транзакции.
После изменения строки таблицы она ставится в очередь на обработку.
Процесс обновления индекса берет из строки (строки) таблицы все строковые значения, «подписанные» на индекс, и разбивает их на отдельные слова.
После этого слова можно привести к какому-нибудь «стандартному» виду (например, без окончаний), чтобы облегчить поиск по словоформе.
«Стоп-слова» (предлоги, артикли и другие слова, не имеющие смысла) выбрасываются.
Остальные совпадения ссылок на строки слов записываются в индекс полнотекстового поиска.
Получается, что каждый столбец таблицы, включенный в индекс, проходит через следующий конвейер: Длинная строка -> разделитель слов -> набор частей (слов) -> стеммер -> нормализованные слова -> [необязательно] без стоп-слов -> запись в индекс Как уже говорилось, процесс обновления индекса является асинхронным.
Поэтому:
- Обновление не блокирует действия пользователя
- Обновление ожидает завершения транзакции изменения строки и начинает применять изменения не раньше, чем произойдет фиксация.
- Изменения полнотекстового индекса применяются с некоторой задержкой относительно базовой транзакции.
То есть между добавлением строки и временем ее обнаружения будет задержка, зависящая от длины очереди обновления индекса.
- Количество элементов, содержащихся в индексе, можно отслеживать с помощью следующего запроса:
Теги: #microsoft #Хранилище данных #sql #Microsoft SQL Server #sql-серверSELECT
-
Ispmanager 6. Что Нового?
19 Oct, 24 -
Литература 2.0
19 Oct, 24
