PRF:20170410 Writing a Time Series Database from Scratch.md

PART 1

translated/tech/20170410 Writing a Time Series Database from Scratch.md

@@ -1,16 +1,15 @@
 从零写一个时间序列数据库
-============================================================
-
+==================
 
 我从事监控工作。特别是在 [Prometheus][2] 上，监控系统包含一个自定义的时间序列数据库，并且集成在 [Kubernetes][3] 上。
 
-在许多方面上 Kubernetes 展现出了所有 Prometheus 的设计用途。它使得<ruby>持续部署<rt>continuous deployments</rt></ruby>，<ruby>弹性伸缩<rt>auto scaling</rt></ruby>和其他<ruby>高动态环境<rt>highly dynamic environments</rt></ruby>下的功能可以轻易地访问。在众多概念上的决策中，查询语句和操作模型使得 Prometheus 特别适合这种环境。但是，如果监控的工作负载动态程度显著地增加，这就会给监控系统本身带来新的压力。记住了这一点，而不是回过头来看 Prometheus 已经解决的很好的问题，我们就可以明确目标去提升它高动态或<ruby>瞬态服务<rt>transient services</rt></ruby>环境下的表现。
+在许多方面上 Kubernetes 展现出了 Prometheus 所有的设计用途。它使得<ruby>持续部署<rt>continuous deployments</rt></ruby>，<ruby>弹性伸缩<rt>auto scaling</rt></ruby>和其他<ruby>高动态环境<rt>highly dynamic environments</rt></ruby>下的功能可以轻易地访问。查询语句和操作模型以及其它概念决策使得 Prometheus 特别适合这种环境。但是，如果监控的工作负载动态程度显著地增加，这就会给监控系统本身带来新的压力。考虑到这一点，我们就可以特别致力于在高动态或<ruby>瞬态服务<rt>transient services</rt></ruby>环境下提升它的表现，而不是回过头来解决 Prometheus 已经解决的很好的问题。
 
-Prometheus 的存储层在很长一段时间里都展现出卓越的性能，单一服务器就能够以每秒数百多万个时间序列的速度摄入多达一百万个样本，同时只占用了很少的磁盘空间。尽管当前的存储做的很好，但我依旧提出一个新设计的存储子系统，它更正了现存解决方案的缺点，并具备处理更大规模数据的能力。
+Prometheus 的存储层在历史以来都展现出卓越的性能，单一服务器就能够以每秒数百万个时间序列的速度摄入多达一百万个样本，同时只占用了很少的磁盘空间。尽管当前的存储做的很好，但我依旧提出一个新设计的存储子系统，它可以修正现存解决方案的缺点，并具备处理更大规模数据的能力。
 
-注释：我没有数据库方面的背景。我说的东西可能是错的并让你误入歧途。你可以在 Freenode 的 #prometheus 频道上提出你的批评（fabxc）
+> 备注：我没有数据库方面的背景。我说的东西可能是错的并让你误入歧途。你可以在 Freenode 的 #prometheus 频道上对我（fabxc）提出你的批评。
 
-### 问题，难题，问题域
+## 问题，难题，问题域
 
 首先，快速地概览一下我们要完成的东西和它的关键难题。我们可以先看一下 Prometheus 当前的做法 ，它为什么做的这么好，以及我们打算用新设计解决哪些问题。
 
