Реалізація пошуку з виправленням помилок для веб-застосунку

Реалізація пошуку з виправленням помилок для веб-застосунку

Користувач вводить «наушниик» — порожній результат. 70% таких відвідувачів ідуть до конкурентів. Нечіткий пошук (fuzzy search) виправляє помилки та повертає релевантні товари. За час роботи ми реалізували понад 30 проектів з fuzzy-пошуком для e-commerce та каталогів. Обираємо двигун під ваш стек та навантаження: pg_trgm, Meilisearch або Elasticsearch. При правильному налаштуванні конверсія зростає на 15–25%, а витрати на підтримку знижуються — це підтверджують наші кейси.

Наприклад, для інтернет-магазину побутової техніки ми знизили відсоток порожніх результатів з 25% до 3% за рахунок впровадження Meilisearch. Конверсія зросла на 22%. Час відповіді скоротився з 200 мс до 4 мс. Замовте пілотний проект — ми безкоштовно протестуємо на ваших даних.

Які алгоритми відстаней використовуються?

Відстань Левенштейна — мінімальна кількість вставок, видалень, замін для перетворення одного рядка в інший, описано в Wikipedia. Відстань Дамерау-Левенштейна додає транспозицію (перестановку сусідніх символів). Для української мови він кращий: «наушники» → «наушинки» — це одна транспозиція, а не дві операції. На практиці використовуємо Damerau-Levenshtein. Вибір алгоритму впливає на якість: Damerau-Levenshtein дає на 10% менше пропусків для україномовних запитів.

PostgreSQL: pg_trgm

Розширення pg_trgm працює на основі триграм і не потребує зовнішніх сервісів. Це найпростіше рішення, якщо ваш стек вже включає PostgreSQL.

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX idx_products_title_trgm ON products USING GIN (title gin_trgm_ops);
CREATE INDEX idx_products_description_trgm ON products USING GIN (description gin_trgm_ops);

SET pg_trgm.similarity_threshold = 0.3;

SELECT id, title, similarity(title, 'наушниик') AS sim
FROM products
WHERE title % 'наушниик'
ORDER BY sim DESC
LIMIT 10;

-- Комбінуємо fuzzy з повнотекстовим пошуком
SELECT p.id, p.title, p.price,
       greatest(similarity(p.title, 'беспродные наушники'),
                ts_rank(p.search_vector, plainto_tsquery('russian', 'беспродные наушники'))) AS relevance
FROM products p
WHERE p.title % 'беспродные наушники'
   OR p.search_vector @@ plainto_tsquery('russian', 'беспродные')
ORDER BY relevance DESC
LIMIT 20;

Оператор % використовує GIN-індекс. Поріг similarity_threshold 0.3 — ліберальний, 0.5 — строгий. Для коротких запитів обирайте нижню межу. На практиці ми рекомендуємо починати з 0.3 та коригувати за A/B-тестами: збільшення порогу до 0.5 знижує кількість хибних спрацьовувань, але може пропустити частину релевантних результатів. Економія на інфраструктурі при використанні pg_trgm становить до 40% порівняно із зовнішніми двигунами.

Meilisearch — виділений fuzzy-двигун

Meilisearch написаний на Rust, підтримує typo tolerance з коробки. Він спеціально спроектований для швидкого нечіткого пошуку і не потребує складного налаштування.

import meilisearch

client = meilisearch.Client('http://localhost:7700', 'your-master-key')
index = client.index('products')

# Налаштування індексу
index.update_settings({
    'searchableAttributes': ['title', 'brand', 'description', 'tags'],
    'filterableAttributes': ['category_id', 'status', 'price', 'brand'],
    'sortableAttributes': ['price', 'created_at', 'popularity'],
    'rankingRules': ['words', 'typo', 'proximity', 'attribute', 'sort', 'exactness'],
    'typoTolerance': {
        'enabled': True,
        'minWordSizeForTypos': { 'oneTypo': 5, 'twoTypos': 9 },
        'disableOnWords': ['iPhone', 'iPad'],
        'disableOnAttributes': ['sku', 'barcode'],
    },
    'pagination': { 'maxTotalHits': 10000 },
})

# Батчева індексація
batch_size = 1000
for i in range(0, len(documents), batch_size):
    batch = documents[i:i + batch_size]
    task = index.add_documents(batch)
    index.wait_for_task(task.task_uid)

{
  "hits": [
    {
      "id": 1234,
      "title": "Sony WH-1000XM5 бездротові навушники",
      "_formatted": { "title": "Sony WH-1000XM5 бездротові <mark>навушники</mark>" }
    }
  ],
  "query": "наушниик sony",
  "processingTimeMs": 4,
  "totalHits": 38,
  "page": 1,
  "hitsPerPage": 20
}

Meilisearch дає середній час відповіді менше 10 мс для каталогів до 10 млн записів, що в 10 разів швидше за pg_trgm на великих обсягах.

Elasticsearch: fuzzy-запит

Якщо Elasticsearch вже використовується, додайте fuzzy в мультиматч:

{
  "query": {
    "bool": {
      "should": [
        {
          "multi_match": {
            "query": "наушниик",
            "fields": ["title^3", "brand^2", "description"],
            "fuzziness": "AUTO",
            "prefix_length": 2,
            "max_expansions": 50
          }
        },
        {
          "match_phrase": {
            "title": {
              "query": "наушниик",
              "slop": 2
            }
          }
        }
      ]
    }
  }
}

prefix_length: 2 — точне співпадіння перших двох символів знижує хибні спрацьовування. Elasticsearch підходить для великих обсягів (10M+) та інтеграції з аналітикою, але потребує складнішої інфраструктури.

Який двигун обрати?

Для стартапів оптимальний pg_trgm — мінімальна вартість розгортання. Якщо очікуєте зростання, закладайте міграцію на Meilisearch. Для корпоративних проектів з аналітикою — Elasticsearch.

Чому налаштування порогу помилок критичне?

Кожен параметр впливає на якість: занадто ліберальний поріг дає шум, занадто строгий — пропускає помилки. На практиці ми використовуємо:

Точне налаштування дає зростання конверсії на 15–25% за нашими вимірами на 30+ проектах. Економія на доробках після запуску становить до 30% часу команди.

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

Аналітика — аудит поточного пошуку, збір статистики помилок. Вибір двигуна — pg_trgm, Meilisearch або Elasticsearch під ваш стек. Інтеграція — налаштування індексів, конфігурацій, API. Тестування — A/B-тест з реальними запитами, коригування порогів. Деплой — моніторинг та підтримка.

Терміни

pg_trgm (розширення, індекси, запити, tuning threshold): 1 день. Meilisearch (деплой, налаштування, синхронізація, API): 2–3 дні. Fuzzy в існуючому Elasticsearch: 1 день.

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

Конфігурація індексів та типів помилок. Інтеграція через REST API або SDK. Документація з експлуатації. Гарантія — виправимо баги протягом 2 тижнів.

Оцінимо реалізацію fuzzy search під ваші задачі. Отримайте консультацію — зв'яжіться з нами. Ми допоможемо підібрати оптимальне рішення та налаштувати його під ваш стек.

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