一尘不染

嵌套文档与父/子文档的缩放比例

elasticsearch

我正在为我们运行概念验证,以便对ES中更多“标准化”的数据运行嵌套查询。

例如带有嵌套

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

现在,我可以将给定客户的事件列表移至另一位客户。例如,客户A有50个事件客户B有5000个事件

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

拥有数百万客户的规模,并且在UI中针对图形进行查询,Parent / Child更适合还是应该能够嵌套处理?

在我的情况下,优缺点是什么?


阅读 215

收藏
2020-06-22

共1个答案

一尘不染

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

巢状

  • 嵌套文档彼此存储在相同的Lucene块中,这有助于提高读取/查询性能。读取嵌套文档比同等的父/子更快。
  • 更新嵌套文档(父级或嵌套子级)中的单个字段会强制ES重新为 整个 嵌套文档编制索引。对于大型嵌套文档而言,这可能会非常昂贵
  • 更改“父”意味着ES将:删除旧文档,使用更少的嵌套数据重新索引旧文档,删除新文档,使用新的嵌套数据重新索引新文档。

父母/子女

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

嵌套可以很好地工作,但是如果您认为有可能进行大量“数据改组”,则“父/子”可能更合适。嵌套最适合嵌套数据不经常更新但经常读取的实例。父母/孩子最好安排数据更频繁地移动。

2020-06-22