关于Elasticsearch中Index与type、id、routing数据结构设计合理性的疑惑,有两套方案麻烦各位了 5C

各位大神:
我先简单讲述一下项目的业务逻辑。一个物联网的项目,设备连接网关(可以理解为中间介质),经由网关进行数据推送到服务器,我们做的事情需要在服务上接收各地项目网关上报的数据,进行不同时间维度的数据分析。
几个约定:
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支持的方案

2个回答

es高版本中type将会被取消掉,个人建议是不使用type直接,而且既然使用了es,为什么不自定义存储对象

u013544048
knees_down 谢谢,有一定的帮助。
大约 2 年之前 回复

Elasticsearch6.X版本已经不支持多个type了,将来7版本会取消type。所以是不建议在type上下功夫。
id是单个index内唯一的,直观的看是文档id,其实Elasticsearch内部是转换成_uid来构建唯一,_uid=type+_id,所以_id唯一跟 routing没任何关系。_ routing是你写入的时候指定,相同_ routing的文档一定会存储到同一个shard上,这种情况查询的时候也要指定_ routing,否则是查不到文档的。
对你你所列的,第一种方案显然行不通,如果是按照第一种方案的思路,可以在第二种方案上考虑一下嵌套文档

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