elasticsearch单索引过大问题

动态api可以直接增加副本数，但是增加了副本数写入性能会受影响。
集群的datanode有几台呢？
或者可以考虑下用rollover的方案，但是这个改动会比较大。

单个分片的索引数量，集群的总分片数，一次搜索需要处理的数据量，执行什么样的搜索语句，这些都是影响搜索性能的关键因素。
怎么处理好这些影响因素，怎么根据业务特点制定合适的索引策略，用什么样的搜索语句去获取搜索结果，这些都是需要好好考虑和好好设计的。很明显，环境中出现了这种异常索引，说明索引策略是有问题的，需要整改索引策略。
如果数据量不是很大，比如最大的索引还只有20亿条，如果这个增长是经历了很久才长上来的，那么最简单的做法是增加索引的分片，这样就可以使得每个分片的索引数量不会太大了，因为ES底层的lucene搜索时，都是针对分片维度进行的。
但是增加分片数只能针对新生成的索引，所以如果想改善旧索引的搜索性能，可以把现在的索引reindex到新的索引中（在集群比较空闲的时候做）
如果数据量增长比较快，那么简单的增加分片就无法解决查询性能问题了，就需要更精细化的索引策略了。比如数据搜索时，会携带时间维度信息，那么索引可以按天或者按月（根据数据特点来定）生成，这样搜索时先根据时间确定索引范围，然后再执行搜索，这样可以大大提高搜索性能。当然，如果数据搜索没有按天/月搜索的一些属性，比如是需要全局搜索的，这个时候索引的生成策略可以考虑在业务上做细化，比如某些业务的放在一个索引里。
如果不好按时间生成索引，也可以考虑rollover机制，这种策略就是等到数据量积累到一定程度后，再生成一个新的索引，比较适合一些时间上数据量的变化不好评估的数据。
滚动也好，按时间生成新索引也好，都是为了控制单个分片的数据量不太大。但是如果数据量大到一定程度，每次需要搜索的东西，需要匹配或处理的东西很多时，也会碰到搜索瓶颈，这时就需要根据业务特点，做更精细化的索引分配，搜索时尽量减少索引搜索范围。
总之，索引策略需要结合业务特点进行设计，简单快捷的可以考虑按时间生成新索引，按数据量rollover索引，扩大索引分片数量等

我们在实际环境上测试过,主分片数越多,查询速度越快

可以用reindex增加分片数