Налаштування Elasticsearch для фасетного пошуку з агрегаціями

Налаштування Elasticsearch для фасетного пошуку з агрегаціями

Уявіть каталог з мільйоном товарів. Без фасетного пошуку користувач гортає 200 сторінок. З ним — за секунду знаходить потрібний бренд і ціновий діапазон. Але лічильники брешуть, якщо не налаштувати post_filter і global aggregations. У цій статті розберемо, як зібрати коректні фасетні лічильники на Elasticsearch, уникнувши типових помилок. Економія часу розробки при використанні готового рішення — до 30%.

Ми інтегруємо Elasticsearch з фасетним пошуком у каталогах та інтернет-магазинах. Це фільтри-лічильники: «Бренд: Samsung (143), Apple (89)», «Ціна: до 30 000 (234), 30–60 000 (145)». При виборі фільтра список товарів звужується, а лічильники інших значень перераховуються. У реляційних базах такі операції дорогі — GROUP BY з COUNT(*) по відфільтрованій вибірці. В Elasticsearch задача вирішується агрегаціями часто за єдиний запит. Оцінимо ваш проект і реалізуємо під ключ за 2–4 робочі дні.

Як реалізувати коректні лічильники фасетів?

Типовий запит для каталогу: пошуковий запит + активні фільтри + агрегації для підрахунку фасетів. Приклад базового запиту:

POST /products/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "ноутбук" } }
      ],
      "filter": [
        { "term": { "is_active": true } },
        { "range": { "price": { "gte": 20000, "lte": 80000 } } }
      ]
    }
  },
  "aggs": {
    "by_brand": {
      "terms": {
        "field": "brand",
        "size": 20,
        "order": { "_count": "desc" }
      }
    },
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "key": "до 30 000", "to": 30000 },
          { "key": "30–60 000", "from": 30000, "to": 60000 },
          { "key": "60–100 000", "from": 60000, "to": 100000 },
          { "key": "від 100 000", "from": 100000 }
        ]
      }
    },
    "price_stats": {
      "stats": { "field": "price" }
    },
    "by_category": {
      "terms": { "field": "category", "size": 10 }
    },
    "by_rating": {
      "histogram": { "field": "rating", "interval": 1, "min_doc_count": 1 }
    }
  },
  "size": 20,
  "from": 0
}

Проблема зникаючих лічильників при виборі фасета

Якщо користувач обирає бренд «Samsung» і додає його в filter, агрегація by_brand рахує тільки всередині відфільтрованої вибірки. Лічильники інших брендів обнуляються — користувач не бачить, скільки товарів в інших брендів. Рішення — Post Filter у поєднанні з Global Aggregation:

POST /products/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "ноутбук" } }
      ],
      "filter": [
        { "term": { "is_active": true } }
      ]
    }
  },
  "post_filter": {
    "bool": {
      "filter": [
        { "term": { "brand": "Samsung" } }
      ]
    }
  },
  "aggs": {
    "all_brands": {
      "global": {},
      "aggs": {
        "filtered_brands": {
          "filter": {
            "bool": {
              "must": [
                { "match": { "title": "ноутбук" } }
              ],
              "filter": [
                { "term": { "is_active": true } }
              ]
            }
          },
          "aggs": {
            "brands": {
              "terms": { "field": "brand", "size": 20 }
            }
          }
        }
      }
    },
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "key": "до 30 000", "to": 30000 },
          { "key": "30–60 000", "from": 30000, "to": 60000 },
          { "key": "від 60 000", "from": 60000 }
        ]
      }
    }
  },
  "size": 20
}

Згідно з документацією Elasticsearch, post_filter застосовується до результатів після агрегації, а global агрегація виходить за межі контексту query. post_filter застосовується до результатів після агрегації. Агрегації рахуються по всій вибірці (до post_filter), тому лічильники брендів залишаються коректними. global агрегація виходить за межі контексту query — дозволяє рахувати агрегати по всіх документах індексу з додатковими фільтрами.

Як працювати з вкладеними атрибутами?

Якщо атрибути (розмір, колір, матеріал) зберігаються як nested об'єкти:

