ElasticSearch 类型和索引性能

Question

我想了解将多种类型的文档索引到单个索引的性能影响，其中每种类型的项目数量不平衡（一种类型有数百万个文档，而另一种类型只有数千个文档）。我在一些索引上发现了问题，排除类型是否在单个索引中单独索引（或不）对我有帮助。我可以假设类型是按照关系数据库的行单独索引的，其中每个表实际上都是独立的吗？

如果上述问题的答案是否定的，并且实际上所有类型都集中在一起，那么我将列出我正在做的其余工作，以尝试获得一些更详细的输入。

此示例的用例是为 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)。

Answer 1

我是否可以假设类型是按照关系数据库的行单独索引的，其中每个表实际上都是独立的？

不，如您所料，类型都集中在一个索引中。

有没有办法让我理解问题是否与特定索引中的文档总数有关、与“has_child”过滤查询的操作、其他一些糟糕的查询或构面设计或其他原因有关?

索引中的文档总数显然是一个因素。 has_child 查询是否特别慢是另一个问题 - 例如，尝试将 has_child 查询的性能与琐碎的 term 查询进行比较。 has_child documentation 在“内存注意事项”下提供了一条线索：

在当前实现中，所有_id 值都加载到内存（堆）中以支持快速查找，因此请确保有足够的内存供它使用。

这意味着任何有数百万潜在孩子的has_child 查询都需要大量内存。确保有足够的内存可用于此类操作，或者考虑重新设计以消除对has_child 的需求。