@@ -22,9 +21,9 @@ Prometheus 的存储层在很长一段时间里都展现出卓越的性能，单
 identifier -> (t0, v0), (t1, v1), (t2, v2), (t3, v3), ....
 ```
 
-每个数据点是一个时间戳和值的元组。在监控中，时间戳是一个整数，值可以是任意数字。64 位浮点数对于计数器和测量值来说是一个好的表示方法，因此我们将会使用它。一系列严格单调递增的时间戳数据点是一个序列，它由标识符所引用。我们的标识符是一个带有<ruby>标签维度<rt>label dimensions</rt></ruby>字典的度量名称。标签维度分开了单一指标的测量空间。每一个指标名称加上一个独一无二的标签集就成了它自己的时间序列，它有一个与之关联的<ruby>数据流<rt>value stream</rt></ruby>。
+每个数据点是一个时间戳和值的元组。在监控中，时间戳是一个整数，值可以是任意数字。64 位浮点数对于计数器和测量值来说是一个好的表示方法，因此我们将会使用它。一系列严格单调递增的时间戳数据点是一个序列，它由标识符所引用。我们的标识符是一个带有<ruby>标签维度<rt>label dimensions</rt></ruby>字典的度量名称。标签维度划分了单一指标的测量空间。每一个指标名称加上一个唯一标签集就成了它自己的时间序列，它有一个与之关联的<ruby>数据流<rt>value stream</rt></ruby>。
 
-这是一个典型的<ruby>序列标识符<rt>series identifiers </rt></ruby>集，它是统计请求指标的一部分：
+这是一个典型的<ruby>序列标识符<rt>series identifier</rt></ruby>集，它是统计请求指标的一部分：
 
 ```
 requests_total{path="/status", method="GET", instance=”10.0.0.1:80”}
@@ -41,6 +40,7 @@ requests_total{path="/", method="GET", instance=”10.0.0.2:80”}
 ```
 
 我们想通过标签来查询时间序列数据。在最简单的情况下，使用 `{__name__="requests_total"}` 选择所有属于 `requests_total` 指标的数据。对于所有选择的序列，我们在给定的时间窗口内获取数据点。
+
 在更复杂的语句中，我们或许想一次性选择满足多个标签的序列，并且表示比相等条件更复杂的情况。例如，非语句（`method!="GET"`）或正则表达式匹配（`method=~"PUT|POST"`）。 
 
 这些在很大程度上定义了存储的数据和它的获取方式。
@@ -66,24 +66,31 @@ series
     <-------------------- time --------------------->
 ```
 
-Prometheus 通过定期地抓取一组时间序列的当前值来获取数据点。我们获取到的实体称为目标。因此，写入模式完全地垂直且高度并发，因为来自每个目标的样本是独立摄入的。这里提供一些测量的规模：单一 Prometheus 实例从成千上万的目标中收集数据点，每个数据点都暴露在成百上千个不同的时间序列中。
+Prometheus 通过定期地抓取一组时间序列的当前值来获取数据点。我们从中获取到的实体称为目标。因此，写入模式完全地垂直且高度并发，因为来自每个目标的样本是独立摄入的。
+
+这里提供一些测量的规模：单一 Prometheus 实例从数万个目标中收集数据点，每个数据点都暴露在数百到数千个不同的时间序列中。
 
 在每秒采集数百万数据点这种规模下，批量写入是一个不能妥协的性能要求。在磁盘上分散地写入单个数据点会相当地缓慢。因此，我们想要按顺序写入更大的数据块。
-对于旋转式磁盘，它的磁头始终得物理上地向不同的扇区上移动，这是一个不足为奇的事实。而我们都知道 SSD 具有快速随机写入的特点，但事实上它不能修改单独的字节，只能写入一页 4KiB 或更多的数据量。这就意味着写入 16 字节的样本相当于写入满满一个 4Kib 的页。这一行为部分上属于[写入放大][4]，这种特性会损耗你的 SSD。因此它不仅影响速度，而且还毫不夸张地在几天或几个周内破坏掉你的硬件。
-关于此问题更深层次的资料，[“Coding for SSDs”系列][5]博客是极好的资源。让我们想想有什么收获：顺序写入和批量写入对于旋转式磁盘和 SSD 来说都是理想的写入模式。大道至简。
 
-查询模式比起写入模式千差万别。我们可以查询单一序列的一个数据点，也可以为 10000 个序列查询一个数据点，还可以查询一个序列几个周的数据点，甚至是 10000 个序列几个周的数据点。因此在我们的二维平面上，查询范围不是完全水平或垂直的，而是二者形成矩形似的组合。
-[记录规则][6]减轻了已知查询的问题，但对于<ruby>点对点<rt>ad-hoc</rt></ruby>查询来说并不是一个通用的解决方法。
+对于旋转式磁盘，它的磁头始终得在物理上向不同的扇区上移动，这是一个不足为奇的事实。而虽然我们都知道 SSD 具有快速随机写入的特点，但事实上它不能修改单个字节，只能写入一页或更多页的 4KiB 数据量。这就意味着写入 16 字节的样本相当于写入满满一个 4Kib 的页。这一行为就是所谓的[写入放大][4]，这种特性会损耗你的 SSD。因此它不仅影响速度，而且还毫不夸张地在几天或几个周内破坏掉你的硬件。
 
