问题描述
我正在尝试以 25% 的压缩率压缩时间序列数据集。这对我来说已经变成了仇杀。
数据是 1 个月内间隔 1 分钟的历史股票报价(见数据集注释),缺失数据为 0。这相当于大约 9000 个 uint32_t 类型的数据点(我不做小数)
我的第一次尝试是对所有数据使用 FastPFor 压缩。这导致约 80% 的压缩率。还不够好。所以 -
我首先去掉所有的时间戳(很明显)
然后我对历史数据进行了排序并删除了所有重复项。这将唯一值的数量从 ~ 5000 减少到 1000。从那里,我使用差分 SIMD compression algorithm 进一步压缩它。这些也做位包装。这导致最终约 5% 的压缩率。伟大的!问题来了。
要重建数据集,您必须能够将其放回原处。我的想法是为上面每个处理过的值设置倒排索引——每个索引都指向它的原始位置。 这当然只是添加了 9000 个数字。这使尺寸几乎达到原始尺寸。
示例:
Values Indexes
10 ===> 40,20,55,100,56,21
25 ===> 1,5
...
因此,我尝试压缩倒排索引。
不幸的是,这种压缩索引的尝试并不好。在实际压缩使用每个整数 20-64 位之后,它只导致了大约 75% 的压缩率。请注意,之前我提到我使用的是 32 位数字。压缩使索引列表只有 1 个比原始大小大 2 倍的数字(我希望它保持不变)。
尝试使用倒排索引是徒劳的 - 当它与原始大小相当时,不足以证明额外的处理是合理的。
我还有其他一些想法:
压缩倒排索引的最佳方法是什么?
是否存在理论上的最小压缩率?
你知道我可以用什么方法来代替这个吗?
感谢任何输入。
示例数据
- Formatted stock prices with indexes "quote --> [indexes]" - (不对索引做任何处理)
备注
- 索引的使用将仅用于重建数据集,不会用于任何其他查询。
解决方法
整个排序似乎毫无意义。
我取了你的 8000(不是 9000)个值系列,取了不同之处,然后将它们写成可变长度整数,产生大约 14,000 个字节。然后我用 gzip 压缩它以获得大约 6000 个字节。您没有说 25% 的起点是什么,但如果是四字节二进制整数(32,000 字节),那么这种方法会将其减少到 20% 以下。