各位大神：
我先简单讲述一下项目的业务逻辑。一个物联网的项目，设备连接网关（可以理解为中间介质），经由网关进行数据推送到服务器，我们做的事情需要在服务上接收各地项目网关上报的数据，进行不同时间维度的数据分析。
几个约定：
1、同一个项目，网关编号不会重复；
2、同一个网关下的设备编号不会重复，但是有可能与其他网关下的设备编号重复
3、设备拥有多种不同的参数编号及参数值
初步存放数据设计的格式有两种方案（基于es 5.x的版本）
方案一：
1、Index=存储项目编号+日期（yyyy-MM）
2、type=存储网关编号
3、id =存储设备编号
4、routing=设备参数
基于方案一，好处在数据分类上可能比较直观，坏处就是会产生多个type、id，而且id不唯一，需要id+routing才能表达唯一。但是不知道es对多个type的支持是否效率高。
方案二：
1、index=项目编号+日期（yyyy-MM）
2、type=data（仅仅说明这个是原始的数据）
基于方案二、好处就是type较少，检索数据直接通过字段查询。
上诉两种方案，可能是我理解的不够透彻，所以不懂那种方式属于es支持的方案
es高版本中type将会被取消掉，个人建议是不使用type直接，而且既然使用了es，为什么不自定义存储对象
Elasticsearch6.X版本已经不支持多个type了，将来7版本会取消type。所以是不建议在type上下功夫。
id是单个index内唯一的，直观的看是文档id，其实Elasticsearch内部是转换成_uid来构建唯一，_uid=type+_id，所以_id唯一跟 routing没任何关系。_ routing是你写入的时候指定，相同_ routing的文档一定会存储到同一个shard上，这种情况查询的时候也要指定_ routing，否则是查不到文档的。
对你你所列的，第一种方案显然行不通，如果是按照第一种方案的思路，可以在第二种方案上考虑一下嵌套文档