冷存大量浮点数类型数据，有什么合适的压缩方案吗？

[LeeReamond]

如题，自用传感器有大量时序数据需要记录，大概格式是时间-》传感器数据 A，传感器数据 B....等等这样，单个数据类型为单精度浮点数，小数点后 6 位以内

因为记录精度精确到毫秒，所以数据量非常大，粗略估算了一下在 1T 到 10T 之间这个数量级，

这些是原始数据，实际上工作中是用不到的，工作用到的数据是处理之后的版本，但是我觉得原始数据如果可能的话最好还是保存一下，谁知道以后可能出什么问题呢。

之前有了解过时序数据库似乎很适合储存这类传感器数据。但是我目前这个需要的是完全冷存，不需要有任何增删改查的功能，只需要储存体积尽可能小，这样可以少买几块硬盘。神通广大的 V 友有什么合适的方式推荐吗

[codehz]

直接序列存储+没有强数据安全需求的话根本用不到数据库，文件系统都不需要，直接按块写盘就好了。。。然后找个其他存储设备存元数据（即一块盘写了哪些东西，写了几个字节这些信息）

[unixeno]

10T 很大么，不是一块硬盘就完事儿了？

[imn1]

对于原始数据，我的话，不会考虑耗费硬盘多少，只考虑必要时能否读出，定期转存的成本（倒数据的工作量）

[thedrwu]

HDF

[felixcode]

如果直接简单粗暴用纯文本的话，压缩率会很可观的吧。

[larry801]

@felixcode 全是单精度当然直接存二进制啦 转文本不多一层么
各个云厂商的冷数据服务如何？
无规律的单精度压缩率估计不好看 省不了多少 考虑一下安全性吧 等要的时候又坏了才坑呢

[zmj1316]

12T 硬盘也不贵，还可以开启文件系统的压缩

[xupefei]

压缩后存 B2 或 glacier 的话，每月 20 美元应该搞得定。
买个大硬盘也可以，不贵。

[3dwelcome]

用 diff 算法按照 32bit 转置后存。
比如 1.21 ，1.23 ，1.24 就变成了三个 32bit 字节流，用转置算法把三个 sign 位拼一起压缩，把三个 exp 位拼接一起压缩，把三个 fraction 位拼一起压缩。
这样数据值变动小，压缩率就很可观。

[thedrwu]

考虑一下直接存采样的整数数据？
快速的模数转换，有 16 位进度已经很高了，容量需求直接砍一半。如果能省下几位 LSB，或者用 dithering 抖过去，又能节省十分之几的空间。

[LeeReamond]

@imn1 确实硬盘不是首要考量，但最好还是空间小一些，资金有限

@3dwelcome 没有听懂，不过听起来很诱人，想试一下这个方案，我的每个数值之间区别不大，容我研究研究。

[ryd994]

二进制，按时间分文件，然后压缩
想省事的话就用文件系统自带的压缩

[jworg]

10 楼正解，作为嵌入式一直很怀疑对接的人非要浮点数的必要，明明存采样 adc 的原始数据就可以了，然后注释一下转化公式。这个让下面的嵌入式改下面上传数据格式就可以了，比起浮点数还有无损的优点。

[LeeReamond]

感谢各位提供的思路，按楼上设想我准备输出成整数，然后采用某些已经有的序列化方案转换成二进制，最后做一下简单的压缩，理论上单个数值的合适储存体积应该小于 2bytes，经过上述操作可以比较接近这个数值，没什么不满意的了。

[vhysug01]

之前做股票价格数据，一般的数字存 csv 再压缩，能省 90%的空间

[siyemiaokube]

这个级别的时序数据，应该很需要考虑安全性了吧？感觉非常容易丢失啊

[siyemiaokube]

也要取决于你这个传感器的工作环境了，压缩算法自己造轮子的话，我感觉很可能存在大量丢失数据的风险。相对地，比起直接存定点数，压缩率大概顶多 50%？

[3dwelcome]

@LeeReamond 我这算法就是把 bit 拆分后压缩，很好理解。
比如你浮点数据都是正数，那么所有符号位的 bit，就全部都是 1 。把连续几万个 1 放一起，压缩后也就几个字节大小。然后依次处理剩下的 31 个 bit 。
浮点格式里，相近数字变化时，大部分 bit 都是不变的，就是利用这个特性来压缩。

[whileFalse]

直接写 txt，然后压缩
或者二进制后压缩

没必要自己研究存储算法。一般人研究不过 zip 。如果你不是一般人，那你根本不会提出这个问题。

[zwzmzd]

参考 facebook gorilla 压缩算法，时序数据压缩基本绕不开，而且代码都开源了