Elasticsearch & ClickHouse 存储成本比较

在上一篇文章（Elasticsearch & ClickHouse 存储效能对比）中，我们比较了ES和CK在数据集的压缩存储方面的效能，ClickHouse的压缩存储其实并没有特别的魔法，使用的列存方式和压缩算法其实都是业内常见的，因为其数据结构是以列存方式专门针对这种结构化数据的OLAP场景的，因此可以做到一个比较高的压缩比率。而Elasticsearch是一个使用场景非常广泛的数据库，其默认数据结构配置是支持高并发、高可用、可全文检索的非结构化数据的搜索需求，但同时也是提供doc_value, BKD tree等方式支持高效存储数据的。要达到CK类似的效果，需要有针对性的进行优化。

我们在做技术选型的时候，往往首先需要先比较两个技术是否能够满足我们的需求，再去考量很多类似成本，维护性，售后方面的需求。看似容易，但实际上因为技术本身的复杂性，一些比较往往因为不够全面而失真，导致得出不正确的结论。

回到本文的重点，我们之前讨论过压缩率的问题，但对原始数据的压缩率与存储成本并不是划等号的，压缩率只是总体存储成本中的一个因素，在实际的场景中，我们有多种手段可以降低我们的存储成本，包括我们数据处理的方式，存储方式，存储介质，存储策略都会最终影响到。我们已经讨论过压缩率的问题，接下来，看一下数据处理，存储方式、介质、策略等方面的因素。

不做任何数据处理和存储方面的优化

在不做任何数据处理和存储方面的优化时，即便我们做了一些数据压缩层面的优化，ES和CK的存储成本大概是这样的：

image.png

即ES因为索引膨胀，或者说是数据压缩的问题，在同等原始数据下，需要使用更多的存储和计算资源去支撑数据量，并且，我们数据留存时间越长，这种成本就越多。

通过数据处理降低存储成本：Rollup + transform

但ES作为一个非常成熟的大数据产品，其提供了更多的方式协助我们降低成本。在日志场景下，大多都有实时分析的需求，即对于day 0的当天实时数据，有做实时分析需求，这部分数据我们是不动的。而对于day 1之后的数据，我们可以考虑通过上卷或者转置、聚合（rollup + transform）的方式，由明细数据变为汇总数据。此时同样能支撑OLAP分析

Elasticsearch提供以下用于处理数据的方法：

• 汇总您的历史数据 Elastic Stack数据汇总功能提供了一种汇总和存储历史数据的方法，以便仍可以将其用于分析，但只花费原始数据的存储成本的一小部分。
• 转换数据 转换使您能够将现有的Elasticsearch索引转换为汇总索引，这为新的见解和分析提供了机会。

比如，我们可以把原本以ms为单位统计的网络流量信息，通过rollup，转换为以分钟单位的汇总信息。或者把以用户的行为日志，通过transform，group by为以用户为在不同埋点路径上的点击、耗时的汇总表。

此时，day1之后的数据成本是可以缩减的：

image.png

通过存储方式和介质降低成本

我们可能要问，我们本身就有日志数据存储的需求，不够能只存储上卷和转置之后的数据，原始的数据还是要存储的。ES通过每日生成快照的方式来解决这个问题：

image.png

我们可以通过配置索引生命周期管理（ILM）和快照生命周期管理（SLM）的功能，来保证原始数据的存储。当我们对数据有审计需求，查询需求，或者新的分析需求的时候，我们可以通过restore/ reindex的功能，恢复数据。

另外，我们可以通过最新的可搜索快照功能，减少在day 0的数据存储成本。

image.png

我们可以在生命周期管理（ILM）策略中的热层策略，配合rollover功能，开启可搜索快照功能来减少50%的存储成本。开启该功能后，ES先通过rollover来切分索引，当索引被切分出来之后，即备份到快照中，然后通过searchable snapshot功能来支持数据的高可用和failure over处理，并自动将对应所以的副本数降为0；当出现分片丢失或者节点故障时，自动通过可搜索快照功能进行恢复。

此时，在没有高并发的日志分析场景，我们可以完全不适用副本。成本模型如下图：

image.png

通过存储策略降低成本

对于时序型数据来说，数据的热度，或者说访问评率，重要性等会随着时间的流逝而慢慢降低。对于day 30 或者 day 180之后的数据，我们通常可以采用成本更低的存储来支撑，比如将SSD换成机器磁盘，将机器磁盘换成对象存储或者共享文件存储。 ES支持热、温、冷的层次更丰富的架构，而非简单的可读写数据与只读数据的区分。

image.png

并且，我们可以通过最新的可搜索快照的冷冻层的功能，做到计算和存储的分离，将远期的离线数据完全放在cos等对象存储中。甚至可以通过云服务的灵活性，平时完全不保留计算资源，在需要的时候再添加节点或者新建集群，来后将冷冻层的可搜索快照挂载为索引，提供远期数据的在线可查特性

image.png

此时的成本模型为：

image.png

总结

本文中，我主要列出了在一些存储成本上我们可以采集的方法。在进行成本估算的时候，我们不能只看压缩率一个指标，我们需要综合分析一个产品，或者说一个解决方案是不是给你提供了一套完整的，可用的，稳定的数据治理，数据维护的工具，方便我们能够更好的达成对数据的控制。这里主要介绍了ES在数据处理，数据治理上的一些功能，或许CK也能做到（或在未来做到）, 希望上文提到的一些方法能够给大家以帮助。