最近在优化部分业务的搜索吞吐率，结合之前优化过写请求的经验，想和大家讨论下我对es分片在不同场景下的分配策略的思路
原先普通索引我的分片策略是： 主分片=节点数，副本=1，这样可以保证业务数据一定的可用性（丢失一个节点数据完整），且书局是均匀的读写请求在各个节点也是均匀的。
该模式目前看来并不是一个最好的方案，首先对于写请求，请求会优先落到主分片，再由主分片下发到各个副本，默认半数节点同步完返回，主分片=机器数可以保证写请求负载均衡，而1个副本的情况下主分片写成功即可，所以该模式对写还是相对友好。
但是读场景下，由于多个分片分散在不同机器上，请求会从client node发布到各个分片号上取topN汇总，通一个分片号的分片不会出现在一台机器，所以虽然搜索请求还是负载均衡的，但是等于每个机器上都执行了一次搜索，而且有的分片上有目标数据有的没有，也会出现有的机器上执行的快，负载低；有的执行慢负载高。
那么针对读远大于写的这种case，我的方案是：主分片=1，副本=节点数-1。 这样能够保证每个节点一个分片，读请求在任意分片都是可执行的，而且主分片只有一个，意味着搜索请求既可以负载到任一节点执行，同一个请求又不会复制到多个机器执行，就能减少多余的查询开销。
当然了这样做对写就不友好了，首先多个副本，默认的测略是半数完成返回，理论上副本越多读延时越长，而且单个主分片意味着写请求会全都打到在主分片所在机器。不过对于写远小于读的场景应该是可以接受的。还有个问题就是读远大于写，可能会有半数分片没有同步完的执行了读，存在一定的数据不一致，这种可以通过调整weite.consistency为all来解决，只要写性能优先级不高。
所以最后我的结论是：
1.读远大于写的场景，可以减少主分片个数，增加副本数，提升读吞吐率，前提是写的优先级不高。极端情况下单分片多副本可以最大程度提升总的读吞吐。
2.写远大于读的场景，最大程度分配主分片个数，一个机器一个，并最大程度减少副本数（极端情况下集群规模不大且可用性优先级较低时可以不要副本）。
额外多说下，提到分片，segment作为更细粒度的分片，其相关策略可以类比，因为读请求也是要遍历各个segment的，因此读场景下适当减少segment能够减少segment的遍历。而合并segment也是开销比较大的动作，尽量在低峰期处理避免cpu load过高反噬读性能。
原先普通索引我的分片策略是： 主分片=节点数，副本=1，这样可以保证业务数据一定的可用性（丢失一个节点数据完整），且书局是均匀的读写请求在各个节点也是均匀的。
该模式目前看来并不是一个最好的方案，首先对于写请求，请求会优先落到主分片，再由主分片下发到各个副本，默认半数节点同步完返回，主分片=机器数可以保证写请求负载均衡，而1个副本的情况下主分片写成功即可，所以该模式对写还是相对友好。
但是读场景下，由于多个分片分散在不同机器上，请求会从client node发布到各个分片号上取topN汇总，通一个分片号的分片不会出现在一台机器，所以虽然搜索请求还是负载均衡的，但是等于每个机器上都执行了一次搜索，而且有的分片上有目标数据有的没有，也会出现有的机器上执行的快，负载低；有的执行慢负载高。
那么针对读远大于写的这种case，我的方案是：主分片=1，副本=节点数-1。 这样能够保证每个节点一个分片，读请求在任意分片都是可执行的，而且主分片只有一个，意味着搜索请求既可以负载到任一节点执行，同一个请求又不会复制到多个机器执行，就能减少多余的查询开销。
当然了这样做对写就不友好了，首先多个副本，默认的测略是半数完成返回，理论上副本越多读延时越长，而且单个主分片意味着写请求会全都打到在主分片所在机器。不过对于写远小于读的场景应该是可以接受的。还有个问题就是读远大于写，可能会有半数分片没有同步完的执行了读，存在一定的数据不一致，这种可以通过调整weite.consistency为all来解决，只要写性能优先级不高。
所以最后我的结论是：
1.读远大于写的场景，可以减少主分片个数，增加副本数，提升读吞吐率，前提是写的优先级不高。极端情况下单分片多副本可以最大程度提升总的读吞吐。
2.写远大于读的场景，最大程度分配主分片个数，一个机器一个，并最大程度减少副本数（极端情况下集群规模不大且可用性优先级较低时可以不要副本）。
额外多说下，提到分片，segment作为更细粒度的分片，其相关策略可以类比，因为读请求也是要遍历各个segment的，因此读场景下适当减少segment能够减少segment的遍历。而合并segment也是开销比较大的动作，尽量在低峰期处理避免cpu load过高反噬读性能。