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

• 資深大佬 : 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 压缩算法，时序数据压缩基本绕不开，而且代码都开源了