3

我正在将旧的 ES 实例迁移到 ES7。我们需要 1-n 个父子关系。

我们曾经在同一个索引中有多种类型，这很容易。有些类型通过_parent.

但是 ES7 将只允许单一类型的索引。这让我觉得我会将旧类型转换为单独的索引。

我阅读了文档，他们建议将其join用于父子关系，但是这些似乎仅适用于属于单个索引的文档。

https://www.elastic.co/blog/removal-of-mapping-types-elasticsearch

因此，如果我将以前的类型转换为单独的索引，在我的理解join中将无济于事。

那么在 ES7 中对不同类型（或者我应该说是索引）之间的父子关系建模的正确解决方案是什么？

或者也许我不应该在 ES7 中将我的数据建模为单独的类型/索引。但在那种情况下，如何解决这个问题？

提前致谢

4

1 回答 1

2

是的，在版本 7 中使用indices而不是typesES 是正确的，因此我们必须创建多个索引来管理这个用例。

所以现在我们只有两个选择：

选项 1：对数据进行非规范化并相应地摄取文档。

再次，您可以通过两种方式管理它：

  • 以您继续使用连接字段的方式显着非规范化，或者说非规范化1-to-n child types为n indexes of to 1-to-1 parent-child type. 基本上，您将拥有与早期版本中的父子关系一样多的索引，但是所有索引中的父级都是相同的。索引数 = 父子关系数

  • 实现此目的的第二种方法是完全非规范化数据，这样您就拥有一个索引，其中包含您在单个文档中拥有的所有类型的所有子级的所有信息。在这种情况下，索引号 = 1

我想如果您的孩子有独特的字段，在这种情况下，我认为第二个具有单个索引的字段可能会执行，但是您再次没有提到您拥有的文档数量，因此您可能需要找到一个平衡点。另一种技术是同时利用两者。

在这种情况下的缺点是

  • 摄取层或作业的管理
  • 维护索引结构的复杂性
  • 根据此链接使用联接类型时的性能问题
  • 如果他们决定修改父子功能，请密切关注未来的 ES 版本，尽管目前不考虑这一点。

优点：

  • 可能在不必处理选项 2 的服务层，如下所述
  • 能够与前端应用程序使用中的用例相关联。

选项 2：在应用层管理加入

  • 有一个父索引和多个子索引，但在应用层管理连接。如果您有多个1-to-n mapping，则索引数将为n (parent = 1, child = n-1)

缺点：

  • 可能或可能无法轻松地与用例相关联
  • 在应用层编写单独的连接逻辑。更不用说如果您想在父子节点之间进行聚合，您必须编写多个带有多个单独聚合查询的 for 循环。

优点：

  • 易于维护作业或摄取层
  • 索引管理将不那么痛苦

或者，您可以混合和匹配上述两个选项，具体取决于您拥有的用例。

所以你看，两者都有其优点和缺点。如果一个摄取层容易，那么另一个就变得很麻烦，如果一个服务层更容易维护，那么另一个就会变得困难。

最好的方法是继续使用一些模拟数据，进行一些性能测试，看看你会投入哪些因素，查询的便利性，索引的维护，查询或聚合性能，开发/管理摄取作业和服务层等的便利性.

可能不是您正在寻找的东西，但我只是希望这会有所帮助！

于 2020-06-11T16:17:57.513 回答