-我们知道自己想要批量地写入，但我们得到的仅仅是一系列垂直数据点的集合。当查询一段时间窗口内的数据点时，我们不仅很难弄清楚在哪才能找到这些单独的点，而且不得不从磁盘上大量随机的地方读取。也许一条查询语句会有数百万的样本，即使在最快的 SSD 上也会很慢。读入也会从磁盘上获取更多的数据而不仅仅是 16 字节的样本。SSD 会加载一整页，HDD 至少会读取整个扇区。不论哪一种，我们都在浪费宝贵的读吞吐量。
-因此在理想上，相同序列的样本将按顺序存储，这样我们就能通过尽可能少的读取来扫描它们。在上层，我们仅需要知道序列的起始位置就能访问所有的数据点。
+关于此问题更深层次的资料，[“Coding for SSDs”系列][5]博客是极好的资源。让我们想想主要的用处：顺序写入和批量写入分别对于旋转式磁盘和 SSD 来说都是理想的写入模式。大道至简。
 
-显然，将收集到的数据写入磁盘的理想模式与能够显著提高查询效率的布局之间存在着很强的张力。这是我们  TSDB 需要解决的一个基本问题。
+查询模式比起写入模式明显更不同。我们可以查询单一序列的一个数据点，也可以对 10000 个序列查询一个数据点，还可以查询一个序列几个周的数据点，甚至是 10000 个序列几个周的数据点。因此在我们的二维平面上，查询范围不是完全水平或垂直的，而是二者形成矩形似的组合。
 
-#### 当前的解法
+[记录规则][6]可以减轻已知查询的问题，但对于<ruby>点对点<rt>ad-hoc</rt></ruby>查询来说并不是一个通用的解决方法。
+
+我们知道我们想要批量地写入，但我们得到的仅仅是一系列垂直数据点的集合。当查询一段时间窗口内的数据点时，我们不仅很难弄清楚在哪才能找到这些单独的点，而且不得不从磁盘上大量随机的地方读取。也许一条查询语句会有数百万的样本，即使在最快的 SSD 上也会很慢。读入也会从磁盘上获取更多的数据而不仅仅是 16 字节的样本。SSD 会加载一整页，HDD 至少会读取整个扇区。不论哪一种，我们都在浪费宝贵的读取吞吐量。
+
+因此在理想情况下，同一序列的样本将按顺序存储，这样我们就能通过尽可能少的读取来扫描它们。最重要的是，我们仅需要知道序列的起始位置就能访问所有的数据点。
+
+显然，将收集到的数据写入磁盘的理想模式与能够显著提高查询效率的布局之间存在着明显的抵触。这是我们  TSDB 需要解决的一个基本问题。
+
+#### 当前的解决方法
 
 是时候看一下当前 Prometheus 是如何存储数据来解决这一问题的，让我们称它为“V2”。
