多表关联

     Elasticsearch关联关系如何存储？

 1、应用端关联

存储层面：独立两个索引存储。
实际业务层面分两次请求

      适用场景：数据量少的业务场景，优点：数据量少时，用户体验好。缺点：数据量大，两次查询耗时比较长，影响用户体验

　  引申场景：关系型数据库和ES 结合，各取所长。将关系型数据库全量同步到 ES 存储，不做冗余存储。可以考虑二者结合，使用 ES 多索引建立相同的别名，针对别名检索到对应 ID 后再回 MySQL 查询，业务层面通过关联 ID join 出需要的数据。

2、宽表冗余存储

　　冗余存储，对每个文档保持一定数量的冗余数据可以在需要访问时避免进行关联。先通过视图对Mysql数据做好多表关联，然后同步视图数据到ES。此处的视图就是宽表。

　　适用场景：一对多或者多对多关联。

　　优点：速度快。因为每个文档都包含所需的所有信息，当这些信息需要在查询进行匹配时，并不需要进行昂贵的关联操作。

　　缺点：索引更新或删除数据，应用程序不得不处理宽表的冗余数据；由于冗余存储，导致某些搜索和聚合操作可能无法按照预期工作

3 嵌套文档（Nested）存储

　　当使用嵌套文档时，使用通用的查询方式是无法访问到的，必须使用合适的查询方式（nested query、nested filter、nested facet等），很多场景下，使用嵌套文档的复杂度在于索引阶段对关联关系的组织拼装。

　　适用场景：1 对少量，子文档偶尔更新、查询频繁的场景。如果需要索引对象数组并保持数组中每个对象的独立性，则应使用嵌套 Nested 数据类型而不是对象 Oject 数据类型。

　　优点：nested文档可以将父子关系的两部分数据（举例：博客+评论）关联起来，可以基于nested类型做任何的查询。缺点：查询相对较慢，更新子文档需要更新整篇文档。

4 父子文档存储

　　适用场景：子文档数据量要明显多于父文档的数据量，存在1 对多量的关系；子文档更新频繁的场景。

　　举例：1 个产品和供应商之间是1对N的关联关系。 当使用父子文档时，使用has_child 或者has_parent做父子关联查询。

　　优点：父子文档可独立更新。缺点：维护Join关系需要占据部分内存，查询较Nested更耗资源。