elasticsearch - ES7 - 如何建模 1-n 父子关系 - 不同的 ES 类型

Question

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

我们曾经在同一个索引中有多个类型，这很容易。某些类型通过 _parent 与其父级相关。

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

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

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

因此，如果我将以前的类型转换为单独的索引，据我所知，join 将无济于事。

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

或者也许我不应该在 ES7 中将我的数据建模为单独的类型/索引。但那样的话，如何解决呢？

提前致谢

Answer 1

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

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

选项 1:反规范化数据并相应地摄取文档。

同样，您可以通过两种方式管理它:

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

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

我想如果你的 child 有独特的字段，在那种情况下，我认为第二个具有单一索引的可能会执行，但你没有提到你拥有的文档数量，所以你可能需要找到一个平衡点。另一种技术是同时使用两者。

在这种情况下的缺点是

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

优点:

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

选项2:在应用层管理Join

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

缺点:

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

优点:

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

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

所以你看，两者各有利弊。如果摄取层在一个中很容易，那么在另一个中就变得很麻烦，如果服务层在一个中更容易维护，那么在另一个中就变得困难了。

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

可能不是您要找的，但我希望这对您有所帮助!