存储成本仅为OpenTSDB的1/10,TDengine的最大杀手锏是什么?
在《这几个神秘参数,教你TDengine集群的正确使用方式》中,我们告诉了大家:如何才能让数据均匀的分布在节点中。接下来,我们和大家一起以产品使用者的视角继续向前探索。
如果说让数据均匀分布的目的是为了最大化地使用CPU资源的话,那么充分地利用数据压缩能力就是为了最大化地驾驭存储资源了。
我只能说,在这个方面TDengine做得棒极了。
在官网上,有这样的描述:
TDengine 相对于通用数据库,有超高的压缩比,在绝大多数场景下,TDengine 的压缩比不会低于 5 倍,有的场合,压缩比可达到 10 倍以上。
下面就是TDengine在最近三个月内打出的成绩。
在顺丰科技的应用案例中,TDengine轻松替换掉了OpenTSDB+HBase:
服务端物理机由21台降至3台,每日所需存储空间为93G(2副本),同等副本下仅为OpenTSDB+HBase的约1/10,在降低成本方面相对通用性大数据平台有非常大的优势。
在得物APP的应用案例中,TDengine通过10%的压缩率为对方节约了大量存储资源:
目前Sentinel的数据没有使用副本,全量数据分散在三台机器中,根据计算得知TDengine对于Sentinel监控数据的压缩率达10%,相当可观。
一是开源产品免费,二是能白白给自己省下那么多服务器,三是读写性能都不错——这种降本增效的工具谁不喜欢呢。
于是一些用户开始安装产品,并开始使用官方推荐的压测工具taosdemo造数写入,想看看是不是真的可以做到宣传的效果。
但是测试过后,很多用户感觉TDengine的压缩率并没有达到自己的预期。可另一方面,顺丰和得物这些大企业又实实在在地得到了非常可观的成本降低,那么问题到底出在哪里呢?
大家都知道IoT数据的特点之一就是,对于同一监测量而言,相互之间相差小且有规律,即便是字符型也会有相当大数据重复出现或者类似的可能。正是这样的数据模型才给了TDengine的列式压缩广阔的发挥空间。
但是呢,如果仅以taosdemo默认配置的随机数据来做测试,生成的数据未必具有这样的特点。比如,默认的配置有一个长度为16的nchar字符类型,每个 nchar 字符占用 4 bytes 的存储空间4*16占据了几乎一半的行长度又不好压缩,所以就显得压缩效率有点低。
为了优化这个体验,在2.1版本的taosdemo里默认的写入数据换成了四列INT。但如果大家想写入自定义格式的数据,只要根据这个博客操作就好了。
那么回到真实生产环境上,又会是什么情况呢。换言之,TDengine到底是如何帮助顺丰与得物这样的独角兽企业降低存储成本的呢?
接下来,我们就来看看——什么叫赢在起跑线上:超级表建表语句和普通表建表语句的区别就只在这一个地方——Tag(标签)。超级表多了它就可以管理百万千万级别的子表,充分地说明了它的重要性。
正是因为TDengine把每个设备的标签都提取出来放在了内存里,所以才让设备的裸数据量天生就少了很多。所以,如果你想测试一样的业务场景下的性能时,在生成数据的那一刻你就会发现TDengine已经赢了。因为想要营造出一样的场景,它根本不需要造出那么多数据。
假设一个设备光是标签数就和测点数差不多甚至更多的时候,那在原始数据上你就可能已经省下了至少一半的磁盘占用。
接下来,我们来看看TDengine的数据压缩流程:当数据写入内存的时候,为了防止断电等特殊情况带来的数据丢失,TDengine会把数据先写入wal(write ahead log)文件。
当落盘机制被触发,数据开始持久化到存储之前,COMP参数就开始生效了。根据这个参数的值(0 1 2),TDengine会分别选择是做不压缩,一阶段压缩,还是二阶段压缩:一阶段压缩会根据数据的类型进行了相应的列压缩,压缩算法包括delta-delta编码、simple 8B方法、zig-zag编码、LZ4等算法。所以,总结一下:
1.对于特定列有特定算法的针对性压缩
2.物联网场景下数据的普遍规律性
这两点共同造就了TDengine超强的压缩能力。
接下来,二阶段压缩又在一阶段压缩的基础上用通用压缩算法进行了压缩,压缩效果更高。关于TDengine压缩算法的说明见如下链接。
https://github.com/taosdata/TDengine/blob/master/src/util/src/tcompression.c
最后,我们再来看看,到底要如何估算出压缩率:
首先,我们要算出裸数据的大小,官网上提供的计算公式为:
Raw DataSize = numOfTables * rowSizePerTable * rowsPerTable
rowSizePerTable(每行长度)可以根据每个数据类型的长度来计算。describe table你会看到表的结构以及各个字段的大小。其中binary和nchar类的长度为最大长度。实际占用要以真实数据长度为准(下面示范中binary和nachar占满全部空间),而nchar字段的占用长度还要乘4。此外,每个binary和nchar还要额外占据两个字节。
比如下表:
在假设Binary和Nchar数据都是写满16个的情况下,单行总长度就是(8+1+2+4+8+4+8+16+164+1+8)+4=128字节。用128字节乘以 rowsPerTable(每个表行数)numOfTables(表数),就可以大体地估算出我们的总数据量了。
其实,测试中更常见的是直接用超级表作为测试主体,直接使用超级表的count(*)数据去乘以每行长度就可以得到Raw DataSize了。
最后,再用/var/lib/taos/vnode/下面各个vnode的数据文件大小除以Raw DataSize。
大功告成——我们终于得出实际压缩率了。这里,大家要留意一下:在数据文件目录下的vnode目录里面还有一个wal目录。如果这里面有数据说明数据还没有落盘到存储里面,也就是说数据是还没有压缩过的。为了让测试结果更加精准,所以大家可以使用最简单直接的办法——重启服务进程,这样就可以直接触发落盘机制了。
上图显示:重启过后,所有的wal文件大小都是0,证明数据已经成功被压缩后写入存储了。
本次TDengine之旅,终于到此告一段落。
其实,测试压缩率最好的办法就是在合理的数据建模之后,用自己的真实数据试去跑一下,这时候就一目了然了。
以上,就是TDengine降低存储成本的最大杀手锏。
点击这里,体验TDengine!
从 1000+ 参赛项目突围!涛思数据荣获 ITEC 2022 全球创业赛成长组二等奖
TDengine涛思数据
高效数据运营赋能数字化转型研讨会暨《DataOps 实践手册》新书发布会 预约通道开启!
思否编辑部阅读 3.9k
vivo 超大规模消息中间件实践之路
vivo互联网技术赞 2阅读 520
Flink 批作业的运行时自适应执行管控
ApacheFlink赞 1阅读 610
浙江省体育局上线“体育大脑” 蚂蚁数科提供技术支持
蚂蚁技术赞 1阅读 442
中原银行对金融行业实时数仓的现状与发展趋势思考
ApacheFlink阅读 1.1k
时序数据库性能及应用大PK,TDengine 值得期待
铁甲大宝阅读 977
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。