共计 2659 个字符，预计需要花费 7 分钟才能阅读完成。
在《这几个神秘参数，教你 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 taosdemo 工具使用指南
那么回到实在生产环境上，又会是什么状况呢。换言之，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 * rowsPerTablerowSizePerTable（每行长度）能够依据每个数据类型的长度来计算。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！
