Post #81

🔗 Всем привет, продолжаю рассказывать про наших ботов @sounds и @clips. Сегодня покажу, как работает технология поиска, благодаря которому мы помогаем вам найти максимально релевантные результаты по мемным звукам или кружочкам. Когда вы пишете в боте запрос типа "гойда" или "ну давай нападай", кажется, что это просто "поиск по базе". Но внутри это больше похоже на умный поиск Google, только заточенный под нашу базу (звуки/кружки). 👨‍💻 Из чего состоит поиск(скриншот 2) У нас есть три слоя, которые работают вместе: • PostgreSQL — основная база, где хранятся сами звуки (название, описание, теги). • Elasticsearch — быстрый “мозг” для полнотекстового поиска (умеет искать по словам, ошибкам, похожим формулировкам). • ZomboDB — магический мост между ними: позволяет делать Elasticsearch-поиск прямо из SQL, как будто это обычный запрос в Postgres. Он также занимается формированием индексов на основе данных Postgres в ElasticSearch. То есть: данные живут в Postgres, а ищем мы силой Elasticsearch, при этом всё выглядит как "одна база". 🐥Что именно мы ищем Каждый звук индексируется по трём главным полям: • title (название) • description (описание) • tags (теги) Они собираются в "единый поисковый документ", и по нему строится индекс. Фишка ZomboDB: когда звук меняется в Postgres — индекс в Elasticsearch обновляется автоматически. Без ручной синхронизации. 📰 Два пути поиска: в боте и через API (скриншот 2) Поиск доступен двумя способами: • Inline в Telegram: @bot <запрос> • Через наш MiniApp, там происходит запрос в API: GET /api/sounds?query=... Но самое главное: оба пути приходят в один и тот же метод — SoundDAO.get_list() (то есть логика поиска единая и вы получите одинаковый результат, независимо от источника взаимодействия). 🙃Как запрос превращается в результат(скриншот 1) Когда вы вводите текст, система делает несколько попыток найти лучшее совпадение. 1) Сначала — "строгий" поиск (MUST) Логика: все слова из запроса должны встретиться. Это даёт максимально точные результаты. И да: поиск умеет "прощать" опечатки — включён режим fuzziness: AUTO, то есть: • «превет» может найти «привет» • «смешной звук» найдёт даже если где-то ошиблись 2) Если строго не нашло — включается "мягкий" поиск (SHOULD) Логика: берём только слова длиннее 3 букв, и достаточно, чтобы совпала примерно половина. Когда полезен: • длинный • с лишними словами • "криво сформулирован" 3) Если и "мягкий" не помог — включается "нечёткий" поиск (FUZZY / SIMILARITY) Логика: мы смотрим на запрос целиком и пытаемся найти похожие варианты, даже если слова написаны по-разному, перепутан порядок или опечаток больше обычного. Это такой режим “ну ты понял, что я имел в виду”. Когда полезен: • короткий и неточный (типа «ааа ну тот звук») • с кучей опечаток / транслитом («privet», «prvyt», «preevet») • с переставленными словами («звук смешной» vs «смешной звук») • когда помнишь только кусок фразы, а остальное “примерно” ⚡️Почему один звук выше другого Результаты сортируются так: • по релевантности (насколько “попали в смысл запроса”) — это score от Elasticsearch • по популярности (сколько раз звук использовали) То есть идеальный вариант — и подходит по смыслу, и реально любимый людьми. 🙈Что происходит, когда вы просто открыли inline и ничего не ввели Если запрос пустой, мы не делаем никакого поиска — вместо этого собираем витрину: • Промо-звуки (сейчас их нет) • Ваша история (последние отправленные) • Топ популярных (по количеству использований) И всё это аккуратно склеивается в один список (до 50 штук), с дедупликацией, чтобы не было повторов. 🚀 Как считаются "использования"(скриншот 3) Когда вы выбираете звук в inline — мы не пишем счётчик сразу в базу (это бы замедлило систему). Вместо этого событие улетает в Redis Stream, а дальше отдельный воркер: • читает события пачками • обновляет счётчики • записывает историю В итоге бот отвечает быстро, а статистика обновляется асинхронно.