干货 | Elasticsearch多表关联设计指南( 二 ) _文档

缺点：索引更新或删除数据，应用程序不得不处理宽表的冗余数据；
由于冗余存储，导致某些搜索和聚合操作可能无法按照预期工作。
3.3 嵌套文档（）存储
类型是ES 定义的集合类型之一，它是比类型更NB的支持独立检索的类型。
举例：有一个文档描述了一个帖子和一个包含帖子上所有评论的内部对象评论。可以借助实现。
实践注意1：当使用嵌套文档时，使用通用的查询方式是无法访问到的，必须使用合适的查询方式（ query、、 facet等），很多场景下，使用嵌套文档的复杂度在于索引阶段对关联关系的组织拼装。
推荐实践：干货 |类型深入详解
实践注意2：
index.mapping.nested_fields.limit 缺省值是50 。即：一个索引中最大允许拥有50个nested类型的数据。index.mapping.nested_objects.limit 缺省值是10000 。即：1个文档中所有nested类型json对象数据的总量是10000 。
适用场景：1 对少量，子文档偶尔更新、查询频繁的场景。
如果需要索引对象数组并保持数组中每个对象的独立性，则应使用嵌套数据类型而不是对象 Oject 数据类型。
优点：文档可以将父子关系的两部分数据（举例：博客+评论）关联起来，可以基于类型做任何的查询。
缺点：查询相对较慢，更新子文档需要更新整篇文档。
3.4 父子文档存储
注意：6.X之前的版本的父子文档存储在相同索引的不同type中。而6.X之上的版本，单索引下已不存在多type的概念。父子文档Join的都是基于相同索引相同type实现的。
Join类型是ES 定义的类型之一，用于在同一索引的文档中创建父/子关系。关系部分定义文档中的一组可能关系，每个关系是父名称和子名称。
实践参考： 6.X 新类型Join深入详解
适用场景：子文档数据量要明显多于父文档的数据量，存在1 对多量的关系；子文档更新频繁的场景。
举例：1 个产品和供应商之间是1对N的关联关系。
当使用父子文档时，使用或者做父子关联查询。
优点：父子文档可独立更新。
缺点：维护Join关系需要占据部分内存，查询较更耗资源。
4 小结

文章插图
在开发实战中对于多表关联的设计要突破关系型数据库设计的思维定式。
不建议在es做join操作，-child能实现部分功能，但是它的开销比较大，如果可能，尽量在设计时使用扁平的文档模型。
尽量将业务转化为没有关联关系的文档形式，在文档建模处多下功夫，以提升检索效率。
&Join父子文选型必须考虑性能问题。类型检索使得检索效率慢几倍，父子Join 类型检索会使得检索效率慢几百倍。
以上内容，实际官方文档都有明确的描述。我把内容加上自己的理解，作了精炼和解读。
再次强调：第一手资料的重要性。但本着“再显而易见的道理，也有N多人不知道”的原则，一定要读英文官方文档，加深认知理解。
多表关联你是如何做的呢？欢迎留言写下您的思考。
参考：
[1]
[2]教程