前面在介绍ES做TSDB的问题剖析中，说到了ES存储时序数据的存储容量特别大。
针对时序数据的存储容量大的问题。ES时序引擎以及TimeStream做了很多的优化工作，最终能将ES的存储容量降低到之前的十分之一。
存储容量的优化是如何做到的呢？
先来复习下ES存储容量大的几个原因：
- ES默认配置，创建了很多时序场景不需要的索引数据
- ES存储时序数据，元数据本身的存储容量使用空间过大。
- ES针对指标数据，在doc_values的压缩上效果不佳。
我将之前给出的基准数据的存储明细再贴出来，用以对比优化后的效果：
其中ES Synthetic Source（合成source）优化后，索引可以不再存储_source，这个优化是最明显的，存储空间直接减少了49.3%。
接下来是TimeStream的一些优化。
TimeStream支持通过参数，来去掉_id、_seq_no的存储。
不存储_id后，数据不再支持针对doc的删除和更新，但是这在时序场景，一般是不必须的。
不存储_seq_no，TimeStream使用阿里云自研的物理复制，可以不依赖_seq_no进行数据的复制和恢复，所以去掉_seq_no对ES功能影响不大，只是不能再使用CCR功能。如果不使用CCR，是可以关闭_seq_no的。
这样索引存储空间分别继续降低了9.6%和5.3%。整体的存储空间从1.2gb降低到了437.5mb。
接下来针对doc_values类型，阿里云codec插件（https://help.aliyun.com/document_detail/363036.html）支持对doc_values使用zstd压缩算法，通过将列式数据分成block，每个block使用zstd压缩，doc_values的数据可以得到极大的压缩，下面是开启doc_values后，字段的压缩效果：
- 指标字段：128.8mb -> 87.3mb
- 维度字段：34.8mb -> 163kb
- 时间字段：14.8mb -> 6mb
然后针对指标字段，不再需要存储BKD索引，如果真的有对指标数据进行query的需求，比如一些范围查询，可以通过ES的doc_values only的query能力支持。这样存储空间又进一步降低了129.7mb。
针对维度字段，首先只使用keyword索引，然后倒排索引也是用阿里云codec插件，将posting数据使用zstd压缩，存储空间可以从108.7mb降低为398.1kb。
所以优化后，整体的存储容量如下：
经过优化，存储空间从1.2gb降低到了114.5mb，存储容量直接减少到之前的十分之一。
