集群索引数建议？

一个集群可以容纳的索引的数量（准确的说是shard数据量)和shard的大小以及数据结点的数量和硬件配置有关，因此不可能有一个统一的标准。 最好通过监控数据来做容量管理，如果一个数据结点的heap压力很大，load过高导致查询或者写入慢，就应该考虑扩容加节点了。理论上集群可以容纳的索引数据量可以通过增加数据结点来无限水平扩展，但实际集群的元信息是无法水平扩展的，因为ES在设计上是在每个节点缓存了集群元信息的全量拷贝。当集群规模较大的时候（节点比较多，shard比较多，字段比较多)的情况下，更新元信息的开销也随之增大。直观上的感受就是创建/删除索引，或者update setting/mapping一类的操作比较慢，一次操作耗时可能达到数秒。
 
因此建议尽量控制索引和shard的数量，比如如果一天的数据量很小，不一定非要一天一个索引，可以考虑1周或者1个月一个索引，甚至一天数据很少的时候，一个shard也许就够了，而不是用5个或者10个shard。  
ES 5.0以后的shrink和rollover api也可以用来对历史冷数据做shard的缩减，对于查询频率比较低的历史数据，缩减shard数量能节省大量的集群资源。
 
万一所有手段都用了，shard数量依然很多，则可以考虑搭建多个集群，采用tribe node互联，或者在应用层面制定一定的路由规则，将数据分散到多个集群。

楼上说的很有道理，其实主要还是看你集群和业务数据，官方建议一个索引10个shard，每个shard最好不要超过50G，数据冷热可以搞起来，数据量小的该合并的合并。该优化的都优化了，还是有问题，那就加节点、分集群吧