浅谈ElasticSearch的嵌套存储模型

最近一个半月都在搞SparkStreaming+Hbase+Redis+ES相关的实时流项目开发，其中重度使用了ElasticSearch作为一个核心业务的数据存储，所以这段时间更新文章较少，现在开发基本完事，接下来的会写几篇有关ElastiSearch的使用心得。

大多数时候我们使用es都是用来存储业务比较简单的数据，比如日志log类居多，就算有一些有主外键关联的数据，我们也会提前join好，然后放入es中存储。

的确，扁平化后的数据存入索引，无论是写入，更新，查询都比较简单。但是有一些业务却没法扁平化后存储。比如我们这次的业务数据。由于业务本身比较复杂，先看下数据实体模型。

总共是三层模型，可以看到User（用户）包含多个Quest（题目），每个题目又包含多个Kp（知识点），其中User，Quest，Kp都是一个实体类，可以包含多个属性，按照es的字段类型应该叫做object类型，先说说为什么不能扁平化处理在写入索引，因为一旦扁平化其实只有统计知识点相关的聚合才是正确的，若想统计题目和人的一些聚合指标有些是查不出来的，因为一旦扁平前2级数据会被冗余放大好多倍，导致计算指标会出现问题。常规的count+distinct可以出来，但是一些sum指标就不对了，会多算冗余数据的和，而且没法再减出去，如果想做可能需要多次查询才能搞定，理想情况下，一次查询就能搞定大部分查询或聚合 所以只有嵌套设计才能贴合真实的数据模型，换做关系型数据需要三张表，用MongoDB也可以但是查询+聚合就没有es这么强大和高效

三层嵌套的好处就是贴合实际的数据实体模型，但是带来的弊端也非常明显，对深层嵌套数据的删除，修改比较麻烦，虽然也能做到，但是每一层的数据量越大，性能可能就越低，所以嵌套方案，适合存储和查询多级嵌套数据，且更新和删除操作少的业务情况，尽量没有修改和删除。

es的嵌套查询和聚合支持都比较完善，并且支持嵌套反转查询。嵌套数据的添加可以使用script脚本方式来完成，直接将Java的bean给转换完为json提交即可。

下面来看下动态mapping+嵌套类型设置，一个模板如下：

嵌套类型的关键词是nested，如果一个类型是nested，就相当于是设置了Java里面的List是一个集合对象list，可以有多个同一种类型的实体类数据，每个数据里面还可以有自己的嵌套类型或其他类型，上面的动态mapping里面数据类型设置各个类型的定义，并且根据path设置了嵌套的动态mapping设置。这样以来就相当于设置了三层嵌套。

到此我们应该能理解嵌套模型的定义和使用场景了，下篇会给出如何插入数据和使用script追加数据以及简单查询。