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

PART 4

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

@@ -305,27 +305,31 @@ t0             t1            t2             t3             t4             now
 
 ### 索引
 
-研究存储改进的最初想法是解决序列分流的问题。基于块的布局减少了查询所要考虑的序列总数。因此假设我们索引查找的复杂度是 `O(n^2)`，我们就要设法减少 n 个相当数量的复杂度，之后就有了改进后 `O(n^2)` 的复杂度。——恩，等等...糟糕。
-快速地想想“算法 101”课上提醒我们的，在理论上它并未带来任何好处。如果之前就很糟糕，那么现在也一样。理论是如此的残酷。
+研究存储改进的最初想法是解决序列分流的问题。基于块的布局减少了查询所要考虑的序列总数。因此假设我们索引查找的复杂度是 `O(n^2)`，我们就要设法减少 n 个相当数量的复杂度，之后就相当于改进 `O(n^2)` 复杂度。——恩，等等……糟糕。
 
-实际上，我们大多数的查询已经可以相当快地被相应。但是，跨越整个时间范围的查询仍然很慢，尽管只需要找到少部分数据。追溯到所有这些工作之前，最初我用来解决这个问题的想法是：我们需要一个更大容量的[倒排索引][9]。倒排索引基于数据项内容的子集提供了一种快速的查找方式。简单地说，我可以通过标签 `app=”nginx"` 查找所有的序列而无需遍历每个文件来看它是否包含该标签。
+快速回顾一下“算法 101”课上提醒我们的，在理论上它并未带来任何好处。如果之前就很糟糕，那么现在也一样。理论是如此的残酷。
 
-为此，每个序列被赋上一个唯一的 ID 来在常数时间内获取，例如 O(1)。在这个例子中 ID 就是 我们的正向索引。
+实际上，我们大多数的查询已经可以相当快响应。但是，跨越整个时间范围的查询仍然很慢，尽管只需要找到少部分数据。追溯到所有这些工作之前，最初我用来解决这个问题的想法是：我们需要一个更大容量的[倒排索引][9]。
 
-> 示例：如果 ID 为 10，29 ，9 的序列包含标签 `app="nginx"`，那么 “nginx”的倒排索引就是简单的列表 `[10, 29, 9]`，它就能用来快速地获取所有包含标签的序列。即使有 200 多亿个数据也不会影响查找速度。
+倒排索引基于数据项内容的子集提供了一种快速的查找方式。简单地说，我可以通过标签 `app="nginx"` 查找所有的序列而无需遍历每个文件来看它是否包含该标签。
+
+为此，每个序列被赋上一个唯一的 ID ，通过该 ID 可以恒定时间内检索它（`O(1)`）。在这个例子中 ID 就是我们的正向索引。
+
+> 示例：如果 ID 为 10、29、9 的序列包含标签 `app="nginx"`，那么 “nginx”的倒排索引就是简单的列表 `[10, 29, 9]`，它就能用来快速地获取所有包含标签的序列。即使有 200 多亿个数据序列也不会影响查找速度。
  
-简而言之，如果 n 是我们序列总数，m 是给定查询结果的大小，使用索引的查询复杂度现在就是 O(m)。查询语句跟随它获取数据的数量 m 而不是被搜索的数据体 n 所扩展是一个很好的特性，因为 m 一般相当小。
-为了简单起见，我们假设可以在常数时间内查找到倒排索引对应的列表。
+简而言之，如果 `n` 是我们序列总数，`m` 是给定查询结果的大小，使用索引的查询复杂度现在就是 `O(m)`。查询语句依据它获取数据的数量 `m` 而不是被搜索的数据体 `n` 进行缩放是一个很好的特性，因为 `m` 一般相当小。
 
