ES 索引分片数、副本数优化

 

分片(shard):一个ES的index由多个shard组成,每个shard承载index的一部分数据。

副本(replica):index也可以设定副本数(number_of_replicas),也就是同一个shard有多少个备份。对于查询压力较大的index,可以考虑提高副本数(number_of_replicas),通过多个副本均摊查询压力

shard数量(number_of_shards)设置过多或过低都会引发一些问题:shard数量过多,则批量写入/查询请求被分割为过多的子写入/查询,导致该index的写入、查询拒绝率上升;对于数据量较大的inex,当其shard数量过小时,无法充分利用节点资源,造成机器资源利用率不高 或 不均衡,影响写入/查询的效率。

对于每个index的shard数量,可以根据数据总量、写入压力、节点数量等综合考量后设定,然后根据数据增长状态定期检测下shard数量是否合理。腾讯云CES技术团队的推荐方案是:

  • 对于数据量较小(100GB以下)的index,往往写入压力查询压力相对较低,一般设置3~5个shard,number_of_replicas设置为1即可(也就是一主一从,共两副本) 。
  • 对于数据量较大(100GB以上)的index: 一般把单个shard的数据量控制在(20GB~50GB) 让index压力分摊至多个节点:可通过index.routing.allocation.total_shards_per_node参数,强制限定一个节点上该index的shard数量,让shard尽量分配到不同节点上 综合考虑整个index的shard数量,如果shard数量(不包括副本)超过50个,就很可能引发拒绝率上升的问题,此时可考虑把该index拆分为多个独立的index,分摊数据量,同时配合routing使用,降低每个查询需要访问的shard数量。

 

具体案例:

      京东客服备战双十一时,有一个index的数据量 2.2G ,集群的信息是 8个 dataNode,开始的时候创建索引时,shard=8,replica=1(历史),当进行压测的时候,TPS=2500的时候,当tps=2500时   TP99=50S,  TP999=53S, AVG=10S,具体见下图:

 

发现对这个index进行查询已经严重超时,碰到这个问题,我们开始分析,首先看了一下其他es查询的耗时是否正常,发现在同一个集群的其他index没有出现严重超时的问题,从而排除集群网络等其他不稳定的原因。我们确定应该是这个index的问题。

打算重建index,新的index,1个shard  ,7个replica (es集群有8台机器)

tps=2500时   TP99=180ms,  TP999=500ms, AVG=100ms   ,avg降低了100倍从下图也可以看到,当TPS不断增大超过2500时,TP999也是超过1000ms的。

 

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页