Prometheus 服务器的嵌入式时间序列数据库 (TSDB) 将每个时间序列的原始样本数据组织成大小恒定为 1024 字节的 chunks。除了原始样本数据，一个 chunk 还包含一些元数据，允许为每个 chunk 选择不同的编码。最根本的区别是编码版本。您可以通过命令行标志 -storage.local.chunk-encoding-version 为新创建的 chunk 选择版本。到目前为止，只有两个受支持的版本：0 代表原始的 delta 编码，1 代表改进的双 delta 编码。在 0.18.0 版本中，我们添加了版本 2，它是双 delta 编码的另一种变体。我们称之为 varbit 编码，因为它在 chunk 内每个样本都涉及可变的位宽。虽然版本 1 在几乎所有方面都优于版本 0，但在版本 1 和版本 2 之间存在真正的权衡。这篇博文将帮助您做出决定。版本 1 仍然是默认编码，因此如果您在阅读本文后想尝试版本 2，则必须通过命令行标志显式选择它。来回切换没有坏处，但请注意，一旦创建，现有 chunk 将不会更改其编码版本。但是，这些 chunk 将根据配置的保留时间逐渐淘汰，因此将被命令行标志中指定的编码的 chunk 替换。
什么是 varbit 编码？
从一开始，我们就将分块样本存储设计为易于添加新编码。当 Facebook 发表了一篇关于他们的内存 TSDB Gorilla 的论文时，我们被 Gorilla 和 Prometheus 独立开发的方案之间的许多相似之处所吸引。然而，也存在许多根本性的差异，我们对此进行了详细研究，想知道是否可以从 Gorilla 中获得一些灵感来改进 Prometheus。
在一个难得的空闲周末来临之际，我决定尝试一下。在一个编码狂欢中，我实现了后来（经过大量的测试和调试）成为 varbit 编码的东西。
在未来的博文中，我将描述编码的技术细节。现在，您只需要了解一些特性，以便在新的 varbit 编码和传统的双 delta 编码之间做出决定。（从现在开始，我将后者称为“双 delta 编码”，但请注意，varbit 编码也使用双 delta，只是方式不同。）
varbit 编码的优点是什么？
简而言之：它提供了更好的压缩率。虽然双 delta 编码对于真实数据集每个样本需要大约 3.3 字节，但 varbit 编码在 SoundCloud 的典型大型生产服务器上低至每个样本 1.28 字节。这几乎是三倍的空间效率（甚至略好于 Gorilla 报告的每个样本 1.37 字节——但请对此持保留态度，因为 SoundCloud 的典型数据集可能与 Facebook 的典型数据集不同）。
现在考虑一下这意味着什么：RAM 中多出三倍的样本，磁盘上多出三倍的样本，只有三分之一的磁盘操作，并且由于磁盘操作目前是摄取速度的瓶颈，它还将允许摄取速度快三倍。事实上，最近报告的每秒 800,000 个样本的新摄取记录只有在使用 varbit chunk 的情况下才有可能——显然还需要 SSD。使用机械硬盘，瓶颈会更早达到，因此 3 倍的增益更为重要。
这一切听起来好得令人难以置信……
那么，问题在哪里？
首先，varbit 编码更复杂。因此，编码和解码值的计算成本有所增加，这从根本上影响了写入或读取样本数据的所有内容。幸运的是，这只是通常仅占操作总成本一小部分的比例增加。
varbit 编码的另一个属性可能更相关：varbit chunk 中的样本只能按顺序访问，而双 delta 编码 chunk 中的样本可以通过索引随机访问。由于 Prometheus 中的写入是仅追加的，因此不同的访问模式仅影响样本数据的读取。实际影响很大程度上取决于原始 PromQL 查询的性质。
一个相当无害的情况是检索时间间隔内的所有样本。当评估范围选择器或渲染分辨率类似于抓取频率的仪表板时，会发生这种情况。Prometheus 存储引擎需要找到间隔的起点。使用双 delta chunk，它可以执行二分查找，而必须顺序扫描 varbit chunk。但是，一旦找到起点，间隔中所有剩余的样本仍然需要按顺序解码，这对于 varbit 编码来说只是稍微昂贵一些。
对于从 chunk 中检索少量不相邻的样本，或者对于简单地检索所谓即时查询中的单个样本，权衡是不同的。存储引擎可能必须迭代大量样本才能找到要返回的少量样本。幸运的是，即时查询最常见的来源是引用每个涉及的时间序列中最新样本的规则评估。并非完全巧合，我最近改进了时间序列最新样本的检索。本质上，添加到时间序列的最后一个样本现在被缓存了。只需要时间序列最新样本的查询甚至不再访问 chunk 层，在这种情况下 chunk 编码无关紧要。
即使即时查询引用的是过去的样本，因此必须访问 chunk 层，查询的大部分其他部分（例如索引查找）也将主导总查询时间。但是，在实际查询中，varbit chunk 所需的顺序访问模式将开始变得非常重要。
varbit chunk 最坏情况的查询是什么？
varbit chunk 的最坏情况是，如果您只需要从每个 chunk 的中间某个位置获取一个样本，而这个 chunk 属于一个非常长的时间序列。不幸的是，这种情况确实存在实际用例。假设一个时间序列压缩得足够好，以至于每个 chunk 持续大约八个小时。那大约是一天三个 chunk，或一个月大约 100 个 chunk。如果您的仪表板显示过去一个月的时间序列，分辨率为 100 个数据点，则仪表板将执行一个查询，从 100 个不同的 chunk 中检索单个样本。即使那样，chunk 编码之间的差异也将被查询执行时间的其他部分所主导。根据具体情况，我猜测使用双 delta 编码查询可能需要 50 毫秒，而使用 varbit 编码查询可能需要 100 毫秒。
但是，如果您的仪表板查询不仅涉及单个时间序列，而且还聚合了数千个时间序列，则要访问的 chunk 数量会相应增加，并且顺序扫描的开销将变得 dominant。（这种查询是不受欢迎的，我们通常建议对经常使用的此类查询（例如在仪表板中）使用记录规则。）但是使用双 delta 编码，查询时间可能仍然可以接受，例如大约一秒。切换到 varbit 编码后，相同的查询可能持续数十秒，这显然不是您希望仪表板看到的。
经验法则是什么？
尽可能简单地说：如果您既不受磁盘容量的限制，也不受磁盘操作的限制，请不要担心，坚持使用经典的双 delta 编码的默认设置。
但是，如果您希望更长的保留时间，或者您目前受磁盘操作瓶颈的限制，我邀请您试用新的 varbit 编码。使用 -storage.local.chunk-encoding-version=2 启动您的 Prometheus 服务器并等待一段时间，直到您有足够的新 varbit 编码的 chunk 来验证效果。如果您看到查询变得无法接受地慢，请检查是否可以使用记录规则来加速它们。最有可能的是，即使使用旧的双 delta 编码，这些查询也将从中获得很多好处。
如果您对 varbit 编码在幕后是如何工作的感兴趣，请继续关注不久的将来的另一篇博文。