好的想法是十分钱一打,真正无价的是能够实现这些想法的人。

有关elasticsearch分片策略的总结

Elasticsearch | 作者 code4j | 发布于2018年10月12日 | 阅读数:5763

最近在优化部分业务的搜索吞吐率,结合之前优化过写请求的经验,想和大家讨论下我对es分片在不同场景下的分配策略的思路
 
原先普通索引我的分片策略是: 主分片=节点数,副本=1,这样可以保证业务数据一定的可用性(丢失一个节点数据完整),且书局是均匀的读写请求在各个节点也是均匀的。
 
原来.png


该模式目前看来并不是一个最好的方案,首先对于写请求,请求会优先落到主分片,再由主分片下发到各个副本,默认半数节点同步完返回,主分片=机器数可以保证写请求负载均衡,而1个副本的情况下主分片写成功即可,所以该模式对写还是相对友好。
 
但是读场景下,由于多个分片分散在不同机器上,请求会从client node发布到各个分片号上取topN汇总,通一个分片号的分片不会出现在一台机器,所以虽然搜索请求还是负载均衡的,但是等于每个机器上都执行了一次搜索,而且有的分片上有目标数据有的没有,也会出现有的机器上执行的快,负载低;有的执行慢负载高。
 
那么针对读远大于写的这种case,我的方案是:主分片=1,副本=节点数-1。 这样能够保证每个节点一个分片,读请求在任意分片都是可执行的,而且主分片只有一个,意味着搜索请求既可以负载到任一节点执行,同一个请求又不会复制到多个机器执行,就能减少多余的查询开销。
 
修改后.png


当然了这样做对写就不友好了,首先多个副本,默认的测略是半数完成返回,理论上副本越多读延时越长,而且单个主分片意味着写请求会全都打到在主分片所在机器。不过对于写远小于读的场景应该是可以接受的。还有个问题就是读远大于写,可能会有半数分片没有同步完的执行了读,存在一定的数据不一致,这种可以通过调整weite.consistency为all来解决,只要写性能优先级不高。
 
所以最后我的结论是:
 
1.读远大于写的场景,可以减少主分片个数,增加副本数,提升读吞吐率,前提是写的优先级不高。极端情况下单分片多副本可以最大程度提升总的读吞吐。
 
2.写远大于读的场景,最大程度分配主分片个数,一个机器一个,并最大程度减少副本数(极端情况下集群规模不大且可用性优先级较低时可以不要副本)。
 
额外多说下,提到分片,segment作为更细粒度的分片,其相关策略可以类比,因为读请求也是要遍历各个segment的,因此读场景下适当减少segment能够减少segment的遍历。而合并segment也是开销比较大的动作,尽量在低峰期处理避免cpu load过高反噬读性能。
 
 
 
 
已邀请:

fanmo3yuan

赞同来自:

这个应该与数据量和查询场景有关吧,当数据比较大时,多个分片或许会更好

要回复问题请先登录注册