ElasticSearch类型和索引性能

Question

我想了解将多种类型的文档索引到单个索引的性能影响，其中每种类型的项目数量不平衡（一种类型有数百万个，其中另一种类型只有数千个文件）。我在我的一些索引中发现了一些问题，并排除了类型是否在单个索引内分别索引（或不是）会对我有所帮助。我能否假设类型是按照关系数据库的各行分别索引的，而每个表格是有效分离的？

如果上面的答案是否定的，而且这些类型实际上都集中在一起，那么我将阐述我正在做的其他尝试以获得更详细的输入。

本示例的用例是为Twitter用户捕获推文（为了清楚起见，将其称为所有者）。我有多租户环境，每个叽叽喳喳拥有者一个索引。这就是说，着眼于一个单一的所有者：

• 我捕捉来自各个时间表鸣叫（提到，直接的信息，我的微博，并全面“家”的时间表）成一个单一的指标，与具有各自的时间表类型ElasticSearch中的不同映射
• 每条推文都是指父类型，即使用父映射创作推文（可能是也可能不是所有者）的用户。对于所有时间线类型，只有一个“用户”类型
• 我在单个查询中只搜索一个所有者，因此我不必关心自己搜索多个索引
• 家庭时间表可能会捕捉数以百万计的推文，其中所有者自己的推文可能会导致数百或数千个用户文档定期更新，其Twitter信息时间线之外的信息会定期更新，因此我希望避免（如果可能的话）保持多个索引同一用户对象的多个副本同步

我注意到很多s即使排除了包含数百万文档索引的“家庭时间线”类型，只留下几千条条目的类型，对数百万个文档的索引查询响应也较低。由于推文和用户之间的父子关系，我不想将这些类型拆分为单独的索引（除非必须）。

有没有一种方法可以理解，如果问题是与特定索引中的文档总数，与'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的需求。