Comments 13
У нас .Net + MSSQL: пользуемся полнотекстовым поиском с прекрасными результатами по производительности.
Важно также заметить, что полнотекстовый поиск для продукта на базе MS:
— имеет низкий порог вхождения
— не требует установки доп. приложений
— сосуществует в одной базе с классическими нормализованными данными
Важно также заметить, что полнотекстовый поиск для продукта на базе MS:
— имеет низкий порог вхождения
— не требует установки доп. приложений
— сосуществует в одной базе с классическими нормализованными данными
В своё время, решая задачу с поиском по номерам заказов, состоящих как раз из буквенной серии и числового номера, с удивлением для себя обнаружил, что выбор в качестве Word Breaker Language тайского помогает достигнуть результата. Возможно, есть и другие языки со схожим поведением.
Разумеется, это тот ещё костыль, и корректно работать он будет далеко не всегда. Но в нашем конкретном случае выстрелило и покрывало все варианты поиска.
Зато «из коробки» и без введения доп. процедур работы с данными.
Разумеется, это тот ещё костыль, и корректно работать он будет далеко не всегда. Но в нашем конкретном случае выстрелило и покрывало все варианты поиска.
Зато «из коробки» и без введения доп. процедур работы с данными.
(на правах автора)
Забавно) Спасибо, запомню
Забавно) Спасибо, запомню
А почему так? Как конкретно он разбивал слова?
Как будет вести себя разбивка на слова вы можете сами посмотреть через функцию 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)
Пара вопросов.
1. Нормализация слов для каких языков?
2. Как можно понять что перестроение полнотекстового индекса закончилось для конкретной транзакции?
1. Нормализация слов для каких языков?
2. Как можно понять что перестроение полнотекстового индекса закончилось для конкретной транзакции?
1. В статье не использовались механизмы, для которых нужна нормализация. Простой поиск по подстроке, без синонимов и прочего. Для создания индексов использовался Английский язык, кроме последнего примера, с внешним word breaker
2. Тут, к сожалению, простого способа нет. Ну или я его не нашел. Можно следить за очередью по конкретной таблице при помощи команды
SELECT OBJECTPROPERTY(object_id('partners'), 'TableFulltextPendingChanges')
Ну и, соответственно, ждать полного «рассасывания» очереди или просто следить за дельтой.
2. Тут, к сожалению, простого способа нет. Ну или я его не нашел. Можно следить за очередью по конкретной таблице при помощи команды
SELECT OBJECTPROPERTY(object_id('partners'), 'TableFulltextPendingChanges')
Ну и, соответственно, ждать полного «рассасывания» очереди или просто следить за дельтой.
Большое спасибо автору!
Много раз подступался к теме ускорения Like-поиска, а самый удачный получался в postgresql на триграммах. Хотелось аналогичного в MSSQL. Все результаты гугления сводятся к ручному распиливанию на префиксы и поиску по 'prefix%' шаблону. Уже погонял предлагаемое решение из статьи, и результат с кастомным wordbreaker-ом очень неплохо работает и крайне удобен в использовании.
Много раз подступался к теме ускорения Like-поиска, а самый удачный получался в postgresql на триграммах. Хотелось аналогичного в MSSQL. Все результаты гугления сводятся к ручному распиливанию на префиксы и поиску по 'prefix%' шаблону. Уже погонял предлагаемое решение из статьи, и результат с кастомным wordbreaker-ом очень неплохо работает и крайне удобен в использовании.
На сколько я знаю, в ms sql только либо like 'abc%', который использует индекс, либо полнотекстовый.
Как только вы пытаетесь найти что-то после '%' ('abc%def') индекс больше не работает. Максимум можно использовать хак для «ends with» поиска ('%abc'), создав колонку с перевернутым значением и получив возможность использовать 'cba%' запрос.
Как только вы пытаетесь найти что-то после '%' ('abc%def') индекс больше не работает. Максимум можно использовать хак для «ends with» поиска ('%abc'), создав колонку с перевернутым значением и получив возможность использовать 'cba%' запрос.
Есть ещё такая штука как бинарные collation.
Да, seek'а не будет. Но, если мне не изменяет память, можно сильно сократить количество логических чтений.
Пример есть на канале russianVC в этом видео.
Да, seek'а не будет. Но, если мне не изменяет память, можно сильно сократить количество логических чтений.
Пример есть на канале russianVC в этом видео.
Sign up to leave a comment.
2 лайфхака: альтернативы классическому поиску в Microsoft SQL Server