Elasticsearch与Clickhouse的对比分析
ClickHouse 和 Elasticsearch 是两种不同的数据存储和分析工具，各自在不同的用例和场景下发挥着作用。
-
数据类型：
- ClickHouse：主要用于结构化数据，特别擅长处理大规模的数据仓库和分析场景，支持 SQL 查询。
- Elasticsearch：适用于非结构化或半结构化数据，特别擅长全文搜索和日志分析，支持文本分析、全文搜索和地理位置查询等。
-
查询语言：
- ClickHouse：支持标准的 SQL 查询语言。
- Elasticsearch：使用自己的查询语言 DSL（Domain Specific Language），也支持基于 JSON 的查询。
-
分布式能力：
- ClickHouse：设计用于处理大规模数据，支持水平扩展。
- Elasticsearch：同样支持水平扩展，并且具有强大的分布式搜索和分析能力。
-
索引：
- ClickHouse：使用列式存储，通常情况下需要提前定义表结构。
- Elasticsearch：使用倒排索引，对文本搜索和分析非常有效，并且不需要提前定义模式。
-
数据更新：
- ClickHouse：主要用于批量加载和批量查询，不太适合频繁的数据更新操作。
- Elasticsearch：支持实时索引，可以实时索引、搜索和查询数据。
-
用例：
- ClickHouse：适用于大规模数据分析、OLAP（联机分析处理）场景，比如数据仓库、报表分析等。
- Elasticsearch：适用于全文搜索、日志分析、实时监控等实时数据处理场景。
-
复杂性：
- ClickHouse：相对于 Elasticsearch，更偏向于传统的数据仓库和分析，相对较复杂。
- Elasticsearch：更加灵活，但在大规模数据仓库和复杂 SQL 查询方面可能稍显不足。
核心点对比：
字段类型对比：
参考的文章：
1、一文看懂 ClickHouse vs Elasticsearch：谁更胜一筹？
主要对比了CH和ES的设计原理上的区别，做了一些查询性能对比。
携程的日志系统从ES迁移到ClickHouse的经历，主要核心点：
1）ClickHouse比ES硬件成本低：相同数据占用的磁盘空间只有ES的 1/3 到 1/30。
2）ClickHouse比ES读写性能更好：ClickHouse 的查询速度比ES快 5-30 倍以上。
3、Fast and Reliable Schema-Agnostic Log Analytics Platform
Uber的日志系统从ES迁移到ClickHouse的过程（使用ReplicatedMergeTree Table）：
1）常用字段作为“固定字段”。
2）通过array类型解决“动态字段”的问题，查询速度比普通字段稍慢。
3）通过保存的字段信息构造SQL查询。
4）分析字段的使用情况，将常用的“动态字段”变更为“固定字段”，提升性能。
5）对上层应用（Kibana dashboards）做了透明迁移，上层无感知。
效果：
1）硬件资源消耗减少一半以上。
2）数据写入延迟1分钟以内。
3）查询性能比ES强。
4、Handling Variable Time Series Efficiently in ClickHouse
在ClickHouse中处理时序指标时，对于变化的“指标字段”，对比了几种建表方式在数据压缩率和性能方面的差异。
介绍了B站基于Clickhouse的日志存储经验。
主要介绍滴滴日志检索场景从 ES 迁移到 CK 的技术探索。
小结：
1、ClickHouse资源消耗比ES低，读写性能比ES强。
2、“动态字段问题”ClickHouse可以通过array或者map、nested类型来解决。
3、ES在集群管理上比ClickHouse简单，ClickHouse的表在集群模式下使用ReplicatedMergeTree和Distributed引擎，集群搭建和运维比ES复杂。
4、ClickHouse生态没有ES完善。
5、ES对全文检索的支持比ClickHouse好。
6、ES对数据更新的支持比ClickHouse好。
参考：
https://pixeljets.com/blog/clickhouse-vs-elasticsearch/
