我想了解将多种类型的文档索引到单个索引的性能影响，其中每种类型的项目数量不平衡（一种类型有数百万个文档，而另一种类型只有数千个文档）。我在我的一些索引上发现了问题，排除类型是否在单个索引中单独索引（或不）会对我有所帮助。我可以假设类型是按照关系数据库的行单独索引的，其中每个表都是有效分离的吗？
如果上面的答案是否定的，并且类型实际上都集中在一起，那么我将列出我正在做的其余部分，以尝试获得一些更详细的输入。
此示例的用例是为 Twitter 用户捕获推文（为清楚起见，将其称为所有者）。我有一个多租户环境，每个 twitter 所有者都有一个索引。也就是说，专注于单一所有者：
- 我将来自每个时间线的推文（提及、直接消息、我的推文和完整的“家庭”时间线）捕获到一个索引中，每种时间线类型在 ElasticSearch 中都有不同的映射
- 每条推文都引用一个父类型，即创作推文的用户（可能是也可能不是所有者），具有父映射。所有时间线类型只有一个“用户”类型
- 我只在单个查询中搜索和分面一个所有者，因此我不必担心自己搜索多个索引
- 主时间线可能会捕获数百万条推文，而所有者自己的推文可能会导致成百上千条
- 用户文档会定期使用 Twitter 时间线之外的信息进行更新，因此我想避免（如果可能）我必须在多个索引中保持同一用户对象的多个副本同步的情况
我注意到查询具有数百万个文档的索引的响应要慢得多，即使排除了索引数百万个文档的“主时间线”类型，只留下具有几千个条目的类型。由于推文和用户之间的父子关系，我不想将类型拆分为单独的索引（除非我必须这样做）。
有没有办法我可以理解问题是否与特定索引中的文档总数有关，与“has_child”过滤查询的操作有关，或者其他一些糟糕的查询或方面设计，或其他原因？
任何输入将不胜感激。
编辑
澄清推文按时间线存储的声明。这意味着为 home_timeline、my_tweets_timeline、mentions_timeline、direct_messages_timeline 等定义了一个 ElasticSearch 类型，它们对应于您在标准 twitter.com UI 中看到的内容。因此，推文集之间存在自然分裂，尽管也有一些重叠。
我已经回去检查 has_child 查询，这在这一点上是一个明确的红鲱鱼。对较大索引的基本查询要慢得多，即使查询只有几千行的类型 (my_tweets_timeline)。