2 лайфхака: альтернативы классическому поиску в Microsoft SQL Server

[vagon333]

У нас .Net + MSSQL: пользуемся полнотекстовым поиском с прекрасными результатами по производительности.
Важно также заметить, что полнотекстовый поиск для продукта на базе MS:
— имеет низкий порог вхождения
— не требует установки доп. приложений
— сосуществует в одной базе с классическими нормализованными данными

[4eS]

В своё время, решая задачу с поиском по номерам заказов, состоящих как раз из буквенной серии и числового номера, с удивлением для себя обнаружил, что выбор в качестве Word Breaker Language тайского помогает достигнуть результата. Возможно, есть и другие языки со схожим поведением.

Разумеется, это тот ещё костыль, и корректно работать он будет далеко не всегда. Но в нашем конкретном случае выстрелило и покрывало все варианты поиска.
Зато «из коробки» и без введения доп. процедур работы с данными.

[frrrost]

(на правах автора)
Забавно) Спасибо, запомню

[4eS]

Запишите себе ещё и корейский word breaker в копилку.
Тайский, похоже, с латиницей не очень, а вот корейский нормально справляется.
Пример в комментарии ниже.

[uaggster]

А почему так? Как конкретно он разбивал слова?

[4eS]

Как будет вести себя разбивка на слова вы можете сами посмотреть через функцию dm_fts_parser.
Посмотрел сейчас сам. Тайский не отделяет в отдельное слово префиксы на латинице. А вот корейский также считает, что буквы отдельно, цифры отдельно.
Не исключаю, что именно на корейском мы и остановились в итоге в нашем решении, но в голове засел именно тайский. Дело было давно и память может подводить.

-- Thai
SELECT * FROM sys.dm_fts_parser (N' "ОРГ00000934" ', 1054, 0, 1)
UNION ALL
SELECT * FROM sys.dm_fts_parser (N' "VGF00000934" ', 1054, 0, 1);

-- Korean
SELECT * FROM sys.dm_fts_parser (N' "ОРГ00000934" ', 1042, 0, 1)
UNION ALL
SELECT * FROM sys.dm_fts_parser (N' "VGF00000934" ', 1042, 0, 1)

[piton_nsk]

Пара вопросов.
1. Нормализация слов для каких языков?
2. Как можно понять что перестроение полнотекстового индекса закончилось для конкретной транзакции?

[frrrost]

1. В статье не использовались механизмы, для которых нужна нормализация. Простой поиск по подстроке, без синонимов и прочего. Для создания индексов использовался Английский язык, кроме последнего примера, с внешним word breaker
2. Тут, к сожалению, простого способа нет. Ну или я его не нашел. Можно следить за очередью по конкретной таблице при помощи команды
SELECT OBJECTPROPERTY(object_id('partners'), 'TableFulltextPendingChanges')
Ну и, соответственно, ждать полного «рассасывания» очереди или просто следить за дельтой.

[afgm]

Большое спасибо автору!
Много раз подступался к теме ускорения Like-поиска, а самый удачный получался в postgresql на триграммах. Хотелось аналогичного в MSSQL. Все результаты гугления сводятся к ручному распиливанию на префиксы и поиску по 'prefix%' шаблону. Уже погонял предлагаемое решение из статьи, и результат с кастомным wordbreaker-ом очень неплохо работает и крайне удобен в использовании.

[vvovas]

На сколько я знаю, в ms sql только либо like 'abc%', который использует индекс, либо полнотекстовый.
Как только вы пытаетесь найти что-то после '%' ('abc%def') индекс больше не работает. Максимум можно использовать хак для «ends with» поиска ('%abc'), создав колонку с перевернутым значением и получив возможность использовать 'cba%' запрос.

[4eS]

Есть ещё такая штука как бинарные collation.
Да, seek'а не будет. Но, если мне не изменяет память, можно сильно сократить количество логических чтений.
Пример есть на канале russianVC в этом видео.

[vvovas]

Неплохо. Не знал об этом, спасибо за наводку.

[4eS]

Есть ещё такая штука как бинарные collation.
Да, seek'а не будет. Но, если мне не изменяет память, можно сильно сократить количество логических чтений.
Пример есть на канале russianVC в этом видео.

P.S.: Коммент должен был уйти в эту ветку :(