"mappings": {
  "properties": {
    "attributes": {
      "type": "nested",
      "properties": {
        "name": { "type": "keyword" },
        "value": { "type": "keyword" }
      }
    }
  }
}

Агрегація по вкладеним атрибутам:

"aggs": {
  "attributes": {
    "nested": { "path": "attributes" },
    "aggs": {
      "attribute_names": {
        "terms": { "field": "attributes.name", "size": 50 },
        "aggs": {
          "attribute_values": {
            "terms": { "field": "attributes.value", "size": 20 }
          }
        }
      }
    }
  }
}

Це дворівневі вкладені агрегації: спочатку групуємо за ім'ям атрибута («Колір», «Розмір»), всередині кожної групи — значення («Чорний», «Білий»).

Cardinality — підрахунок унікальних значень

Для відображення «Знайдено 1 247 товарів від 89 брендів» використовуйте агрегацію cardinality з полем brand і precision_threshold 100. Це гарантує точність до 100 унікальних значень, вище — похибка 1–6%.

Налаштування фасетного пошуку за 5 кроків

1. Визначте поля для фільтрації: бренд, ціна, категорія, рейтинг, атрибути. Типовий набір — 5–10 полів.
2. Налаштуйте маппінг: для ключових полів використовуйте тип keyword, для вкладених — nested. Переконайтеся, що поля для агрегацій не аналізуються.
3. Побудуйте запит з агрегаціями: включіть всі потрібні агрегації (terms, range, histogram, nested). Для коректних лічильників використовуйте post_filter і global агрегації.
4. Застосуйте post_filter: відокремте фільтри від основного query. Це збереже лічильники агрегацій.
5. Оптимізуйте продуктивність: використовуйте execution_hint: map для полів з низькою кардинальністю, кешування для агрегацій без пошукового запиту, обмежте size до 20.

Оптимізація агрегацій

terms агрегація з великим size — дорога операція: кожен шард повертає top-N значень, координуючий вузол мержить результати. Для висококардинальних полів (тисячі унікальних значень) продуктивність падає. Способи оптимізації:

Порівняння типів агрегацій

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

PHP клас для побудови фасетних запитів:

class FacetedSearchService
{
    public function search(array $params): array
    {
        $query = $this->buildQuery($params);
        $response = $this->client->search([
            'index' => 'products',
            'body' => $query,
        ]);

        return [
            'hits' => $response['hits']['hits'],
            'total' => $response['hits']['total']['value'],
            'facets' => $this->extractFacets($response['aggregations']),
        ];
    }

    private function extractFacets(array $aggs): array
    {
        $facets = [];

        if (isset($aggs['by_brand'])) {
            $facets['brand'] = array_map(fn($b) => [
                'value' => $b['key'],
                'count' => $b['doc_count'],
            ], $aggs['by_brand']['buckets']);
        }

        if (isset($aggs['price_ranges'])) {
            $facets['price'] = array_map(fn($r) => [
                'label' => $r['key'],
                'count' => $r['doc_count'],
            ], $aggs['price_ranges']['buckets']);
        }

        return $facets;
    }
}

Що входить в налаштування фасетного пошуку під ключ

• Проектування схеми маппінгів та індексів.
• Налаштування агрегацій усіх типів (terms, range, nested, cardinality).
• Реалізація логіки post_filter + global aggregations для коректних лічильників.
• Оптимізація продуктивності (execution_hint, кешування).
• Написання серверного коду для побудови запитів та обробки відповідей.
• Документація, навчання команди, підтримка після впровадження.

Терміни

• Базова реалізація (3–5 типів агрегацій) — 2 робочі дні.
• Складний сценарій (post_filter, global, nested) — 3–4 дні.
• Оптимізація на реальних обсягах (>5 млн документів) — додатковий день.

Наша команда має 6+ років досвіду в Elasticsearch та сертифікованих інженерів. Ми реалізували понад 50 проектів з фасетним пошуком, гарантуючи точність лічильників та продуктивність. Зв'яжіться з нами для консультації — допоможемо уникнути дорогих помилок. Вартість розраховується індивідуально, а економія від впровадження може досягати 40 000 ₽ на етапі розробки та до 20 000 ₽ на місяць на інфраструктурі. Отримайте готове рішення з повною документацією та підтримкою.

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