-实际上，这几乎就是 V2 存储系统已有的倒排索引，也是提供在数百万序列中查询性能的最低需求。敏锐的人会注意到，在最坏情况下，所有的序列都含有标签，因此 m 又成了 O(n)。这一点在预料之中也相当合理。如果你查询所有的数据，它自然就会花费更多时间。一旦我们牵扯上了更复杂的查询语句就会有问题出现。
+为了简单起见，我们假设可以在恒定时间内查找到倒排索引对应的列表。
+
+实际上，这几乎就是 V2 存储系统具有的倒排索引，也是提供在数百万序列中查询性能的最低需求。敏锐的人会注意到，在最坏情况下，所有的序列都含有标签，因此 `m` 又成了 `O(n)`。这一点在预料之中，也相当合理。如果你查询所有的数据，它自然就会花费更多时间。一旦我们牵扯上了更复杂的查询语句就会有问题出现。
 
 #### 标签组合
 
-数百万个带有标签的数据很常见。假设横向扩展着数百个实例的“foo”微服务，并且每个实例拥有数千个序列。每个序列都会带有标签`app="foo"`。当然，用户通常不会查询所有的序列而是会通过进一步的标签来限制查询。例如，我想知道服务实例接收到了多少请求，那么查询语句便是 `__name__="requests_total" AND app="foo"`。
+与数百万个序列相关的标签很常见。假设横向扩展着数百个实例的“foo”微服务，并且每个实例拥有数千个序列。每个序列都会带有标签 `app="foo"`。当然，用户通常不会查询所有的序列而是会通过进一步的标签来限制查询。例如，我想知道服务实例接收到了多少请求，那么查询语句便是 `__name__="requests_total" AND app="foo"`。
 
-为了找到适应所有标签选择子的序列，我们得到每一个标签的倒排索引列表并取其交集。结果集通常会比任何一个输入列表小一个数量级。因为每个输入列表最坏情况下的尺寸为 O(n)，所以在嵌套地为每个列表进行<ruby>暴力求解<rt>brute force solution</rt><ruby>下，运行时间为 O(n^2)。与其他的集合操作耗费相同，例如取并集 (`app="foo" OR app="bar"`)。当添加更多标签选择子在查询语句上，耗费就会指数增长到 O(n^3), O(n^4), O(n^5), ... O(n^k)。有很多手段都能通过改变执行顺序优化运行效率。越复杂，越是需要关于数据特征和标签之间相关性的知识。这引入了大量的复杂度，但是并没有减少算法的最坏运行时间。
+为了找到满足两个标签选择子的所有序列，我们得到每一个标签的倒排索引列表并取其交集。结果集通常会比任何一个输入列表小一个数量级。因为每个输入列表最坏情况下的大小为 `O(n)`，所以在嵌套地为每个列表进行<ruby>暴力求解<rt>brute force solution</rt><ruby>下，运行时间为 `O(n^2)`。相同的成本也适用于其他的集合操作，例如取并集（`app="foo" OR app="bar"`）。当在查询语句上添加更多标签选择子，耗费就会指数增长到 `O(n^3)`、`O(n^4)`、`O(n^5)`……`O(n^k)`。通过改变执行顺序，可以使用很多技巧以优化运行效率。越复杂，越是需要关于数据特征和标签之间相关性的知识。这引入了大量的复杂度，但是并没有减少算法的最坏运行时间。
 
-这便是 V2 存储系统使用的基本方法，幸运的是，似乎稍微的改动就能获得很大的提升。如果我们假设倒排索引中的 ID 都是排序好的会怎么样？
+这便是 V2 存储系统使用的基本方法，幸运的是，看似微小的改动就能获得显著的提升。如果我们假设倒排索引中的 ID 都是排序好的会怎么样？
 
 假设这个例子的列表用于我们最初的查询：
 
