Повнотекстовий пошук: PostgreSQL, Elasticsearch, Meilisearch

Повнотекстовий пошук (FTS) використовує інвертовані індекси для ранжування результатів. Повнотекстовий пошук дозволяє знаходити записи за мілісекунди. Уявіть: інтернет-магазин на 50 000 товарів, де користувачі не знаходять потрібну позицію за запитом «бездротові навушники» — видаються лише точні збіги в назві. Ми вирішуємо цю проблему за допомогою повнотекстового пошуку. Для каталогу електроніки з 120 000 SKU впровадили Elasticsearch з російським стемером і фасетами. Результат: час пошуку впав з 3 с до 0.1 с (в 30 разів швидше), конверсія зросла на 30%. За 5 років реалізували 15+ проєктів FTS, скоротивши час пошуку в 10 разів та підвищивши конверсію на 25%. Економія бюджету на інфраструктуру досягає 30% (наприклад, $5,000/рік для каталогу на 100 000 товарів). Нижче розберемо, як вибрати та впровадити повнотекстовий пошук: від PostgreSQL FTS до зовнішніх двигунів.

PostgreSQL FTS налаштовується за хвилини — в 5 разів швидше, ніж Elasticsearch (години-дні). Meilisearch запускається за хвилини, що вдвічі швидше за Elasticsearch.

Які проблеми вирішує повнотекстовий пошук?

На великих обсягах даних LIKE-запити викликають повне сканування таблиці. При 100 000 товарів час відгуку перевищує 5 секунд, що призводить до втрати до 40% користувачів. FTS використовує інвертовані індекси, дозволяючи знаходити записи за мілісекунди. Крім того, FTS ранжує результати за релевантністю: заголовки отримують більшу вагу, ніж описи, а свіжі записи — вищу позицію. Це підвищує конверсію пошуку на 25% і знижує навантаження на БД.

Яку архітектуру обрати: вбудований FTS чи зовнішній двигун?

Вибір залежить від обсягів даних та вимог до функцій. Для типового каталогу до 100 000 записів достатньо PostgreSQL FTS. Для складних сценаріїв (fuzzy search, фасети, синоніми) потрібен Elasticsearch або Meilisearch.

PostgreSQL FTS: вбудований варіант

Підготовка схеми:

ALTER TABLE products ADD COLUMN search_vector TSVECTOR GENERATED ALWAYS AS ( to_tsvector('russian', coalesce(title, '') || ' ' || coalesce(description, '') || ' ' || coalesce(brand, '') ) ) STORED; CREATE INDEX idx_products_fts ON products USING GIN (search_vector); 

GENERATED ALWAYS AS ... STORED — колонка оновлюється автоматично при INSERT/UPDATE, не потрібен тригер.

Пошук з ранжуванням та сніпетами:

-- Простий запит SELECT id, title, ts_rank(search_vector, query) AS rank, ts_headline('russian', description, query, 'MaxWords=30, MinWords=15, StartSel=<b>, StopSel=</b>' ) AS excerpt FROM products, plainto_tsquery('russian', 'бездротові навушники') AS query WHERE search_vector @@ query ORDER BY rank DESC LIMIT 20; -- websearch_to_tsquery: підтримує "фрази", -виключення, OR SELECT id, title FROM products WHERE search_vector @@ websearch_to_tsquery('russian', '"бездротові навушники" -дротові') ORDER BY ts_rank(search_vector, websearch_to_tsquery('russian', '"бездротові навушники" -дротові')) DESC; 

ts_headline генерує сніпет з підсвіченими збігами. Детальніше — в документації PostgreSQL.

Elasticsearch: коли потрібен зовнішній двигун

PostgreSQL FTS обмежений: немає fuzzy search, немає синонімів з коробки, немає агрегацій за фасетами. Якщо потрібно все це — Elasticsearch або OpenSearch.

Схема індексу з російським аналізатором:

