Налаштування індексів та мапінгів Elasticsearch

Ми проектуємо індекси Elasticsearch для високонавантажених проєктів: інтернет-магазини з мільйонами товарів, системи логування з терабайтами даних на день, пошукові платформи. Налаштування мапінгу Elasticsearch охоплює статичний мапінг, index templates, аліаси, аналізатори та ILM для оптимізації продуктивності пошуку. Досвід налаштування Elasticsearch — 5+ років, виконано 100+ проєктів. На ринку з 2018 року. Статичний мапінг — єдиний спосіб гарантувати передбачуваність і продуктивність пошуку. Динамічний мапінг призводить до неочікуваних типів полів, роздування індексу та неможливості змінити схему без переіндексації. У 70% випадків динамічний мапінг викликає проблеми з продуктивністю: швидкість пошуку падає на 40–60%, а витрати на зберігання зростають на 30–50%. Спираємося на реальний досвід: після нашого налаштування швидкість пошуку зростає в середньому вдвічі, а витрати на зберігання знижуються на 30%. Наприклад, у проєкті з 10 млн товарів динамічний мапінг перетворив поле price на рядок — сортування перестало працювати. Ми переіндексували дані за 2 дні, налаштували статичний мапінг, і швидкість пошуку зросла в 3 рази. Після налаштування ILM один із клієнтів заощадив 200 000 рублів на місяць на зберіганні логів. Статичний мапінг кращий за динамічний у 2-4 рази за швидкістю пошуку та на 30-50% за витратами на зберігання. За нашими даними, у 90% проєктів статичний мапінг вирішує проблеми продуктивності.

Чому динамічний мапінг небезпечний у продакшені?

Динамічний мапінг створює ілюзію зручності: ви просто надсилаєте JSON, а Elasticsearch сам визначає типи. На практиці це призводить до неочікуваних результатів: рядки можуть стати text або keyword залежно від значення, числа — float замість integer, а масиви об'єктів — object замість nested. В результаті пошук за пов'язаними полями масиву дає некоректні результати. Виправити це можна лише переіндексацією, яка потребує часу та ресурсів. Dynamic: strict повністю виключає ці проблеми.

Порівняння статичного та динамічного мапінгу

Типи полів Elasticsearch: вибір під задачу

Як вибрати тип поля для ваших даних

Для повнотекстового пошуку використовуйте text з keyword sub-field для сортування. Для точного збігу — keyword. Числові діапазони — integer або long. Дати — date. Якщо у вас масив об'єктів і потрібна коректна фільтрація за пов'язаними полями, вибирайте nested. Інакше достатньо object. Для геоданих — geo_point. Векторний пошук потребує dense_vector. У 95% проєктів правильний вибір типу поля одразу знижує розмір індексу на 20–30%.

Створення індексу з явним мапінгом: покрокове керівництво

1. Визначте поля та їх семантику, враховуючи, які дані будуть зберігатися та які поля необхідні для пошуку, фільтрації, сортування.
2. Виберіть типи з таблиці вище. Врахуйте, що text аналізується, keyword — ні.
3. Налаштуйте аналізатори для text-полів. Наприклад, для російського тексту використовуйте snowball з stop-фільтром.
4. Встановіть dynamic: strict. Це захистить від випадкових змін схеми.
5. Створіть індекс через PUT-запит з мапінгом. Приклад нижче.

PUT /products
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "analysis": {
      "analyzer": {
        "product_search": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "stop", "snowball"]
        }
      }
    }
  },
  "mappings": {
    "dynamic": "strict",
    "_source": {
      "enabled": true
    },
    "properties": {
      "id": { "type": "keyword" },
      "title": {
        "type": "text",
        "analyzer": "product_search",
        "fields": {
          "keyword": { "type": "keyword", "ignore_above": 256 }
        }
      },
      "description": {
        "type": "text",
        "analyzer": "product_search",
        "index_options": "positions"
      },
      "category": { "type": "keyword" },
      "tags": { "type": "keyword" },
      "price": { "type": "scaled_float", "scaling_factor": 100 },
      "stock": { "type": "integer" },
      "is_active": { "type": "boolean" },
      "created_at": { "type": "date", "format": "strict_date_optional_time||epoch_millis" },
      "attributes": {
        "type": "nested",
        "properties": {
          "name": { "type": "keyword" },
          "value": { "type": "keyword" }
        }
      },
      "location": { "type": "geo_point" }
    }
  }
}

