Повнотекстовий пошук

Канал подає повнотекстовий пошук не як «просто візьми Elastic», а як механізм, який можна зібрати власноруч — Віктор саме так і зробив у продакшені, власноруч побудувавши повнотекстовий індекс на 300 TB. Мотивуюча невдача: B-tree-індекс робить LIKE 'prefix%' миттєвим, але LIKE '%word%' займає ~40 с (або ~7 с у ранішому демо), бо жоден порядок сортування не допоможе знайти слово всередині значення (навіщо потрібні індекси в базах даних, повнотекстовий пошук та інвертовані індекси). Відповідь — інвертований індекс, а довкола нього конвеєр, який він будує наживо: токенізація (розбиття, фільтрація стоп-слів і закоротких токенів, зведення до нижнього регістру) та стемінг проти лематизації — з його українським контрприкладом: стемінг 'німці' → 'німц' не ловить 'німець', тому в його проєкті на 300 TB використовувався лематизатор (там само). Критично важливо: той самий конвеєр треба застосовувати й до запитів.

Його ключова максима з Q&A-продовження: «хочеш шукати інакше — мусиш індексувати інакше». Пошук підрядка всередині слова — це не хитріший запит, а n-грамний токенізатор (він малює триграми над словом 'family') ціною роздування індексу у 2–3 рази. Каталог токенізаторів Elasticsearch (edge n-gram, letter, keyword, pattern, кастомні витягувачі хештегів/IP) — це насправді меню стратегій індексації (Q&A до другої частини). Його прагматичний вердикт: у реальному житті беріть вбудований FULLTEXT або Elasticsearch — але тепер ви знаєте, що вони насправді роблять; а його саморобний індекс обійшов MySQL LIKE (40 с → 21 мс на 16.5 млн рядків) і вийшов меншим за власний FULLTEXT-індекс MySQL.