何时（不）使用 varbit 块

Prometheus 服务器的嵌入式时序数据库（TSDB）将每个时间序列的原始样本数据组织成固定大小为 1024 字节的块（chunk）。除了原始样本数据外，一个块还包含一些元数据，这使得可以为每个块选择不同的编码方式。最根本的区别是编码版本。你可以通过命令行标志 -storage.local.chunk-encoding-version 来为新创建的块选择版本。到目前为止，只支持两个版本：版本 0 用于原始的 delta 编码，版本 1 用于改进的 double-delta 编码。在 0.18.0  版本中，我们添加了版本 2，这是 double-delta 编码的另一种变体。我们称之为 varbit 编码，因为它在块内对每个样本使用可变位宽。虽然版本 1 在几乎所有方面都优于版本 0，但在版本 1 和版本 2 之间确实需要权衡。这篇博文将帮助你做出决定。版本 1 仍然是默认编码，所以如果你在阅读本文后想尝试版本 2，你必须通过命令行标志显式选择它。来回切换没有坏处，但请注意，已创建的块一旦生成就不会改变其编码版本。不过，这些块会根据配置的保留时间逐渐被淘汰，并被使用命令行标志中指定的编码的新块所取代。

什么是 varbit 编码？

从一开始，我们就将分块样本存储设计为易于添加新编码。当 Facebook 发表了一篇关于其内存 TSDB Gorilla 的论文 时，我们对 Gorilla 和 Prometheus 这两种独立开发的方法之间的一些相似之处很感兴趣。然而，它们之间也存在许多根本性的差异，我们对此进行了详细研究，想知道是否能从 Gorilla 中获得一些灵感来改进 Prometheus。

在一个难得的空闲周末，我决定试一试。在一阵编码狂潮中，我实现了后来（经过大量测试和调试后）成为 varbit 编码的东西。

在将来的博文中，我将介绍这种编码的技术细节。现在，你只需要了解一些特性，以便在新旧 varbit 编码和传统的 double-delta 编码之间做出选择。（从现在开始，我将后者简称为“double-delta 编码”，但请注意，varbit 编码也使用了 double delta，只是方式不同。）

varbit 编码的优势是什么？

简而言之：它提供了更好的压缩比。对于真实世界的数据集，double-delta 编码每个样本大约需要 3.3 字节，而 varbit 编码在 SoundCloud 的一台典型大型生产服务器上，每个样本可以低至 1.28 字节。这使得空间效率提高了近三倍（甚至比 Gorilla 报告的每个样本 1.37 字节还要好一些——但请对此持保留态度，因为 SoundCloud 的典型数据集可能与 Facebook 的不同）。

现在想想这意味着什么：内存中可以多存三倍的样本，磁盘上可以多存三倍的样本，磁盘操作只需原来的三分之一，而且由于磁盘操作目前是数据接收速度的瓶颈，这也将使数据接收速度提高三倍。事实上，最近报道的每秒 800,000 个样本的新接收记录，只有通过 varbit 块才能实现——当然，还需要 SSD。如果使用机械硬盘，瓶颈会更早出现，因此这 3 倍的提升就显得更加重要。

这一切听起来好得令人难以置信……

那么代价是什么呢？

一方面，varbit 编码更为复杂。因此，编码和解码值的计算成本有所增加，这从根本上影响了所有写入或读取样本数据的操作。幸运的是，这只是对一项通常只占操作总成本一小部分的开销的成比例增加。

varbit 编码的另一个特性可能更为重要：varbit 块中的样本只能顺序访问，而 double-delta 编码块中的样本可以通过索引随机访问。由于 Prometheus 中的写入是仅追加的，不同的访问模式只影响样本数据的读取。实际影响在很大程度上取决于原始 PromQL 查询的性质。

一个相对无害的情况是检索一个时间间隔内的所有样本。这发生在评估范围选择器或渲染分辨率与抓取频率相似的仪表盘时。Prometheus 存储引擎需要找到该间隔的起点。对于 double-delta 块，它可以执行二分查找，而对于 varbit 块，它必须顺序扫描。然而，一旦找到起点，该间隔内所有剩余的样本都需要顺序解码，使用 varbit 编码的成本也只是略高一些。

对于从一个块中检索少量不相邻的样本，或者在所谓的即时查询中仅检索单个样本，情况就有所不同了。存储引擎可能需要遍历大量样本才能找到要返回的少数样本。幸运的是，即时查询最常见的来源是规则评估，这些评估引用了每个相关时间序列的最新样本。并非完全巧合，我最近改进了对时间序列最新样本的检索。基本上，添加到时间序列的最后一个样本现在会被缓存。一个只需要时间序列最新样本的查询甚至不会再触及块层，因此块编码在这种情况下是无关紧要的。

即使即时查询引用了过去的某个样本，因此必须触及块层，查询的其他部分，如索引查找，很可能仍将主导总查询时间。但确实存在一些真实场景，varbit 块所要求的顺序访问模式会开始变得非常重要。

对 varbit 块来说，最坏的查询情况是什么？

对 varbit 块来说，最坏的情况是，你需要从一个非常长的时间序列的每个块的中间位置只取一个样本。不幸的是，这种情况确实存在实际用例。假设一个时间序列压缩得很好，每个块可以持续大约八小时。这相当于一天大约三个块，一个月大约 100 个块。如果你有一个仪表盘，显示这个时间序列过去一个月的数据，分辨率为 100 个数据点，那么仪表盘将执行一个查询，从 100 个不同的块中各检索一个样本。即便如此，不同块编码之间的差异也会被查询执行的其他部分所主导。根据具体情况，我猜测使用 double-delta 编码的查询可能需要 50 毫秒，而使用 varbit 编码则需要 100 毫秒。

然而，如果你的仪表盘查询不仅涉及单个时间序列，而是对数千个时间序列进行聚合，那么需要访问的块数量也会相应增加，顺序扫描的开销将变得非常显著。（我们不鼓励此类查询，并且通常建议对频繁使用的查询（例如在仪表盘中）使用记录规则。）但是，如果使用 double-delta 编码，查询时间可能仍然可以接受，比如大约一秒。切换到 varbit 编码后，同样的查询可能会持续数十秒，这显然不是你希望在仪表盘上看到的。

有哪些经验法则？

简单来说：如果你的磁盘容量和磁盘操作都没有限制，那就不用担心，继续使用默认的经典 double-delta 编码。

然而，如果你希望有更长的数据保留时间，或者你目前受限于磁盘操作，我建议你尝试一下新的 varbit 编码。用 -storage.local.chunk-encoding-version=2 启动你的 Prometheus 服务器，并等待一段时间，直到你有足够多的新块使用 varbit 编码来评估效果。如果你发现有些查询变得慢得无法接受，检查一下是否可以使用记录规则来加速它们。很可能，即使使用旧的 double-delta 编码，这些查询也能从中获益匪浅。

如果你对 varbit 编码的幕后工作原理感兴趣，请继续关注不久的将来发布的另一篇博文。