Повнотекстовий пошук: 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"
      }'

Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно і підберемо оптимальне рішення.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.