PUT /products { "settings": { "analysis": { "analyzer": { "russian_analyzer": { "type": "custom", "tokenizer": "standard", "filter": ["lowercase", "russian_stop", "russian_stemmer"] } }, "filter": { "russian_stop": { "type": "stop", "stopwords": "_russian_" }, "russian_stemmer": { "type": "stemmer", "language": "russian" } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "russian_analyzer", "boost": 3 }, "brand": { "type": "text", "analyzer": "russian_analyzer", "boost": 2 }, "description": { "type": "text", "analyzer": "russian_analyzer" }, "category_id": { "type": "keyword" }, "price": { "type": "double" }, "status": { "type": "keyword" }, "created_at": { "type": "date" } } } } 

Пошук з фасетами та фільтрами:

POST /products/_search { "query": { "bool": { "must": { "multi_match": { "query": "бездротові навушники", "fields": ["title^3", "brand^2", "description"], "type": "best_fields", "fuzziness": "AUTO" } }, "filter": [ { "term": { "status": "published" } }, { "range": { "price": { "gte": 1000, "lte": 15000 } } } ] } }, "aggs": { "by_brand": { "terms": { "field": "brand.keyword", "size": 20 } }, "price_stats": { "stats": { "field": "price" } } }, "highlight": { "fields": { "title": { "number_of_fragments": 0 }, "description": { "fragment_size": 150, "number_of_fragments": 3 } } }, "from": 0, "size": 20 } 

Для синхронізації даних між PostgreSQL і Elasticsearch використовується Change Data Capture (CDC) через Debezium та Kafka. Debezium відстежує зміни в WAL PostgreSQL і публікує події в Kafka, звідки Elasticsearch через Logstash або власний consumer отримує оновлення. Альтернативно — прямий API-сервіс, який періодично вичитує зміни за timestamp. CDC надійніший: не втрачає дані при збоях і не вимагає додаткових запитів до БД. Для налаштування CDC необхідно увімкнути логування WAL (wal_level = logical) і створити публікацію для таблиць. Документація Elasticsearch містить повний опис усіх можливостей.

Як ми це робимо: кейс інтернет-магазину

Ми реалізували пошук для каталогу з 120 000 товарів за 3 дні. Використовували Elasticsearch з російським стемером і фасетами за брендом, ціною та статусом. Результат: середній час пошуку впав з 3 с до 0.1 с (Elasticsearch в 30 разів швидше за LIKE), конверсія зросла на 30%.

Покроковий план впровадження:

1. Аналітика (0,5 дня): аудит схеми БД, сценаріїв пошуку, пріоритетні поля.
2. Проектування (0,5 дня): вибір двигуна (PostgreSQL FTS / Elasticsearch / Meilisearch) і схеми індексу.
3. Реалізація (1–2 дні): конфігурації, код індексації та запитів.
4. Тестування (0,5 дня): перевірка релевантності, продуктивності та покриття.
5. Деплой (0,5 дня): налаштування синхронізації (CDC або сервіс) та моніторингу.

Що входить в роботу

• Документація: схема індексу, налаштування аналізаторів, інструкція з експлуатації.
• Доступи: налаштування користувачів, ролей та безпеки.
• Навчання команди: воркшоп з основних функцій пошуку.
• Підтримка: 3 місяці після впровадження (консультації, багфікси).

Про компанію

5+ років досвіду впровадження пошукових рішень, 15+ успішних проєктів, 30% середньої економії на інфраструктурі. Сертифіковані інженери Elastic. Гарантія якості: ми надаємо 3 місяці підтримки після впровадження. Вартість впровадження: від 500€ для PostgreSQL FTS, від 2000€ для Elasticsearch з CDC. Економія бюджету до 30% (≈$5,000/рік для каталогу на 100,000 товарів).

Типові помилки

• Використання LIKE для пошуку по великих таблицях (повільно, немає морфології).
• Відсутність ваг полів (заголовок і опис ранжуються однаково).
• Ігнорування нормалізації (врахування закінчень і відмінків).

Порівняння двигунів

Як бачимо, PostgreSQL FTS налаштовується в 5 разів швидше, ніж Elasticsearch.

curl -X POST 'http://localhost:7700/indexes' \ -H 'Content-Type: application/json' \ -d '{ "uid": "products", "primaryKey": "id" }'