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

干货 | 多表关联设计指南 0、题记
多表关联问题是讨论最多的问题之一，如：博客和评论的关系，用户和爱好的关系。
多表关联通常指：1对多，或者多对多关系在ES中的呈现。
本文以星球问题为出发点，引申出ES多表关联认知，分析了4种关联关系的适用场景、优点、缺点。
希望对你有所启发，为你的多表关联方案选型、实战提供帮助。
1、抛出问题
1.1 星球典型问题

文章插图
1.2 社区典型问题

文章插图
1.3 QQ群典型问题
关系型数据库中的多表之间的关联查询，ES中有什么好的解决方案？
如果我把关联关系的表迁移到ES中放到一个type下，文档结构除了对象之间的嵌套还有什么好的解决方案？
2、基础认知
2.1 关系型数据库
关系数据库是专门为关系设计的，有如下特点：
关系型数据库的缺陷：
2.2
【干货 | Elasticsearch多表关联设计指南】 ，和大多数 NoSQL 数据库类似，是扁平化的。索引是独立文档的集合体。文档是否匹配搜索请求取决于它是否包含所有的所需信息和关联程度。
中单个文档的数据变更是满足ACID的，而涉及多个文档时则不支持事务。当一个事务部分失败时，无法回滚索引数据到前一个状态。
扁平化有以下优势：
索引过程是快速和无锁的。
搜索过程是快速和无锁的。
因为每个文档相互都是独立的，大规模数据可以在多个节点上进行分布。
2.3 Mysql VS
3 关联关系如何存储
关联关系仍然非常重要。某些时候，我们需要缩小扁平化和现实世界关系模型的差异。
以下四种常用的方法，用来在中进行关联数据的管理：
3.1 应用端关联
这是普遍使用的技术，即在应用接口层面来处理关联关系。
针对星球问题实践，
存储层面：独立两个索引存储。
实际业务层面分两次请求：
第一次查询返回：Top5中文姓名和成绩；
根据第一次查询的结果，第二次查询返回：Top5中文姓名和英文姓名；
将第一次查询结果和第二次查询结果组合后，返回给用户。
即：实际业务层面是进行了两次查询，统一返回给用户。用户是无感知的。
适用场景：数据量少的业务场景。
优点：数据量少时，用户体验好。
缺点：数据量大，两次查询耗时肯定会比较长，影响用户体验。
引申场景：关系型数据库和ES 结合，各取所长。将关系型数据库全量同步到 ES 存储，不做冗余存储。
如前所述：ES 擅长的是检索，而 MySQL 才擅长关系管理。所以可以考虑二者结合，使用 ES 多索引建立相同的别名，针对别名检索到对应 ID 后再回 MySQL 查询，业务层面通过关联 ID join 出需要的数据。
3.2 宽表冗余存储
对应于官方文档中的“Data ”，官方直接翻译为：“非规范化你的数据”，总感觉规范化是什么鬼，不好理解。
通俗解释就是：冗余存储，对每个文档保持一定数量的冗余数据可以在需要访问时避免进行关联。
这点通过同步关联数据到ES时，通常会建议：先通过视图对Mysql数据做好多表关联，然后同步视图数据到ES 。此处的视图就是宽表。
针对星球问题实践：姓名、英文名、成绩两张表合为一张表存储。
适用场景：一对多或者多对多关联。
优点：速度快。因为每个文档都包含了所需的所有信息，当这些信息需要在查询进行匹配时，并不需要进行昂贵的关联操作。