Elasticsearch / OpenSearch vs ClickHouse¶

Сравнения · Раздел 02

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Область: Elasticsearch8.19 / OpenSearch2.19; ClickHouse25.8. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.

Критерии выбора¶

Критерий	Elasticsearch8.19 / OpenSearch2.19	ClickHouse25.8
Workload	Full-text relevance, inverted term lookup	Wide analytical scans и aggregate computation
Consistency	Document operation; search refresh отдельно от durability	Parts/query snapshot и engine-specific convergence
Latency	Selective text search; expensive aggregation может нагружать heap	Column pruning, vectorized scan; point lookup не главный path
Throughput	Analysis, refresh, replicas и segment merges	Batch ingest, parts/merges, distributed aggregation
Cost	Index expansion, heap, replicas, snapshot storage	Column compression, sorting, replication, merge CPU
Scalability	Shards/replicas и routing; oversharding дорого	Shards/replicas и sorting design; skew/fan-out дорого
Operational complexity	Mappings/analyzers, refresh, allocations; OS segment mode отдельно	Sorting keys, merge backlog, Keeper и MV correctness

flowchart LR
  Events --> Search[Text search projection]
  Events --> CH[Analytical projection]
  Search --> UI[Investigation UI]
  CH --> UI

Конкретные сценарии¶

Найти похожие descriptions suspicious payments → search engine. Revenue per bookmaker/day с corrections → CH latest-version aggregation. Investigation UI может использовать оба projections от одного durable event stream; версии и completeness должны быть наблюдаемы.

Ограничения и отказы¶

ES и OS не одинаковые версии одного продукта; OS2.19 segment replication меняет replica cost/freshness. Наличие aggregations не делает search идеальной OLAP базой, наличие LIKE не делает CH relevance engine.

Как принять и проверить решение¶

Зафиксировать query mix, data distribution/skew, payload, working set, retention, concurrency, authoritative boundary и допустимую stale-read policy. Проверять steady state и maintenance, lost ACK, node loss, replay и restore. Сопоставлять total cost при одинаковых durability/replication requirements. Не объявлять универсального победителя по одному среднему времени запроса.

Типичные ошибки проектирования¶

Сравнивать default eventual/cache path с durable transactional commit; игнорировать operations/recovery; переносить benchmark другого dataset; выбирать продукт до определения access pattern.

Вопросы на собеседовании¶

Можно ли использовать варианты вместе? Да, если роли, data contracts и способы reconciliation определены. Дополнительная projection добавляет lag, replay и ownership, поэтому её польза должна покрывать эту сложность.

Практические упражнения¶

Для одного сценария выше составьте ADR: invariant, выбранный вариант, отклонённая альтернатива, failure outcomes и план измерений. Не задавайте придуманные TPS/SLA; перечислите входные данные, необходимые для sizing.