InfluxDB 新存储引擎：时间结构化合并树

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

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

在我们的早期测试中，我们看到磁盘空间使用率比 0.9.4 提高了 45 倍，并且在 EC2 c3.8xlarge 实例上，以每秒超过 300,000 的持续速率写入了 10,000,000,000 (100 亿) 个数据点（分布在 10 万个唯一序列中，以 5 千个点为批次写入）。这个新引擎使用比 0.9.4 少 98% 的磁盘空间来存储相同的数据，且查询性能没有下降。

在这篇文章中，我将简要介绍一下新引擎，并提供更详细的文档和有关如何开始测试的说明。

列式存储和无限制字段

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

即使该引擎未针对更新进行优化，新的列式格式也意味着可以更新单个字段，而无需触及给定数据点的其他字段。

压缩

我们使用多种压缩技术，这些技术因字段的数据类型和时间戳的精度而异。时间戳精度很重要，因为您可以将其表示到纳秒级。对于时间戳，我们使用增量编码、缩放和压缩，使用 simple8b、游程编码，或者如果增量太大则回退到不压缩。增量小且规则的时间戳压缩效果最佳。例如，如果纳秒时间戳彼此之间仅相隔 10 纳秒，我们可以获得很好的压缩效果。对于每隔 10 秒的秒精度时间戳，我们将获得相同的压缩级别。

我们对浮点数使用与 Facebook 的 Gorilla 论文中提到的相同的增量编码，对布尔值使用位，对整数使用增量编码，对字符串使用 Snappy 压缩。我们还在考虑为字符串添加字典式压缩，如果您有重复的字符串，这将非常有效。

根据您的数据形状，包括所有标签元数据的存储总大小范围可能从每个点 2 个字节（低端）到更多（对于随机数据）。我们发现，每 10 秒采样一次的系列中，具有秒级精度的随机浮点数大约占用每个点 3 个字节。作为参考，Graphite 的 Whisper 存储每个点使用 12 个字节。真实世界的数据可能会更好一些，因为通常存在重复的值或小的增量。

LSM 树相似性

新引擎与 LSM 树（如 LevelDB 和 Cassandra 的底层存储）具有相似之处。它有一个预写日志、只读的索引文件，并且偶尔会执行压缩以组合索引文件。我们称之为时间结构化合并树，因为索引文件保留了连续的时间块，而压缩将这些块合并为更大的时间块。

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

测试和更多资源

我们提前发布新存储引擎，是因为我们想将设计和代码都发布出来，供社区审查和测试。目前它不适用于生产环境。实际上，在 nightly build 中默认情况下未启用它，您应该计划在 nightly build 安装之间清除所有数据。您可以按照这些说明了解如何启用新存储引擎并开始测试它。

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

我们希望您能测试一下并告诉我们它的运行情况。我们正在内部对原始硬件和各种云提供商进行广泛的测试。一旦我们觉得它准备好用于更严肃的用途，我们就会在此处发布公告。0.9.5 版本将随新存储引擎一起发布，并具有对其进行热备份的能力。0.9.5 的发布日期将是“准备就绪时”。也就是说，在我们对新引擎进行了广泛的测试和错误修复之后。

最后，我们拍摄了一段简短的视频，我在白板上讲解了关于新存储引擎设计的一些基本知识