Elasticsearch / OpenSearch

Зачем

Реляционная БД отлично хранит и достаёт по primary key. Но как только пользователь хочет искать по любому слову в любом поле — LIKE '%iphone%' ставит на колени даже отлично индексированный Postgres. Полнотекстовый поиск, ранжирование по релевантности, faceted-фильтры, агрегации по миллиардам логов — это другой класс задачи, нужен inverted index + sharding + distributed merge.

Elasticsearch (и его OSS-форк OpenSearch) — это distributed Lucene: каждый shard — полноценный Lucene-индекс с inverted-структурой, поверх — cluster state machine, query coordinator и аналитический движок с агрегациями. Используется как secondary search index в продуктах (GitHub code search, Stack Overflow), как основной backend для ELK-стека (logs/metrics/observability), для e-commerce-фасетов (Amazon-style фильтры), для security analytics (SIEM).

Mental model

«Elasticsearch — это distributed Lucene с координатором: документ инвертируется на одном shard, поиск делается fan-out + merge, durability через WAL (translog), видимость в search появляется через 1 секунду после индексации (refresh). Это secondary index, не source of truth.»

Три ключевых уровня:

1. Lucene — на каждом shard. Хранит inverted index (term → posting list), term dictionary (FST — Finite State Transducer), посчитанные нормы для BM25. Immutable segments + WAL (translog) + периодический merge.
2. Shard — единица распределения. Hash-routing hash(_id) % primary_shards. У каждого shard есть primary + N replicas (для HA + read throughput).
3. Cluster — master node'ы держат cluster state (mapping, routing table, allocation), coordinator принимает клиентский запрос и делает fan-out на shards.

Два жизненных цикла внутри shard:

• Refresh (1s default): in-memory buffer → новый Lucene segment → документ виден в search. Это NRT (near real time), а не real time.
• Flush (~30 min или 512 MB translog): fsync segments на диск → truncate translog. Это durable checkpoint.

Что на диаграмме

• client — приложение / Kibana / curl, любой HTTP-клиент.
• coord — coordinator node. Это load-balancer + fan-out + merge. Любая нода может быть coordinator, но в больших кластерах их выделяют отдельно (node.roles: [coordinating_only]).
• master-1/2/3 — три выделенных master nodes. Они держат cluster state и согласуют его через vote-based quorum (с 7.0 заменил minimum_master_nodes). Их три, потому что нужно нечётное число для кворума и переживание отказа одного.
• data-1/2/3 (us-east-1a/b/c) — три data nodes в разных AZ. На каждой живут primary shards одних индексов и replica shards других.
• shard-A/B/C primary + replica — три primary shards индекса, разнесённых по нодам; replicas размещены в другой AZ (no single AZ failure).
• translog — WAL на диске у каждого shard. Append-only лог всех index/delete операций между flush'ами.

Edges:

• client -> coord — единственная точка входа для приложения.
• coord -> shard-X-primary — write path (после hash-routing).
• coord -> shard-X-{p|r} — read path (coord может выбрать любую копию).
• shard-X-p -> shard-X-r — synchronous replication primary → replicas (wait_for_active_shards).
• master-N <-> master-M — consensus для cluster state.
• master-1 -> coord — push нового cluster state (когда меняется mapping, allocation, node up/down).

Сценарии

Запись документа, end-to-end. Coord хеширует _id, форвардит на primary shard. Primary пишет в translog (WAL — для durability), параллельно анализирует текст (tokenize + lowercase + stemming), кладёт в in-memory buffer, форвардит на replicas. После ack'а от replicas — отвечает клиенту 201 Created. Но документ ещё не видим в search — он сидит в buffer'е до следующего refresh'а (1s default). Через 1s buffer становится новым Lucene segment, и документ появляется в выдаче.

Поиск + агрегация — два фазы. Query phase: coord фанаутит запрос на одну реплику каждого shard (round-robin), каждый shard локально находит top-K документов через Lucene + считает partial term counters для агрегации. Fetch phase: coord мерджит top-K от всех shards в global top-K, потом фанаутит запросы на конкретные shards за полным _source. Возвращает клиенту hits + aggregations. Это scatter-gather, и его стоимость = max(shard latency), плюс merge overhead.

