elasticsearch - 关于嵌套与父/子文档的缩放

Question

我正在为我们运行一个概念证明，以便在 ES 中对更多“规范化”数据运行嵌套查询。

例如嵌套

客户 -> - 姓名
- 电子邮件 - 事件 -> - 创建 - 类型

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

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

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

在我的情况下有什么优点和缺点？

Answer 1

很难为您提供诸如“嵌套足够好”之类的粗略性能指标，但我可以为您提供一些有关嵌套与父/子的详细信息，这可能会有所帮助。我仍然建议进行一些基准测试以验证性能是否可以接受。

嵌套

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

家长/孩子

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

Nested 可能会正常工作，但如果您认为有可能进行大量“数据洗牌”，那么 Parent/Child 可能更合适。嵌套最适合嵌套数据不经常更新但经常读取的情况。父/子更适合数据移动更频繁的安排。