关于嵌套vs父/子文档的缩放

Question

我正在运行一个概念验证，让我们在ES中对更多“标准化”数据运行嵌套查询。

e.g。嵌套

客户 - ＆gt;       - 姓名
      - 电子邮件       - 事件 - ＆gt;             - 创建             - 输入

现在我的情况是，可以将给定客户的事件列表移动到另一个客户。例如客户A有50个活动 客户B有5000个活动

我现在想要将所有事件从客户A转移到客户B

在数百万客户的规模和运行查询的UI中，图表是父/子更合适还是应该嵌套能够处理它？

我的情况有哪些优点和缺点？

Answer 1

很难给你甚至粗略的性能指标，如“嵌套已经足够好”，但我可以给你一些有关嵌套vs父/子的详细信息，可以提供帮助。我仍然建议进行一些基准测试，以验证性能是否可以接受。

<强>嵌套

• 嵌套文档彼此存储在相同的Lucene块中，这有助于读取/查询性能。读取嵌套文档的速度比等效的父/子快。
• 更新嵌套文档中的单个字段（父级或嵌套子级）会强制ES重新索引整个嵌套文档。对于大型嵌套文档来说，这可能非常昂贵
• 更改“父级”意味着ES将：删除旧文档，使用较少嵌套数据重新索引旧文档，删除新文档，使用新嵌套数据重新索引新文档。

<强>父/子

• 子项与父项分开存储，但路由到同一个分片。因此，父/子在读/查询上的性能略低于嵌套
• 父/子映射有一点额外的内存开销，因为ES在内存中维护一个“连接”列表
• 更新子doc不会影响父级或任何其他子级，这可能会在大型文档上节省大量索引
• 更改父级意味着您将删除旧的子级文档，然后在新的父级下索引相同的文档。

Nested可能会正常工作，但如果你认为有很多“数据改组”的可能性，那么父/子可能更适合。嵌套最适合嵌套数据不经常更新但经常读取的情况。对于数据更频繁移动的安排，父/子更好。