新的InfluxDB存储引擎：时序结构合并树

作者：Paul Dix / 产品
2015年10月07日

一年多来，我们一直在谈论为时序数据的使用场景专门构建存储引擎的可能性。今天，我很高兴地宣布，我们的新存储引擎的第一版本已在夜间构建中可用于测试。我们称之为时序结构合并树或简称TSM树。

在我们的早期测试中，我们看到了磁盘空间使用量在0.9.4基础上提高了45倍，我们在EC2 c3.8xlarge实例上以每秒超过300,000个的速度持续写入10,000,000,000（10B）数据点（分为100k个独特的系列，每个系列5k个数据点批次）。这个新引擎在存储相同数据时，比0.9.4少占用高达98%的磁盘空间，且不会降低查询性能。

在这篇文章中，我将简要介绍这个新引擎，并提供更详细的文章和测试指导。

列式存储和无限制字段

新的存储引擎是列式格式，这意味着拥有多个字段不会对查询性能产生负面影响。对于这个引擎，我们取消了测量中字段数量的限制。例如，你可以将MySQL作为要测量的对象，并将从MySQL收集的数百个不同的指标作为单独的字段来表示。

尽管这个引擎不是为更新优化，但新的列式格式也意味着可以更新单个字段而无需触及给定数据点的其他字段。

压缩

我们使用多种压缩技术，这些技术取决于字段的数据类型和时间的精度。时间精度很重要，因为你可以将其表示到纳秒级别。对于时间戳，我们使用差分编码、缩放和压缩使用simple8b、运行长度编码，如果差分太大，则回退到不压缩。具有小且规律差分的时间戳压缩效果最佳。例如，如果它们之间只差10纳秒，我们可以在纳秒时间戳上实现很好的压缩。对于10秒间隔的秒级精度时间戳，我们也会达到相同的压缩级别。

我们使用了Facebook的Gorilla论文中提到的浮点数差分编码，布尔值使用位，整数使用差分编码，字符串使用Snappy压缩。我们还在考虑为字符串添加字典压缩，这对于有重复字符串的情况非常高效。

根据数据形状，包括所有标签元数据的存储总大小可以从低端每点2字节到随机数据更多。我们发现，每10秒采样一次的序列中，每秒级精度随机浮点数大约占3字节。作为参考，Graphite的Whisper存储使用每点12字节。实际数据可能会好一些，因为通常有重复值或小的差分。

LSM树的相似之处

新引擎与LSM树（如LevelDB和Cassandra的底层存储）有相似之处。它有一个写入前日志、只读索引文件，偶尔会进行压缩来合并索引文件。我们称之为时间结构合并树，因为索引文件保持连续的时间块，压缩将那些块合并成更大的时间块。

随着索引文件的压缩，数据压缩得到改善。一旦分片写入变得冷，它将被压缩成尽可能少的文件，从而实现最佳压缩。

测试和更多资源

我们提前宣布新的存储引擎，因为我们希望将设计和代码提交给社区进行审查和测试。目前它不适合生产使用。事实上，它默认情况下在夜间构建中未启用，您应该在夜间构建安装之间清除所有数据。您可以按照这些说明启用新的存储引擎并开始测试。

我们还发布了一份关于我们之前尝试的存储引擎的详细说明，为什么它们不适合我们，以及关于新时间结构合并树引擎的所有深入细节。

我们希望您能尝试它并告诉我们它的效果。我们在原始硬件和各种云提供商上进行了广泛的内部测试。一旦我们认为它适合更广泛的使用，我们将在本处发布公告。0.9.5版本将包含这个新的存储引擎，以及对其执行热备份的能力。0.9.5的发布日期将是“准备好的时候”。也就是说，在我们对新引擎进行了广泛的测试和错误修复之后。

最后，我们拍摄了一段简短的视频，展示了我关于新存储引擎设计的一些基本概念。