我们正在从ES 2.3.2跳到6.0。作为这项工作的一部分，我们将整体索引分解为多个索引。我们的索引分为23个分片，每个分片大约50 GB。我们正在做两件事：
1）将我们的类型（我们有26种具有广泛变化的字段的类型）拆分为单独的索引 2）创建基于日期的索引
我们正在做＃1，因为不推荐使用映射类型。
我们正在做＃2，因为80％的查询都来自过去30天的数据。我们确实有查询可以追溯到所有时间。此外，我们的数据是可变的（任何日期的任何文档都可以更新），因此我们在api中管理索引定位。
我现在要处理的是，当我们将这一切分开时，对于一些较大的类型，这非常有效。对于较小的索引，我们最终得到的索引一旦按类型和日期分割，就非常小（例如~100 mb）。我担心对于小型类型，我们最终会得到15个（我们有15个月的保留期）索引，这些索引都很小，这使得搜索效率低下。这真的很糟糕吗？我做了一个测试，折叠较小的，没有基于日期，但我发现性能实际上下降了。我假设这是因为所有数据都在一个分片中（我将它设置为一个分片），并且搜索无法并行化。
我的根本问题是找出是否存在将少量数据分布在多个索引上而不是在一个索引中并置的惩罚？我们确实需要基于日期的较大类型，并且管理日期与非日期的混合是不可取的。
感谢， 〜约翰
答案 0 :(得分：0)
如果你能从时间切片指数中获得所需的表现。我会采用这种方法。一个简单的索引策略比使用另一个系统根据大小管理索引数量更好。