Failure recovery. data-2 умирает (hardware failure). Master через 30s heartbeat timeout помечает node как gone, через кворум согласует новый cluster state: replica shard-B на data-1 промотируется в primary, для shard-B нужен новый replica — master выбирает свободный slot на data-3, новый primary стримит туда segments + translog. ~5 min — кластер снова GREEN. Writes во время recovery не блокируются (после промоушна), но redundancy временно деградирована (YELLOW).

Split-brain до 7.0. Сетевой раздел отрезает master-1 от master-2/3. master-2/3 выбирают нового лидера (себя), а master-1 не знает про partition и продолжает считать себя лидером. Клиенты на обеих сторонах пишут — divergent cluster states. После heal'а — данные несовместимы, merge без потери данных невозможен. Fix до 7.0: discovery.zen.minimum_master_nodes = N/2+1 — меньшая сторона не может elect leader. Fix 7.0+: vote-based quorum через cluster.initial_master_nodes. Урок: всегда 3 dedicated master nodes (нечётное), правильный quorum, и отдельные master/data роли.

Mapping explosion. Dynamic mapping без strict mode + миллионы уникальных field names (типичный случай — логи с request_param.search_query.iphone15, где значение запроса попадает в имя поля). Каждое новое поле — изменение cluster state, broadcast на все nodes. После 250K полей cluster state — 1.5 GB, master heap exhausted, full GC pauses 30s, cluster RED, индексирование отвергает запросы. Fix: index.mapping.total_fields.limit, dynamic: strict (или runtime), или тип flattened для подобъектов с произвольными ключами.

Trade-offs (ADR)

Elasticsearch vs Postgres FTS vs Algolia. Три точки на спектре ops cost / scale / features:

• Postgres FTS (tsvector + GIN + опционально pg_trgm для typo-tolerance): нулевая операционка (одна БД для всего), хорош до ~10M документов и QPS < 100. Минусы: нет distributed sharding, нет BM25 (только ts_rank), aggregations через GROUP BY дорого, faceted search катастрофически медленный на nested.
• Elasticsearch / OpenSearch: distributed Lucene, BM25, полный Query DSL, aggregations (terms/histogram/percentiles/cardinality), geo, vector hybrid (8.0+). Цена — операционная сложность (минимум 3 master + 3 data, JVM heap tuning ≤30 GB для compressed OOPS, ILM, schema discipline) и refresh delay (~1s eventually visible).
• Algolia: managed SaaS, sub-50ms p99 globally через ranking-as-a-service. Цена — $$$ ($500–50K/мес), vendor lock-in, невозможны сложные server-side aggregations.

Решение: до 10M docs и QPS < 100 — Postgres FTS. От 10M документов или сложные facets/aggregations — Elasticsearch/OpenSearch (предпочтительно OpenSearch на AWS из-за лицензии Elastic SSPL). Algolia — только если consumer UX latency < 50ms критичен и бюджет позволяет. ES/Algolia всегда secondary index — primary store Postgres/MySQL, индексируем через CDC (Debezium / outbox pattern), а не double-write.

Refresh interval: 1s default vs увеличенный для bulk. refresh_interval определяет, через сколько после индексации документ становится виден в search. Default 1s — комфортно для NRT UX (поиск через секунду после INSERT уже находит), но создаёт ~1 segment в секунду на shard, что давит на segment merging и тратит CPU/IO.

Решение:

• Production search index: refresh_interval=1s (NRT обязателен для UX).
• Bulk reindex / initial load: refresh_interval=-1 + replicas=0, после загрузки → forced refresh + восстановить replicas → 5–10x быстрее.
• Log indices (write-once, search редко): refresh_interval=30s — меньше segments, меньше merge, latency search +30s допустим для логов.

Реальные системы

