关于Index与type、id、routing数据结构设计合理性的疑惑,有两套方案麻烦各位了
Elasticsearch | 作者 yz100238904 | 发布于2018年07月18日 | 阅读数:2738
各位大神:
我先简单讲述一下项目的业务逻辑。一个物联网的项目,设备连接网关(可以理解为中间介质),经由网关进行数据推送到服务器,我们做的事情需要在服务上接收各地项目网关上报的数据,进行不同时间维度的数据分析。
几个约定:
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支持的方案
我先简单讲述一下项目的业务逻辑。一个物联网的项目,设备连接网关(可以理解为中间介质),经由网关进行数据推送到服务器,我们做的事情需要在服务上接收各地项目网关上报的数据,进行不同时间维度的数据分析。
几个约定:
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支持的方案
1 个回复
rochy - rochy_he
赞同来自:
第二种方案还是可以的,如果数据量很大,可以把 网关编号加到index名称里面