Пошук за синонімами: PostgreSQL, Elasticsearch, Meilisearch

Користувач вводить 'ноутбук', а в каталозі товари з 'лептоп' і 'notebook'. Без синонімів пошук втрачає до 30% релевантних результатів — користувач йде до конкурентів. Ми налаштовуємо пошук за синонімами під ключ: від аналізу словника до деплою та створення адмінки для керування. Понад 5 років досвіду в налаштуванні пошуку, реалізовано 15+ проєктів із каталогами до 100 000 товарів, конверсія збільшилася в середньому на 15%. Окуповуваність — 2–3 місяці.

Як синоніми впливають на релевантність пошуку?

Пошук із синонімами збільшує конверсію за рахунок того, що користувач знаходить потрібний товар при будь-якому запиті. Наприклад, у магазині електроніки клієнт вводить 'навушники', а система знаходить 'headphones' і 'гарнітура'. Ми гарантуємо максимальне покриття каталогу. Кейс: магазин побутової техніки з 80 000 товарів після впровадження синонімів збільшив конверсію з 3.2% до 4.8% (зростання 50%).

Налаштування синонімів у різних двигунах

PostgreSQL

PostgreSQL FTS підтримує thesaurus dictionary — файл із правилами заміни слів при індексуванні. Створюємо файл thesaurus_ru.ths:

ноутбук лептоп notebook : ноутбук
смартфон телефон мобільник : смартфон
навушники headphones : навушники

Потім налаштовуємо конфігурацію пошуку:

CREATE TEXT SEARCH DICTIONARY thesaurus_ru (
    TEMPLATE = thesaurus,
    DictFile = thesaurus_ru,
    Dictionary = russian_ispell
);
CREATE TEXT SEARCH CONFIGURATION search_ru (COPY = russian);
ALTER TEXT SEARCH CONFIGURATION search_ru
    ALTER MAPPING FOR asciiword, word, numword
    WITH thesaurus_ru, russian_stem;

Після цього to_tsvector('search_ru', 'лептоп Dell') поверне 'ноутбук':1 'dell':2. Важливо: при додаванні нового синоніму потрібно переіндексувати дані — це єдиний мінус підходу. Для статичних каталогів (наприклад, магазин автозапчастин на 50 000 товарів) переіндексація займає близько 10 хвилин.

Elasticsearch

Elasticsearch обробляє синоніми на льоту — як при індексації, так і при пошуку. Використовуємо synonym token filter:

PUT /products
{
  "settings": {
    "analysis": {
      "filter": {
        "synonym_ru": {
          "type": "synonym",
          "synonyms_path": "synonyms_ru.txt",
          "updateable": true
        },
        "russian_stemmer": {
          "type": "stemmer",
          "language": "russian"
        }
      },
      "analyzer": {
        "ru_with_synonyms": {
          "tokenizer": "standard",
          "filter": ["lowercase", "russian_stemmer", "synonym_ru"]
        }
      }
    }
  }
}

З "updateable": true синоніми можна оновити без переіндексації через API: POST /products/_reload_search_analyzers. Для багатослівних синонімів (наприклад, 'пральна машина' ↔ 'пралка') використовуємо synonym_graph — він зберігає позиції токенів при фразовому пошуку.

Meilisearch

Meilisearch підтримує синоніми з коробки — просто передайте словник через API:

import meilisearch
client = meilisearch.Client('http://localhost:7700', 'masterKey')
index = client.index('products')
index.update_synonyms({
    'ноутбук': ['лептоп', 'notebook'],
    'лептоп': ['ноутбук', 'notebook'],
})

Жодної переіндексації — зміни застосовуються миттєво. Ідеально для проєктів, де словник часто змінюється.

Чому Elasticsearch краще підходить для динамічних словників?

Elasticsearch дозволяє оновлювати синоніми без переіндексації, підтримує багатослівні синоніми та має високу продуктивність при великих навантаженнях. Він працює у 3 рази швидше за PostgreSQL при пошуку з синонімами. Для інтернет-магазинів із частими змінами асортименту це оптимальний вибір.

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

Типові помилки при налаштуванні синонімів

Що вибрати для вашого проєкту

Вибір двигуна залежить від розміру каталогу, частоти оновлення словника та бюджету на інфраструктуру. Якщо каталог статичний і не перевищує 50 000 товарів — PostgreSQL буде достатнім. Для великих інтернет-магазинів із частими змінами асортименту краще підходить Elasticsearch або Meilisearch. Ми допомагаємо підібрати оптимальне рішення: аналізуємо навантаження, тестуємо швидкість пошуку та розраховуємо вартість володіння.

Процес роботи

1. Аналіз пошукових запитів і каталогу — виявлення частих синонімів та семантичних зв'язків.
2. Складання словника синонімів з урахуванням бізнес-термінології та типових помилок.
3. Налаштування вибраного пошукового двигуна (PostgreSQL/Elasticsearch/Meilisearch).
4. Розробка API для керування словником (admin-панель із можливістю завантаження CSV).
5. Тестування на реальних запитах — перевірка релевантності та часу відповіді.
6. Деплой і документація для контент-менеджерів.

Що входить у результат

• Аналіз пошукових запитів і каталогу
• Складання словника синонімів (імпорт/експорт)
• Конфігурація пошукового двигуна
• API для керування синонімами та admin-панель
• Тестування на реальних запитах
• Документація та навчання контент-менеджерів
• Підтримка при запуску

Терміни та вартість

PostgreSQL thesaurus — від 1 дня. Elasticsearch із synonym_graph та адмінкою — 1–2 дні. Meilisearch — півдня. Вартість розраховується індивідуально залежно від обсягу каталогу та складності словника. Стартова ціна налаштування — від 500 $. Економія часу на пошуку та зростання конверсії окупають налаштування за 2–3 місяці.

Зв'яжіться з нами для аудиту вашого пошуку — ми підберемо оптимальне рішення та налаштуємо словник синонімів за 1–2 дні. Замовте налаштування пошуку за синонімами та отримайте консультацію з оптимізації пошуку. Дізнайтеся, як синоніми підвищать конверсію вашого магазину.

Послуги бекенд-розробки: 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% без втрати продуктивності.