分片（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的。