-我们创建一个时间序列的文件，它包含所有样本并按顺序存储。因为每几秒附加一个样本数据到所有文件中非常昂贵，我们打包 1Kib 样本序列的数据块在内存中，一旦打包完成就附加这些数据块到单独的文件中。这一方法解决了大部分问题。写入目前是批量的，样本也是按顺序存储的。它还支持非常高效的压缩格式，基于给定的同一序列的样本相对之前的数据仅发生非常小的改变这一特性。Facebook 在他们 Gorilla TSDB 上的论文中描述了一个相似的基于数据块的方法，并且[引入了一种压缩格式][7]，它能够减少 16 字节的样本到平均 1.37 字节。V2 存储使用了包含 Gorilla 等的各种压缩格式。
+
+我们创建一个时间序列的文件，它包含所有样本并按顺序存储。因为每几秒附加一个样本数据到所有文件中非常昂贵，我们在内存中打包 1Kib 样本序列的数据块，一旦打包完成就附加这些数据块到单独的文件中。这一方法解决了大部分问题。写入目前是批量的，样本也是按顺序存储的。基于给定的同一序列的样本相对之前的数据仅发生非常小的改变这一特性，它还支持非常高效的压缩格式。Facebook 在他们 Gorilla TSDB 上的论文中描述了一个相似的基于数据块的方法，并且[引入了一种压缩格式][7]，它能够减少 16 字节的样本到平均 1.37 字节。V2 存储使用了包含 Gorilla 变体等在内的各种压缩格式。
 
 ```
    ┌──────────┬─────────┬─────────┬─────────┬─────────┐           series A
@@ -98,18 +105,21 @@ Prometheus 通过定期地抓取一组时间序列的当前值来获取数据点
 
 尽管基于块存储的方法非常棒，但为每个序列保存一个独立的文件会给 V2 存储带来麻烦，因为：
 
-* 我们实际上需要比当前收集的时间序列数目使用更多的文件。多出的部分在<ruby>序列分流<rt>Series Churn</rt></ruby>上。拥有几百万个文件，迟早会使用光文件系统中的 [inodes][1]。这种情况我们只可以通过重新格式化来恢复磁盘，这种方式是最具有破坏性的。我们通常想要避免为了适应一个应用程序而格式化磁盘。
-* 即使是分块写入，每秒也会产生几千万块的数据块并且准备持久化。这依然需要每秒数千个次的磁盘写入量。尽管通过为每个序列打包好多个块来缓解，但反过来还是增加了等待持久化数据的总内存占用。
-* 要保持所有文件的打开状态进行读写是不可行的。特别是因为 99% 的数据在 24 小时之后不再会被查询到。如果它还是被查询到，我们就得打开数千个文件，找到并读取相关的数据点到内存中，然后再关掉。这样做就会引起很高的查询延迟，数据块缓存加剧会导致新的问题，这一点在“资源消耗”一节另作讲述。
-* 最终，旧的数据需要被删除并且数据需要从数百万文件的头部删除。这就意味着删除实际上是高强度的写入操作。此外，循环遍历数百万文件并且进行分析通常会导致这一过程花费数小时。当它完成时，可能又得重新来过。喔天，继续删除旧文件又会进一步导致 SSD 产生写入放大。
-* 目前所积累的数据块仅维持在内存中。如果应用崩溃，数据就会丢失。为了避免这种情况，内存状态会定期的保存在磁盘上，这比我们能接受数据丢失的时间要长的多。恢复检查点也会花费数分钟，导致很长的重启周期。
+* 实际上，我们需要的文件比当前收集数据的时间序列数量要多得多。多出的部分在<ruby>序列分流<rt>Series Churn</rt></ruby>上。有几百万个文件，迟早会使用光文件系统中的 [inode][1]。这种情况我们只能通过重新格式化来恢复磁盘，这种方式是最具有破坏性的。我们通常不想为了适应一个应用程序而格式化磁盘。
+* 即使是分块写入，每秒也会产生数千块的数据块并且准备持久化。这依然需要每秒数千次的磁盘写入。尽管通过为每个序列打包好多个块来缓解，但这反过来还是增加了等待持久化数据的总内存占用。
+* 要保持所有文件打开来进行读写是不可行的。特别是因为 99% 的数据在 24 小时之后不再会被查询到。如果查询它，我们就得打开数千个文件，找到并读取相关的数据点到内存中，然后再关掉。这样做就会引起很高的查询延迟，数据块缓存加剧会导致新的问题，这一点在“资源消耗”一节另作讲述。
+* 最终，旧的数据需要被删除，并且数据需要从数百万文件的头部删除。这就意味着删除实际上是写密集型操作。此外，循环遍历数百万文件并且进行分析通常会导致这一过程花费数小时。当它完成时，可能又得重新来过。喔天，继续删除旧文件又会进一步导致 SSD 产生写入放大。
+* 目前所积累的数据块仅维持在内存中。如果应用崩溃，数据就会丢失。为了避免这种情况，内存状态会定期的保存在磁盘上，这比我们能接受数据丢失窗口要长的多。恢复检查点也会花费数分钟，导致很长的重启周期。
 
-我们能够从现有的设计中学到的关键部分是数据块的概念，这一点会依旧延续。最近一段时间的数据块会保持在内存中也大体上不错。毕竟，最近时间段的数据会大量的查询到。一个时间序列对应一个文件，这种概念是我们想要替换掉的。
+我们能够从现有的设计中学到的关键部分是数据块的概念，我们当然希望保留这个概念。最新的数据块会保持在内存中一般也是好的主意。毕竟，最新的数据会大量的查询到。
+
+一个时间序列对应一个文件，这个概念是我们想要替换掉的。
 
 ### 序列分流
 
-在 Prometheus 的<ruby>上下文<rt>context</rt></ruby>中，我们使用术语<ruby>序列分流<rt>series churn</rt></ruby>来描述不活越的时间序列集合，即不再接收数据点，取而代之的是出现一组新的活跃序列。
-例如，由给定微服务实例产生的所有序列都有一个相对的“instance”标签来标识它的起源。如果我们为微服务执行了<ruby>滚动更新<rt>rolling update</rt></ruby>，并且为每个实例替换一个新的版本，序列分流便会发生。在更加动态的环境中，这些事情基本上每小时都会发生。像 Kubernetes 这样的<ruby>集群编排<rt>Cluster orchestration</rt></ruby>系统允许应用连续性的自动伸缩和频繁的滚动更新，这样也许会创建成千上万个新的应用程序实例，并且伴随着全新的时间序列集合，每天都是如此。
+在 Prometheus 的<ruby>上下文<rt>context</rt></ruby>中，我们使用术语<ruby>序列分流<rt>series churn</rt></ruby>来描述一个时间序列集合变得不活跃，即不再接收数据点，取而代之的是出现一组新的活跃序列。
+
+例如，由给定微服务实例产生的所有序列都有一个相应的“instance”标签来标识其来源。如果我们为微服务执行了<ruby>滚动更新<rt>rolling update</rt></ruby>，并且为每个实例替换一个新的版本，序列分流便会发生。在更加动态的环境中，这些事情基本上每小时都会发生。像 Kubernetes 这样的<ruby>集群编排<rt>Cluster orchestration</rt></ruby>系统允许应用连续性的自动伸缩和频繁的滚动更新，这样也许会创建成千上万个新的应用程序实例，并且伴随着全新的时间序列集合，每天都是如此。
 
 ```
 series