@@ -336,13 +340,17 @@ __name__="requests_total"   ->   [ 9999, 1000, 1001, 2000000, 2000001, 2000002,
              intersection   =>   [ 1000, 1001 ]
 ```
 
-它的交集相当小。我们可以为每个列表的起始位置设置游标，每次从最小的游标处移动来找到交集。当二者的数字相等，我们就添加它到结果中并移动二者的游标。总体上，我们以锯齿形扫描两个列表，因此总耗费是 O(2n)=O(n)，因为我们总是在一个列表上移动。
+它的交集相当小。我们可以为每个列表的起始位置设置游标，每次从最小的游标处移动来找到交集。当二者的数字相等，我们就添加它到结果中并移动二者的游标。总体上，我们以锯齿形扫描两个列表，因此总耗费是 `O(2n)=O(n)`，因为我们总是在一个列表上移动。
 
-两个以上列表的不同集合操作也类似。因此 k 个集合操作仅仅改变了因子 O(k*n) 而不是最坏查找运行时间下的指数 O(n^k)。
-我在这里所描述的是任意一个[全文搜索引擎][10]使用的标准搜索索引的简化版本。每个序列描述符都视作一个简短的“文档”，每个标签（名称 + 固定值）作为其中的“单词”。我们可以忽略搜索引擎索引中很多附加的数据，例如单词位置和和频率。
-似乎存在着无止境的研究来提升实际的运行时间，通常都是对输入数据做一些假设。不出意料的是，仍有大量技术来压缩倒排索引，其中各有利弊。因为我们的“文档”比较小，而且“单词”在所有的序列里大量重复，压缩变得几乎无关紧要。例如，一个真实的数据集约有 440 万个序列与大约 12 个标签，每个标签拥有少于 5000 个单独的标签。对于最初的存储版本，我们坚持基本的方法不使用压缩，仅做微小的调整来跳过大范围非交叉的 ID。
+两个以上列表的不同集合操作也类似。因此 `k` 个集合操作仅仅改变了因子 `O(k*n)` 而不是最坏情况下查找运行时间的指数 `O(n^k)`。
 
-尽管维持排序好的 ID 听起来很简单，但实践过程中不是总能完成的。例如，V2 存储系统为新的序列赋上一个哈希值来当作 ID，我们就不能轻易地排序倒排索引。另一个艰巨的任务是当磁盘上的数据被更新或删除掉后修改其索引。通常，最简单的方法是重新计算并写入，但是要保证数据库在此期间可查询且具有一致性。V3 存储系统通过每块上独立的不可变索引来解决这一问题，仅通过压缩时的重写来进行修改。只有可变块上的索引需要被更新，它完全保存在内存中。
+我在这里所描述的是几乎所有[全文搜索引擎][10]使用的标准搜索索引的简化版本。每个序列描述符都视作一个简短的“文档”，每个标签（名称 + 固定值）作为其中的“单词”。我们可以忽略搜索引擎索引中通常遇到的很多附加数据，例如单词位置和和频率。
+
+关于改进实际运行时间的方法似乎存在无穷无尽的研究，它们通常都是对输入数据做一些假设。不出意料的是，还有大量技术来压缩倒排索引，其中各有利弊。因为我们的“文档”比较小，而且“单词”在所有的序列里大量重复，压缩变得几乎无关紧要。例如，一个真实的数据集约有 440 万个序列与大约 12 个标签，每个标签拥有少于 5000 个单独的标签。对于最初的存储版本，我们坚持使用基本的方法而不压缩，仅做微小的调整来跳过大范围非交叉的 ID。
+
+尽管维持排序好的 ID 听起来很简单，但实践过程中不是总能完成的。例如，V2 存储系统为新的序列赋上一个哈希值来当作 ID，我们就不能轻易地排序倒排索引。
+
+另一个艰巨的任务是当磁盘上的数据被更新或删除掉后修改其索引。通常，最简单的方法是重新计算并写入，但是要保证数据库在此期间可查询且具有一致性。V3 存储系统通过每块上具有的独立不可变索引来解决这一问题，该索引仅通过压缩时的重写来进行修改。只有可变块上的索引需要被更新，它完全保存在内存中。
 
 ### 基准测试