• GitHub code search — Elasticsearch до 2023, потом ушли на самописный Blackbird на Rust (триграммы вместо традиционного inverted index, оптимизирован под код). Случай, когда ES перестало масштабироваться на специфическую workload.
• Stack Overflow — Elasticsearch для поиска по вопросам/ответам, миллиарды документов.
• Wikipedia (CirrusSearch) — full-text всех статей на ES, заменил Lucene-based старую систему.
• Cloudflare — Elasticsearch для recent logs, потом мигрировали часть на ClickHouse (cheaper for long-retention analytics, см. их блог про log analytics).
• Datadog — modified ES fork внутри для logs backend; масштабирование до петабайтов в день.
• Uber — log aggregation, observability stack на ES.
• OpenSearch (AWS fork) — после лицензионного спора с Elastic в 2021 (Elastic перешёл на SSPL, не OSI-approved). Стандарт на AWS, используется Spotify и многими другими.
• Bloomberg — internal search across financial data.
• ELK / Elastic Stack — стандарт для log aggregation в индустрии (Logstash/Beats → Elasticsearch → Kibana).

Anti-patterns

• ES как primary store / source of truth. Нет ACID, есть refresh delay, reindex неизбежен при изменении mapping. Всегда держите primary в Postgres/MySQL/Dynamo, индексируйте в ES через CDC или outbox.
• Dynamic mapping без strict mode. Логи с произвольными ключами (request_param.X.Y.Z) → mapping explosion → master OOM → cluster RED.
• Heavy parent-child / nested joins. Производительность падает катастрофически — Lucene не реляционная БД. Денормализуйте.
• One huge index. Rolling indices (по дням/неделям) + ILM (hot → warm → cold → frozen → delete) — иначе reindex и retention превращаются в боль.
• Too many small shards (<100 MB). Overhead на маршрутизацию выше профита. Целевой размер shard'а — 10–50 GB.
• Heap > 32 GB. Теряете compressed OOPS (32-bit references вместо 64-bit) → де-факто меньше usable heap. Держите ровно 30 GB или меньше, остальная RAM — file system cache (там живут hot Lucene segments).
• ES для key-value lookups. Дороже Postgres/Redis в разы. Если pattern — GET by id, ES не нужен.
• Кластер > 5 нод без dedicated master nodes. Master не должен бороться за CPU/heap с data workload.
• Force merge на active index. Segments лочатся, индексирование/поиск деградируют — делайте только на read-only индексах (после rollover).
• Aggregations на high-cardinality fields. terms aggregation на поле с миллионами уникальных значений может выжрать heap координатора. Используйте composite aggregation с пагинацией.

Когда НЕ использовать

• Маленький продукт, ≤ 10M документов, QPS < 100. Postgres FTS (tsvector + GIN + опционально pg_trgm) дешевле в эксплуатации и достаточно функционален.
• Аналитика на петабайтах с долгой retention. ClickHouse / Druid / Pinot выигрывают по cost-per-GB и latency на агрегациях в разы (columnar storage). Cloudflare ушли с ES на ClickHouse именно поэтому.
• Чистый key-value / counter store. Redis / Dynamo / Postgres. ES — overkill.
• Strong consistency / ACID транзакции. ES — eventually consistent, refresh delay 1s, no multi-document transactions.
• Vector search как primary use case. ES 8.0+ имеет vector support, но Qdrant / Weaviate / pgvector специализированы и часто быстрее/проще.
• Простой product search до 50M docs с минимальной операционкой. Meilisearch / Typesense — single-binary, без JVM, typo-tolerance из коробки.

Дальше читать

• [CONCEPT]sharding — hash vs range routing, hot shards (ES использует hash routing по default).
• [CONCEPT]lsm-tree — Lucene segments концептуально близки к LSM (immutable + merge), хотя структура иная.
• [CONCEPT]wal-write-ahead-log — translog в ES это WAL; параметры durability=request vs async.
• [CONCEPT]cap-theorem — ES в обычном режиме AP (eventually consistent через refresh).
• [CASE]search-autocomplete — поиск с подсказками, типичный use case для ES completion suggester или edge ngram.
• Книги: Elasticsearch in Action, 2nd ed. (Shukla, Kumar) — актуальнее «Definitive Guide»; Lucene in Action (Hatcher, Gospodnetic) для внутренностей.
• Docs: Elasticsearch reference, OpenSearch, Lucene.
• Engineering blogs: GitHub Blackbird code search, Cloudflare logs ES → ClickHouse.
• Papers: BM25 and Beyond (Robertson & Zaragoza) — ranking function в Lucene с 5.0.