ES索引设计

Posted 2023-03-16

参考技术A

一个index可以被分为多个shards，从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。
每个分片都可以处理数据写入和查询请求，在设置索引分片数时，可从以下几个方面考虑：

一个shard就是一个lucene分片，ES底层基于lucene实现。
通常根据集群中的节点数量，对集群中的Shards数进行合理限制。

分片的大小和数量怎么设定？
注1： 小的分片会造成小的分段，从而会增加开销。我们的目的是将平均分片大小控制在几 GB 到几十 GB 之间。对于基于时间的数据的使用场景来说，通常将分片大小控制在 20GB 到 40GB 之间。

注2： 由于每个分片的开销取决于分段的数量和大小，因此通过 forcemerge 操作强制将较小的分段合并为较大的分段，这样可以减少开销并提高查询性能。 理想情况下，一旦不再向索引写入数据，就应该这样做。 请注意，这是一项比较耗费性能和开销的操作，因此应该在非高峰时段执行。

注3： 我们可以在节点上保留的分片数量与可用的堆内存成正比，但 Elasticsearch 没有强制的固定限制。 一个好的经验法则是确保每个节点的分片数量低于每GB堆内存配置20到25个分片。 因此，具有30GB堆内存的节点应该具有最多600-750个分片，但是低于该限制可以使其保持更好。 这通常有助于集群保持健康。

注4： 如果担心数据的快速增长, 建议根据这条限制: ElasticSearch推荐的最大JVM堆空间是 30~32G, 把分片最大容量限制为 30GB, 然后再对分片数量做合理估算。例如, 如果的数据能达到 200GB, 则最多分配7到8个分片。

索引和shard数并不是越多越好，对于批量读写都会有性能下降，所以要综合考虑性能和容量规划，同时配合压力测试，不存在真正的最优解。

索引的⽣命周期有五个阶段：

ES中open状态的索引都会占用堆内存来存储倒排索引，过多的索引会导致集群整体内存使用率多大，甚至引起内存溢出。所以需要根据自身业务管理历史数据的生命周期，如近3个月的数据open用于快速查询；过去3-6月的数据索引close以释放内存，需要时再开启；超过6个月的可以删除索引。

可以使用索引模板的方式按照一定时间创建新的索引，例如按天创建索引，索引的命名可能是index-yyyy-mm-dd，每天生成不同的索引，清除历史数据时可直接关闭或删除。