Elasticsearch: налаштування нечіткого пошуку для обробки помилок друку

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Elasticsearch: налаштування нечіткого пошуку для обробки помилок друку
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    948

Користувач вводить у пошук «наутбук» замість «ноутбук» або «javascipt» замість «javascript» — і йде, не знайшовши потрібний товар. Ми вирішуємо цю проблему налаштуванням нечіткого пошуку в Elasticsearch. В основі — метрика редакційної відстані Левенштейна: кількість односимвольних операцій (вставка, видалення, заміна, перестановка сусідніх символів), необхідних для перетворення одного рядка в інший. Докладніше — в відстані Левенштейна.

Такі помилки друку — причина до 30% порожніх результатів пошуку у великих інтернет-магазинах. Наші інженери з 5-річним досвідом в Elasticsearch допомагають налаштувати нечіткий пошук під ключ. Ми гарантуємо, що 99% помилок користувачів будуть оброблені коректно, а швидкість пошуку залишиться прийнятною навіть на індексах з мільйонами документів. Замовте безкоштовну консультацію — ми проаналізуємо ваш пошуковий профіль та запропонуємо оптимальні параметри.

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

Головний параметр — fuzziness. Він визначає, скільки помилок допускається. AUTO краще фіксованого fuzziness: 2 у 5 разів за точністю на коротких запитах.

Значення Опис Приклад для запиту "ноутбук" (8 символів)
0 Точний збіг Тільки «ноутбук»
1 1 операція редагування «ноутбук», «ноутбу» (видалення)
2 2 операції «ноутбук», «наутбук» (заміна), «ноубук» (видалення+заміна)
AUTO 0 для довжини 1-2, 1 для 3-5, 2 для 6+ Для «ноутбук» (8) → 2

AUTO — оптимальний вибір у більшості випадків. Примусовий fuzziness: 2 для коротких запитів дає багато хибних збігів.

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

Без prefix_length кожен токен індексу стає кандидатом для fuzzy-розширення. Для індексу з 10 млн документів це може призвести до десятків тисяч операцій вводу-виводу. Встановлення prefix_length: 2 скорочує кількість кандидатів у десятки разів. Для бази з технічними термінами (коди, артикули) рекомендуємо збільшити до 3-4.

Приклад fuzzy-запиту

POST /products/_search
{
  "query": {
    "fuzzy": {
      "title": {
        "value": "наутбук",
        "fuzziness": "AUTO",
        "prefix_length": 2,
        "max_expansions": 50,
        "transpositions": true
      }
    }
  }
}

prefix_length — перші 2 символи мають збігатися точно. Це критичний параметр продуктивності: без нього fuzziness: 2 для однолітерного запиту «а» теоретично збіжиться з величезною кількістю токенів. Встановлюйте мінімум 1–2.

max_expansions — максимальна кількість варіантів, у які розширюється нечіткий запит. За замовчуванням 50 — зазвичай достатньо.

transpositions — дозволити перестановки сусідніх символів (ab → ba). За замовчуванням увімкнено. Відповідає відстані Дамерау-Левенштейна.

Порівняння підходів: fuzzy vs match з fuzziness

Критерій fuzzy-запит match-запит з fuzziness
Аналіз запиту Ні, сире значення Так, токенізація та нормалізація
Застосування До одного поля До кожного токена після аналізу
Граматичні форми Не враховуються Враховуються (стемінг, синоніми)
Рекомендація Для унікальних ідентифікаторів Для користувацьких пошукових рядків

Комбінування точного та нечіткого пошуку

Найкращий патерн — запускати точний і нечіткий пошук паралельно, точні результати мають займати топ видачі:

POST /products/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "multi_match": {
            "query": "наутбук",
            "fields": ["title^3", "description"],
            "boost": 2
          }
        },
        {
          "multi_match": {
            "query": "наутбук",
            "fields": ["title^3", "description"],
            "fuzziness": "AUTO",
            "prefix_length": 2,
            "boost": 1
          }
        }
      ]
    }
  }
}

Точний збіг з бустом 2 буде вище нечіткого. Документи з точним збігом піднімуться в топ, нечіткі опиняться нижче — але все одно потраплять у видачу.

Наш досвід: кейс інтернет-магазину електроніки

Клієнт — магазин з 500 тис. товарів. Користувачі часто вводили бренди з помилками: «самсунг», «самсун», «сamsung». Ми налаштували нечіткий пошук з fuzziness: AUTO та prefix_length: 2 для полів title, brand, description. Час пошуку зріс на 15%, але частка нульових результатів знизилася з 8% до 0,5%. Додатково встановили phonetic-аналізатор для англійських брендів (Double Metaphone). Економія бюджету на доопрацювання — близько 30% завдяки використанню вбудованих механізмів Elasticsearch без купівлі сторонніх рішень.

Як налаштувати нечіткий пошук покроково?

  1. Створіть індекс з маппінгом полів, де потрібен нечіткий пошук.
  2. Виберіть аналізатор (стандартний, phonetic при необхідності).
  3. У запиті використовуйте multi_match з fuzziness: AUTO.
  4. Встановіть prefix_length: 2 для продуктивності.
  5. Протестуйте на вибірці типових помилок.
  6. Відрегулюйте параметри при необхідності.

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

  • Аналіз типових помилок друку та патернів пошуку ваших користувачів.
  • Налаштування маппінгу індексу з урахуванням нечіткого пошуку (вибір полів, аналізаторів).
  • Конфігурація fuzziness, prefix_length, max_expansions під ваші дані.
  • Оптимізація продуктивності (профілювання, налаштування шардів).
  • Тестування на реальному наборі запитів, коригування.
  • Документація та передача доступу до індексу.
  • Навчання вашої команди роботі з нечітким пошуком.

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

Базова налаштування (fuzziness + параметри) — 1 робочий день. Якщо потрібен phonetic-аналіз або інтеграція зі змішаною російсько-англійською базою — ще 1 день. Вартість розраховується індивідуально. Зв'яжіться з нами — оцінимо ваш проект безкоштовно. Отримайте консультацію прямо зараз!

Наші сертифіковані спеціалісти Elastic (5+ років досвіду) реалізували понад 20 проектів з нечітким пошуком у продакшені. Гарантуємо: якщо результат не влаштує — доопрацюємо безкоштовно.

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

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

Стек Коли використовувати
Laravel + Octane CRUD, бізнес-логіка, REST/GraphQL API, адмінки
Node.js (Fastify) Realtime WebSocket, streaming, serverless, висока I/O concurrency
Go Високонавантажені мікросервіси (>10k RPS), gRPC, DevOps-інструменти
Django + DRF ML-пайплайни, інтеграція з AI, складна обробка даних
Ruby on Rails Швидкий MVP з багатим екосистемою гемів

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

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

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

Роль Деталі
Кеш Кешування результатів важких запитів, фрагментів HTML
Черги Backend для Laravel Queue / Celery
Session store Distributed sessions в multi-instance оточенні
Pub/Sub Realtime події між сервісами
Rate limiting Sliding window counters для API throttling
Leaderboards Sorted Sets для рейтингів

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

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

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

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

Задача Термін
REST API для мобільного/SPA (середня складність) 6–12 тижнів
Backend зі складною бізнес-логікою + інтеграції 12–20 тижнів
Високонавантажений сервіс на Go 8–16 тижнів
Міграція legacy PHP на Laravel 16–32 тижні

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