@@ -129,14 +139,15 @@ series
     <-------------------- time --------------------->
 ```
 
-所以即便整个基础设施的规模基本保持不变，过一段时间后数据库内的时间序列还是会成线性增长。尽管 Prometheus 很愿意采集 1000 万个时间序列数据，但要想在 10 亿的序列中找到数据，查询效果还是会受到严重的影响。
+所以即便整个基础设施的规模基本保持不变，过一段时间后数据库内的时间序列还是会成线性增长。尽管 Prometheus 很愿意采集 1000 万个时间序列数据，但要想在 10 亿个序列中找到数据，查询效果还是会受到严重的影响。
 
-#### 当前解法
+#### 当前解决方案
+
+当前 Prometheus 的 V2 存储系统对所有当前保存的序列拥有基于 LevelDB 的索引。它允许查询语句含有给定的<ruby>标签对<rt>label pair</rt></ruby>，但是缺乏可伸缩的方法来从不同的标签选集中组合查询结果。
 
-当前 Prometheus 的 V2 存储系统对所有保存的序列拥有基于 LevelDB 的索引。它允许查询语句含有给定的<ruby>标签对<rt>label pair</rt></ruby>，但是缺乏可伸缩的方法来从不同的标签选集中组合查询结果。
 例如，从所有的序列中选择标签 `__name__="requests_total"` 非常高效，但是选择  `instance="A" AND __name__="requests_total"` 就有了可伸缩性的问题。我们稍后会重新考虑导致这一点的原因和能够提升查找延迟的调整方法。
 
-事实上正是这个问题才催生出了对更好的存储系统的最初探索。Prometheus 需要为查找亿万的时间序列改进索引方法。
+事实上正是这个问题才催生出了对更好的存储系统的最初探索。Prometheus 需要为查找亿万个时间序列改进索引方法。
 
 ### 资源消耗