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

Question

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

我们曾经在同一个索引中拥有多个类型，这很容易，有些类型是通过 "父 "和 "子 "的关系。_parent.

但是ES7只允许单类型的指数，这让我觉得我将把旧的类型转换为独立的指数。

我看了文档，他们建议使用 join 父子关系，但这些似乎只适用于属于单一索引的文档。

https:/www.elastic.coblogremoval-of-mapping-types-elasticsearch

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

那么，在ES7中建立不同类型（或者说是指数）之间的父子关系的正确解决方案是什么？

或者我不应该在ES7中把我的数据建模为独立的类型指数。但在这种情况下，如何解决这个问题？

先谢谢你

Answer 1

是的，这是正确的，在使用 indices 而不是 types 因为ES在第7版中取消了这个功能，所以我们必须创建多个索引来管理这个用例。

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

方案一： 对数据进行去正常化，并相应地摄取文档。

这里你又可以用两种方式来管理它。

• 显著地去正常化的方式，你继续使用连接字段，或者说去正常化。1-to-n child types 变成 n indexes of to 1-to-1 parent-child type. 基本上，你会有和早期版本中的父子关系一样多的索引，但是所有索引中的父是相同的。索引的数量=父子关系的数量。

• 第二种方法是将数据完全去正常化，这样你就有一个单一的索引，其中包含了你在一个文档中所有类型的所有子代的所有信息。在这种情况下 索引数=1

我想如果你的孩子有独特的字段，在这种情况下，我认为第二个单一索引可能会执行，但同样你没有提到你有多少文件，所以你可能需要找到一个平衡。另一种技术是把这两种方法也利用起来。

这种情况下的缺点是

• 摄取层或作业的管理
• 维持指数结构的复杂性
• 性能问题，按照这个 联系 在使用连接类型
• 如果ES决定修改父子功能，请关注未来的ES版本，虽然暂时不考虑这个问题。

优点。

• 可能是在服务层，不需要处理下面讨论的方案2。
• 能够与你从前端应用使用中可能出现的用例共同关联。

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

• 拥有一个父索引和多个子索引，但在应用层管理连接。如果你有多个 1-to-n mapping那么，指数的数量将是 n(父母=1，子女=n-1)

缺点。

• 可能或不容易与用例相联系。
• 在应用层单独写加入逻辑。更不用说如果你想在父子之间做聚合，你就得写几个for循环与多个单独的聚合查询。

优点

• 易于维护作业或摄取层
• 指数管理将减少痛苦

另外，你也可以根据你的使用情况，将以上两种方案混合搭配。

所以你看，两者都有其优点和缺点。如果一个中的摄取层容易，另一个中的摄取层就会变得繁琐，如果一个中的服务层容易维护，另一个中的服务层就会变得困难。

最好的办法是先去做一些模拟数据，做一些性能测试，看看你会投进哪些因素，查询的便利性，索引的维护，查询或聚合的性能，开发管理摄取作业和服务层的便利性等等。

可能不完全是你要找的，但我只是希望这能帮助你!