1.Shards数量规划
一个index可以被分为多个shards，从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。
每个分片都可以处理数据写入和查询请求，在设置索引分片数时，可从以下几个方面考虑：
- 每个shard包含的数据条数越多，查询性能会降低（建议1亿条左右，最多建议不超过4亿）。
- 建议单个分片保存的数据量在20GB左右，最大不超过30GB。
- 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说，预计存储的数据量越大，应当分配的shard越多，分布式查询的优势越明显。如果确认某个index的数据量非常少（如一年不到1GB），那么过多的分配shard，反而可能不如单shard的性能好
- 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
- 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大28G为例，单实例管理的shard数保持在500以内。
一个shard就是一个lucene分片，ES底层基于lucene实现。
通常根据集群中的节点数量，对集群中的Shards数进行合理限制。
cluster.max_shards_per_node * number of non-frozen data nodes
分片的大小和数量怎么设定？
注1：小的分片会造成小的分段，从而会增加开销。我们的目的是将平均分片大小控制在几 GB 到几十 GB 之间。对于基于时间的数据的使用场景来说，通常将分片大小控制在 20GB 到 40GB 之间。
注2：由于每个分片的开销取决于分段的数量和大小，因此通过 forcemerge 操作强制将较小的分段合并为较大的分段，这样可以减少开销并提高查询性能。 理想情况下，一旦不再向索引写入数据，就应该这样做。 请注意，这是一项比较耗费性能和开销的操作，因此应该在非高峰时段执行。
注3：我们可以在节点上保留的分片数量与可用的堆内存成正比，但 Elasticsearch 没有强制的固定限制。 一个好的经验法则是确保每个节点的分片数量低于每GB堆内存配置20到25个分片。 因此，具有30GB堆内存的节点应该具有最多600-750个分片，但是低于该限制可以使其保持更好。 这通常有助于集群保持健康。
注4：如果担心数据的快速增长, 建议根据这条限制: ElasticSearch推荐的最大JVM堆空间是 30~32G, 把分片最大容量限制为 30GB, 然后再对分片数量做合理估算。例如, 如果的数据能达到 200GB, 则最多分配7到8个分片。
2.索引（index）数量
索引和shard数并不是越多越好，对于批量读写都会有性能下降，所以要综合考虑性能和容量规划，同时配合压力测试，不存在真正的最优解。
- 大索引需要拆分：增强性能，风险分散。
反例：一个10T的索引，例如按date查询、name查询
正例：index_name拆成多个index_name_${date}
正例：index_name按hash拆分index_name_{1,2,3,...100..}
3.索引生命周期
索引的⽣命周期有五个阶段：
- Hot（热）：索引处于活动状态，能够更新（增改删）和查询。
- Warm（暖）：处于该阶段的索引不再支持更新，但是能够被查询。
- Cold（冷）： 该阶段的索引不再支持更新，只能支持很少的查询，查询较慢！
- Frozen（冻结）：该阶段的所有不再支持更新，也很少查询，查询很慢！
- Delete（删除）：索引不再需要可以被安全删除。
ES中open状态的索引都会占用堆内存来存储倒排索引，过多的索引会导致集群整体内存使用率多大，甚至引起内存溢出。所以需要根据自身业务管理历史数据的生命周期，如近3个月的数据open用于快速查询；过去3-6月的数据索引close以释放内存，需要时再开启；超过6个月的可以删除索引。
可以使用索引模板的方式按照一定时间创建新的索引，例如按天创建索引，索引的命名可能是index-yyyy-mm-dd，每天生成不同的索引，清除历史数据时可直接关闭或删除。
网友评论