集群资源评估

磁盘空间评估

我们考虑磁盘空间时主要有以下几方面的考虑:

  • 索引膨胀: 当向ES写入数据时,ES内部默认情况下会把原始数据也存储,同时也会在每个字段上都建立索引,所以相比原始数据来说ES内的数据量是有膨胀的;但是ES存储的数据都会有压缩,从我们的观察看基本能够跟索引膨胀抵消。一般情况下可以认为索引膨胀不影响容量。这个膨胀率会随着ES的配置参数不同而不同,相关性比较大的是_all和_source,目前_all 默认是禁用的,_source 是打开的,用户如果不需要查询原始的文档内容,可以把_source 也禁用,那么会降低磁盘使用量。
  • ES 内部开销:ES内部需要定期的做各个segment之间的合并,来减少segment的数目,释放删除的doc占用的空间,合并过程中原始的数据会保留,并写出新的一份数据,此时的数据量会翻倍,但是ES并不会同时做所有的segment的合并,它只会选择一部分segment做合并。
  • 应急开销:有时可能有节点宕机后,ES会把数据重新分布到别的节点上,此时每个节点都需要一定的空间来接收数据。因为为merge预留的空间也可以给应急开销使用,所以可以综合第2点和第3点一起计算,实际中磁盘的实际使用率为70%就比较高了,如果超过70%就需要报警。
  • 副本的数量。

综合以上4点,可以得到磁盘空间的总量 = 原始数据量 1.0 副本数 / 0.7

除了测试之外,我们建议副本数量至少为2,此时磁盘空间 = 原始数据量 * 2.8, 在大部分情况下用户都可以用磁盘空间这一个指标结合所选的套餐来估算节点的数目。

shard 相关评估

  • 每一个shard内部都维护了一个单独的lucene的索引,各个shard之间的索引互相不会合并,lucene的索引很多信息都在jvm内存里,比如FST, DocValue的索引元数据信息,FieldInfos信息,这些信息会占用大量的JVM内存,考虑到JVM的指针压缩功能,ES建议JVM的内存不要超过30G,在这个约束下我们建议一个节点上的shard数目建议控制在500个以下,不要超过1000个。
  • 特别大的shard会导致异常情况下shard在节点之前的迁移非常慢,一旦宕机恢复时间比较长;一个shard非常大时查询延时也会比较高,建议一个shard的大小控制在10G-30G之间是比较合适的,基本能达到比较好的查询性能,不要超过100G。