首页 > 解决方案 > 父子v / s多个索引 - Elasticsearch 6.2+

问题描述

我们目前有一个 ES 5.3 集群,它使用父子映射,因为我们的数据遵循这个模型。父子映射是最佳选择,因为它支持集群端连接,并通过存储在同一个分片中提供性能优势。

从 5.3 迁移到 6.2 涉及重大更改,因为从 ES v6.0 开始不再支持多种映射类型。

想知道在使用连接数据类型的新版本弹性搜索中是否值得坚持父子数据模型。

据我所知,有三种可能的选择

  1. 使用新的连接数据类型保留父子映射。

    优点

    • 集群端连接
    • 性能优势
    • 仍然可以使用 has_parent、has_child 查询

    缺点

    • 平面映射模式(如果文档有很多属性,就会变得丑陋)
    • 仅通过查看文档很难识别类型
  2. 为每种映射类型创建单独的索引

    优点

    • 映射看起来更干净
    • 只需查看即可轻松识别文档类型
    • 可以利用路由将父级的所有相关子文档放在同一个分片中
    • 每个索引可以有不同的分片配置(灵活性)

    缺点

    • 需要两个索引中的公共字段来维护关系
    • 不能再使用 has_parent、has_child 查询
    • 需要应用程序端连接
    • 与父索引相比,子索引可以变得非常大
    • 执行连接的多个查询会增加整体延迟
  3. 单个索引,但有一个自定义字段来定义文档的类型

    优点

    • 无需使用连接类型
    • 可以利用自定义路由将相关文档放在同一个分片中

    缺点

    • 映射看起来很复杂
    • 索引可能会变得非常大,因为所有文档都将驻留在同一个索引中

我更倾向于拥有多个索引的第二种选择。我可以看到的主要缺点是应用程序端连接可能很昂贵。同时,elasticsearch 文档说 has_parent、has_child 查询也很昂贵。

存储在同一分片中的父子文档的另一个优点可以通过让各个索引使用路由来实现,从而在各个索引中实现数据局部性。

当前集群统计信息

文档总数 270492501

1596009 父文档

268896492 子文档

Parent:child doc count ratio 最多为 1:400

总共 36 个分片(12 个主分片,24 个副本)

92.33 GB 数据

父文档阅读量很大。子文档的读写繁重。

想知道我是否需要考虑任何其他性能/扩展方面。谢谢

标签: elasticsearch

解决方案


推荐阅读