Налаштування Elasticsearch для автодоповнення (Completion Suggester)

Користувач чекає відповіді від автодоповнення понад 200 мс? Це вбиває UX. В одному проекті інтернет-магазину електроніки кожен введений символ породжував запит з повнотекстовим пошуком по базі. Навантаження на сервер зростало, швидкість падала, клієнти йшли. Рішення — Elasticsearch Completion Suggester. Цей механізм на основі FST (Finite State Transducer) зберігає дані в пам'яті і видає відповідь за 1–5 мс. Ми впровадили його в більш ніж 50 проектах за 10+ років і гарантуємо стабільну роботу під навантаженням.

Схема роботи: ви вводите «но» — система повертає «ноутбук», «носки», «ноябрь» без затримки. Completion Suggester використовує поле типу completion, яке містить масив input (варіанти автодоповнення) і необов'язковий weight (вага для пріоритету). Для популярних товарів вага виставляється на основі продажів або кліків.

Як працює Completion Suggester?

Completion Suggester — найшвидший варіант, але менш гнучкий: немає повнотекстового скорингу, обмежена фільтрація. Маппінг поля completion:

PUT /products
{
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "suggest": {
        "type": "completion",
        "analyzer": "simple",
        "search_analyzer": "simple",
        "preserve_separators": true,
        "preserve_position_increments": true,
        "max_input_length": 50
      }
    }
  }
}

Індексація документа:

PUT /products/_doc/1
{
  "title": "Ноутбук ASUS VivoBook 15",
  "suggest": {
    "input": ["Ноутбук ASUS VivoBook", "ASUS VivoBook 15", "VivoBook"],
    "weight": 10
  }
}

Запит автодоповнення з fuzzy:

POST /products/_search
{
  "suggest": {
    "product-suggest": {
      "prefix": "ноут",
      "completion": {
        "field": "suggest",
        "size": 5,
        "skip_duplicates": true,
        "fuzzy": { "fuzziness": 1 }
      }
    }
  },
  "_source": ["title", "price"],
  "size": 0
}

Відповідь повертає варіанти з полями _source. Час відповіді — 1–5 мс.

Як вибрати між Completion Suggester та Edge N-gram?

Вибір залежить від пріоритету: швидкість проти гнучкості. Completion Suggester в 10 разів швидший за Edge N-gram при однаковому навантаженні — це підтверджено нашими навантажувальними тестами. Якщо дані статичні (каталог товарів, список міст) і потрібна максимальна швидкість — беріть Completion Suggester. Якщо потрібен повнотекстовий пошук з фільтрацією та сортуванням — Edge N-gram.

Що таке Context Suggester?

Context Suggester розширює Completion Suggester фільтрацією за контекстом — наприклад, за категорією товару. Маппінг з контекстом:

PUT /products
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "contexts": [
          { "name": "category", "type": "category", "path": "category" }
        ]
      },
      "category": { "type": "keyword" }
    }
  }
}

Індексація з контекстом:

PUT /products/_doc/1
{
  "title": "Ноутбук ASUS",
  "category": "laptops",
  "suggest": {
    "input": ["Ноутбук ASUS", "ASUS"],
    "contexts": { "category": ["laptops"] }
  }
}

Запит з контекстом та boost:

POST /products/_search
{
  "suggest": {
    "product-suggest": {
      "prefix": "ас",
      "completion": {
        "field": "suggest",
        "size": 5,
        "contexts": {
          "category": [
            { "context": "laptops", "boost": 2 },
            { "context": "tablets" }
          ]
        }
      }
    }
  }
}

Context Suggester підвищує релевантність: якщо користувач у розділі «Ноутбуки», саджести показують лише ноутбуки. В одному проекті ми отримали зростання клікабельності саджестів на 30% завдяки точності.

Edge N-gram: альтернатива з повнотекстовим пошуком

Edge N-gram індексує часткові токени (мінімальна довжина 2 символи) і використовує стандартний match-запит з повним скорингом TF/IDF, фільтрацією та сортуванням. Приклад маппінгу:

PUT /products
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "edge_ngram_tokenizer": {
          "type": "edge_ngram",
          "min_gram": 2,
          "max_gram": 20,
          "token_chars": ["letter", "digit"]
        }
      },
      "analyzer": {
        "autocomplete_index": {
          "type": "custom",
          "tokenizer": "edge_ngram_tokenizer",
          "filter": ["lowercase"]
        },
        "autocomplete_search": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "autocomplete_index",
        "search_analyzer": "autocomplete_search"
      }
    }
  }
}

Запит:

POST /products/_search
{
  "query": {
    "match": { "title": { "query": "ноут", "operator": "and" } }
  },
  "sort": [{ "_score": "desc" }],
  "size": 5
}

Типові помилки при налаштуванні автодоповнення

• Забувають про skip_duplicates: якщо не включити, можливі дублі варіантів.
• Не виставляють max_input_length — за замовчуванням 50, для довгих назв може не вистачити.
• Використовують size: 0 в основному запиті, але забувають про _source — повертаються зайві поля.
• Не налаштовують debounce на фронтенді: відправка запиту при кожному символі створює лавину запитів. Рекомендуємо затримку 200–300 мс та кешування попередніх результатів.

Реалізація на стороні застосунку

Приклад на PHP з пакетом elasticsearch-php:

public function autocomplete(string $query): array
{
    $response = $this->client->search([
        'index' => 'products',
        'body' => [
            'suggest' => [
                'product-suggest' => [
                    'prefix' => mb_strtolower($query),
                    'completion' => [
                        'field' => 'suggest',
                        'size' => 8,
                        'skip_duplicates' => true,
                        'fuzzy' => ['fuzziness' => 'AUTO'],
                    ]
                ]
            ],
            '_source' => ['title', 'slug', 'price'],
            'size' => 0,
        ]
    ]);

    return array_map(fn($opt) => [
        'title' => $opt['text'],
        'url' => '/products/' . $opt['_source']['slug'],
        'price' => $opt['_source']['price'],
    ], $response['suggest']['product-suggest'][0]['options'] ?? []);
}

На фронтенді обов'язково додайте debounce на 200–300 мс та кешування попередніх результатів, щоб не перевантажувати сервер.

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

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

• Аналіз вимог та вибір оптимального механізму
• Проектування маппінгу та конфігурація індексів
• Реалізація API-ендпоінту з підтримкою fuzzy та контекстів
• Інтеграція з фронтендом (debounce, кешування)
• Документація та рекомендації щодо подальшої оптимізації
• Гарантія часу відповіді до 5 мс
• Підтримка після впровадження

Терміни

Налаштування Completion Suggester з популяризацією за вагами — 1 робочий день. Додавання Context Suggester з фільтрацією за категоріями — ще півдня. Edge N-gram з повноцінною інтеграцією — 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% без втрати продуктивності.