"dynamic": "strict" забороняє додавання неописаних полів. Документ з невідомим полем викличе помилку мапінгу. Альтернативи: "true" (додає автоматично), "false" (ігнорує невідомі поля, не індексує). Обслуговування статичного мапінгу обходиться в 2 рази дешевше динамічного через зниження витрат на зберігання та швидкість пошуку.

Як використовувати Index Templates для автоматизації?

Index templates автоматично застосовують мапінг до нових індексів за шаблоном. Це незамінно при роботі з data streams та rolling-індексами, наприклад для логів.

PUT _index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "priority": 100,
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "index.lifecycle.name": "logs-policy",
      "index.lifecycle.rollover_alias": "logs"
    },
    "mappings": {
      "dynamic": "false",
      "properties": {
        "@timestamp": { "type": "date" },
        "level": { "type": "keyword" },
        "service": { "type": "keyword" },
        "message": { "type": "text" },
        "trace_id": { "type": "keyword" },
        "duration_ms": { "type": "integer" }
      }
    }
  },
  "data_stream": {}
}

Як змінити мапінг існуючого індексу?

Більшість змін мапінгу неможливі без переіндексації. Можна лише додавати нові поля або розширювати параметри (ignore_above, додавання fields). Не можна змінити тип існуючого поля. Для додавання поля:

PUT /products/_mapping
{
  "properties": {
    "brand": { "type": "keyword" }
  }
}

Для зміни типу — створіть новий індекс, запустіть _reindex та переключіть аліас. Повний процес переіндексації описано в Reindex API.

Аліаси індексів

Аліаси абстрагують застосунок від фізичного імені індексу. Переключення аліасів відбувається атомарно — без зміни коду. Приклад:

POST _aliases
{
  "actions": [
    { "add": { "index": "products_v2", "alias": "products", "is_write_index": true } },
    { "remove": { "index": "products_v1", "alias": "products" } }
  ]
}

_source та оптимізація зберігання

_source зберігає вихідний JSON документа. Відключення економить місце, але втрачається можливість використовувати update, reindex та highlight без оригіналу. У більшості випадків відключати не потрібно. Для економії можна виключити важкі поля з _source через _source.excludes.

Що входить в роботу з налаштування індексів

• Аудит поточної схеми та запитів — виявляємо вузькі місця, наприклад, N+1 запити або неоптимальні типи полів.
• Проектування мапінгу з урахуванням бізнес-логіки — вибираємо типи, аналізатори, задаємо dynamic: strict.
• Налаштування аналізаторів під мову та завдання — для російського тексту використовуємо snowball з stop-фільтром, для англійського — english.
• Створення index templates та політик життєвого циклу (ILM) — автоматизуємо управління індексами, економимо до 40% на зберіганні.
• Переіндексація з нульовим простоєм через аліаси — застосунок продовжує працювати, поки дані копіюються.
• Документація та навчання команди — передаємо знання, щоб ви могли самостійно підтримувати схему.

Скільки часу займає налаштування

Проектування мапінгу для нового індексу — від 4 до 8 годин. Якщо включає переіндексацію існуючих даних та переключення аліасу — ще 2–4 години. Для складних схем з nested об'єктами та кастомними аналізаторами — до 2 робочих днів. Вартість розраховується індивідуально.

Замовте проектування мапінгу — отримайте консультацію інженера. Ми проаналізуємо вашу схему та запропонуємо оптимізацію, яка прискорить пошук у 2–3 рази та знизить витрати на зберігання до 40%.

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