最近Elasticsearch 7.10版本发布,该版本除了有Searchable Snapshots可搜索快照这个重磅特性之外,还有Data tiers数据层功能。数据层实际上就是先定义好数据节点的角色,比如热节点、温节点等,然后可以在ILM索引生命周期管理中实现索引由热节点迁移到温节点,再迁移到冷节点,达到数据冷热分离的目的。
在Data tiers功能之前,我们通常是通过在elasticsearch.yml中定义节点的属性(node.attrs)来实现集群的冷热分离架构,而Data tiers,需要在elasticsearch.yml中通过新增的node.roles定义节点的角色,同样角色的节点理应有用相同的物理属性,比如热节点为SSD云盘,温节点为SATA盘,定义节点角色的配置如下所示:
node.roles: ["data_hot", "data_content"]
相比较通过node.attr来定义节点的类型,通过node.roles定义节点类型则更清晰,我们可以清楚的知道每个节点在集群中所处于的位置,并且方便管理。
Content内容层面向的是数据本身一成不变或者极少发生变化的场景,比如搜索场景,或者是本身因为数据量不大而不需要切分索引的场景,在这种场景中,数据写入或者查询都由Content层的节点承担。新建的索引默认就分配在Content层(面向时序数据的Data stream的索引除外)。
在面向时序数据的日志或者监控场景,往往只需要保证最近比较新的数据的写入能够及时落地,以及满足对比较新的数据近实时的查询,这些数据可以放在Hot层,使用SSD盘、较高的节点规格保证写入和查询的性能。
使用Data stream新创建的索引,默认放在Hot层。
在面向时序数据的日志或者监控场景,对于写入或者查询频率较低的索引,在允许写入或者查询性能相对差一些的情况下,可以把索引从Hot层移动到Warm层,使用成本相对低廉的SATA存储数据,从而节省成本。
当索引已经足够老时,可以把索引移动到Cold层,这些索引可能极少会写入或者查询,因此可以在该层中对索引进行forcemerge节省一些磁盘空间,或者进行shrink降低索引的分片数量。另外,可以在该层中先把数据备份到廉价的存储介质比如S3中,然后把索引副本调低为0,从而减少一半的存储空间。
社区里为什么要重新开发Data tiers功能,而不是继续沿用之前给节点设置node.attr属性的方式实现节点的冷热分离呢,从社区里Data tiers的issue可以窥探出一些设计初衷:
既然把集群数据分层或者说冷热分离的架构都规范化了,我们自然可以有更多的设想,利用数据分层做更多的事情:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。