Parent Child (父子文档)
父子文档的结构目录，适用于频繁写入，查询较少的场景。
因为底层每次更新只会更新单独的子文档，不是走全量更新的形式，所以对写入较为友好。
维护Join关系需要耗费比较大的内存，所以查询会相对来说较慢。
Nested (嵌套)
适用于频繁查询，写入较少的场景。
object对象结构的升级版本，嵌套结构，可以解决我们在object结构中查询不准确的问题。
因为每一次写入都会需要更新单条文档下全量的数据，但是又因为保存了每个对象的关系以及他们之间的独立性所以有着相对parent child更高的查询性能。
Other (其他方案)
在某些场景下，可能上述的方案都不太适合现有的场景。
例如: 复杂的关联关系 或者 海量的关联数据量。
我们在思考这个问题之前得先明确我们当下所使用的这些存储组件的意义，也就是说为什么我们会用到这些组件？
比如我们的ElasticSearch,Mysql,Hbase 等等其他组件
随着我们的思考我们会发现,ElasticSearch其实最适合的场景是从海量数据中查询出找出自己想要的那部分数据。也就说其实它最强大的功能是搜索，而并不是特别大体量的数据召回能力，在这个基础上我们很容易就能设想出结合其他技术的解决方案。
方案的具体设计思路
ElasticSearch + Mysql
在有些场景下MySQL需要多表联查数据，但是好多字段都没有建立索引，单独为某一需求建立索引又不太现实，因为熟悉Mysql的同学也都知道，建立索引是需要额外维护B + Tree的，它会占用我们的内存空间，导致我们的IO速度变慢，这时候我们可以通过ES强大的搜索能力来帮助我们做多条件筛选，筛选出对应的Mysql表对应的业务主键Id，比如保险行业的业务id就是投保单号，我们可以根据投保单号去搜索Mysql，直接使用主键去定位数据，避免了多次回表以及没有建立索引产生的性能损耗，提高MySQL查询的性能。
ElasticSearch + Hbase
适用于单表查询或者一对多查询的场景下，配合kafka一起使用，从源库中做数据同步到ES以及Hbase，只存储主业务表的数据在ElasticSearch，也就是一对多关系当中的一，如果只需要召回这一部分数据的话ElasticSearch就可以直接返回，如果还需要查询多表数据的话，那么我们就会通过反转id作为rowkey去查询我们的Hbase然后获取到想要获取的多表数据，对返回值进行封装返回,此操作也可用于对接其他微服务系统，来为其他服务提供查询支持，类似于中台的架构设计。
