为什么弃用Elasticsearch
es 使用痛点
对于开发来说：
- 大批量数据查询导致 es 的 CPU 飙升。
- 数据量增大之后，es 的查询效率下降，影响接口性能。
- 聚合效率低。
对于运维来说：
- 维护成本很大，在数据量大的情况，es 占用磁盘空间很大，没有很好的压缩手段。
- es 很占内存，内存配置为整体内存的一半。
问题记录
缓存计算系统评分导致 es 的 cpu 飙升。
系统评分需要查询 es 的流量信息进行计算，实时查询很慢。做了定时任务计算分数信息并作缓存。
- 经常发现 es 的 cpu 会被打满。排查发现随着系统的增多，当定时任务跑的时候，批量查询 es 次数太多的时候，es的 cpu 会持续飙升。
业务场景分析
云监控采集的平台数据以流量数据为主，主要是用来进行分析的。
数据一经存入，极少进行增改删操作。是一个很典型的 OLAP（联机分析处理） 场景
ck 和 es 的对比
优点:
- 硬件资源成本更低，同等场景下，Clickhouse占用的资源更小。
- 人力成本更低，新人学习、开发单测以及测试方面都更加友好，更容易介入。
- OLAP场景下Clickhouse比Elasticsearch更适合，聚合计算比Elasticsearch更精确、更快，更节省服务器计算资源。
- 写入性能更高，同等情况下是Elasticsearch的5倍，写入时消耗的服务器资源更小。
- Elasticsearch在大量导出情况下频繁GC，严重可能导致宕机，不如Clickhouse稳定。
- 查询性能平均是Elasticsearch的12.7倍，Clickhouse的查询性能受服务器配置影响较小。
缺点：
- 关联查询不如单表查询效率高，而且差距很明显。
- 云监控业务场景极少有关联查询。
- 在高并发查询上支持的不如Elasticsearch支持的更好。
- 由于平台是 toB的，不会有很大的 QPS。意味着不会有太多高并发查询。
云监控真实性能对比
- 压测环境对比组件查询效率提高10倍。
- 压测环境对比组件写入和更新效果不明显。