Data engineering
Полнотекстовый поиск: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — inverted index, паритет анализаторов, тюнинг BM25, GIN vs GiST, near-real-time refresh и reindex без даунтайма.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, проектируя или отлаживая реальный поиск — не определение для заучивания, а компромисс, который надо взвесить относительно корпуса, скорости записи и SLO.
Цель
Убедись, что связываешь inverted index, конвейер анализа, релевантность BM25, выбор Postgres-vs-движок и операционные ловушки (задержка refresh, reindex-миграции) в единую модель того, как поиск на самом деле себя ведёт.
Викторина
Completed
Запрос по 'running' возвращает ноль результатов без ошибок в логах. Документы проиндексированы со stemming-анализатором; путь запроса анализирует терм иначе. Какова наиболее вероятная корневая причина?
Heads-up Bloat замедляет lookup, но никогда не превращает корректно записанный токен в не-совпадение. Ноль результатов значит, что ничего не совпало — это проблема токенизации, а не здоровья индекса.
Heads-up k1 лишь меняет форму ранжирования уже совпавших документов. Он не может превратить совпадение в не-совпадение — ноль результатов это сбой матчинга, а не скоринга.
Heads-up Задержка refresh даёт краткую паузу для свежезаписанных документов, а не постоянный ноль для уже проиндексированных, которые другой формулировкой запроса нашлись бы.
Викторина
Completed
Почему современные движки перешли от чистого TF-IDF к BM25 для скоринга по частоте терма?
Heads-up Скорость не мотив; оба дёшевы после слияния posting lists. BM25 — это улучшение релевантности, а не производительности.
Heads-up BM25 скорит кандидатов, которых уже произвёл inverted index. Он ранжирует вывод индекса, но не заменяет сам индекс.
Heads-up Stemming и tokenization происходят до скоринга. BM25 скорит те токены, что произвёл анализ — две стадии независимы.
Викторина
Completed
SaaS-приложению на Postgres нужен поиск по ~2M тикетам поддержки: keyword-матч, базовая релевантность, умеренные записи, малый ops-бюджет. Какой выбор по умолчанию правильный?
Heads-up Оверинжиниринг под эти ограничения. ES оправдан на faceting, fuzzy-матче, тюнинге BM25 или scale-out — ничего из этого тут не нужно — ценой кластера в эксплуатации и проблемы консистентности dual-write.
Heads-up LIKE с ведущим wildcard не может использовать B-tree, поэтому ты всё равно сканируешь все 2M строк, без stemming, без case-folding и без релевантности. Это ровно та проблема, которую заменяет full-text search.
Heads-up GiST блещет при постоянных записях или жёстком лимите диска; здесь доминируют чтения, а записи умеренные — это вотчина GIN: lookup примерно в 3x быстрее, а lossiness GiST форсирует rechecks по таблице.
Викторина
Completed
Ты выбрал GIN для tsvector-индекса. Спустя месяцы, на теперь write-heavy таблице, латентность поиска деградирует с перебоями без изменения запроса. Каков наиболее вероятный механизм?
Heads-up k1 и b — статическая конфигурация; они не дрейфуют с размером корпуса, и Postgres ts_rank по умолчанию вообще не использует BM25. Симптом — здоровье индекса под записью, а не скоринг.
Heads-up Больше кандидатов добавляет немного стоимости ранжирования, но перебойная деградация, привязанная к объёму записи, прямо указывает на flush pending list и bloat GIN, а не на арифметику ранжирования.
Heads-up Смена анализатора дала бы неверные или пустые результаты, а не перебойную латентность, которая трекает объём записи. Это failure mode сопровождения индекса, а не токенизации.
Викторина
Completed
Сервис на Elasticsearch пишет документ и сразу читает его обратно поиском, периодически получая промах. Команда предполагала write-then-read консистентность. Что происходит?
Heads-up Перебойный промах, который разрешается за ~1s, — это окно refresh, а не отброс. Отброшенная запись никогда не стала бы доступной для поиска; эта становится — мгновением позже.
Heads-up Позиция ранжирования не может сделать документ кратко невидимым, а затем видимым без изменения данных. Тайминг видим-потом-нет — сигнатура refresh interval.
Heads-up GIN — структура Postgres; Elasticsearch использует сегменты Lucene. Описанное поведение — это refresh-to-searchable латентность Lucene, by design.
Викторина
Completed
Нужно починить баг stemming, поменяв анализатор существующего поля на 200M документах в Elasticsearch. Какова правильная миграция и почему?
Heads-up Lucene не может поменять анализатор или тип существующего поля — закоммиченные токены неизменяемы. Ленивой ре-токенизации нет; нужно строить новый индекс.
Heads-up Удаление живого индекса означает, что клиенты видят пустой или падающий поиск, пока reindex не завершится — часы на 200M документов. Проектирование за read-алиасом полностью избегает простоя.
Heads-up refresh_interval управляет латентностью write-to-searchable, а не сменой анализатора. Он не имеет отношения к ре-токенизации уже закоммиченных документов.
Итог
Сквозная линия: совпадение — это токены, а не строки, поэтому один и тот же анализатор должен работать при индексировании и при запросе, иначе получишь молчаливые нули; BM25 ранжирует кандидатов, которых произвёл inverted index, насыщая term frequency и нормализуя длину; Postgres GIN — правильный выбор по умолчанию, пока не понадобятся facets, fuzziness, тюнинг BM25 или масштаб, и тогда внутренний выбор — write-bloat GIN против lossiness GiST; а операционные ловушки — near-real-time задержка refresh и reindex из-за неизменяемых токенов — это причина проектировать за read-алиасом с первого дня.