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

PART 3

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

@@ -253,10 +253,11 @@ t0            t1             t2             t3             now
 
 #### 压缩
 
-存储系统需要定期的“切”出新块并写入之前完成的块到磁盘中。仅在块成功的持久化之后，写之前用来恢复内存块的日志文件（wal）才会被删除。
-我们很乐意将每个块的保存时间设置的相对短一些（通常配置为 2 小时）以避免内存中积累太多的数据。当查询多个块，我们必须合并它们的结果为一个完成的结果。合并过程显然会消耗资源，一个周的查询不应该由 80 多个部分结果所合并。
+存储系统需要定期“切”出新块并将之前完成的块写入到磁盘中。仅在块成功的持久化之后，才会被删除之前用来恢复内存块的日志文件（wal）。
 
-为了实现两者，我们引入<ruby>压缩<rt>compaction</rt></ruby>。压缩描述了一个过程：取一个或更多个数据块并将其写入一个可能更大的块中。它也可以在此过程中修改现有的数据。例如，清除已经删除的数据，或为提升查询性能重建样本块。
+我们希望将每个块的保存时间设置的相对短一些（通常配置为 2 小时），以避免内存中积累太多的数据。当查询多个块，我们必须将它们的结果合并为一个整体的结果。合并过程显然会消耗资源，一个星期的查询不应该由超过 80 个的部分结果所组成。
+
+为了实现两者，我们引入<ruby>压缩<rt>compaction</rt></ruby>。压缩描述了一个过程：取一个或更多个数据块并将其写入一个可能更大的块中。它也可以在此过程中修改现有的数据。例如，清除已经删除的数据，或重建样本块以提升查询性能。
 
 ```
 
@@ -272,11 +273,11 @@ t0             t1            t2             t3             t4             now
  └──────────────────────────┘  └──────────────────────────┘  └───────────┘
 ```
 
-在这个例子中我们有一系列块`[1,2,3,4]`。块 1，2 ，3 可以压缩在一起，新的布局将会是 `[1,4]`。或者，将它们成对压缩为 `[1,3]`。所有的时间序列数据仍然存在，但现在整体上保存在更少的块中。这极大程度地缩减了查询时间的消耗，因为需要合并的部分查询结果变得更少了。
+在这个例子中我们有顺序块 `[1,2,3,4]`。块 1、2、3 可以压缩在一起，新的布局将会是 `[1,4]`。或者，将它们成对压缩为 `[1,3]`。所有的时间序列数据仍然存在，但现在整体上保存在更少的块中。这极大程度地缩减了查询时间的消耗，因为需要合并的部分查询结果变得更少了。
 
 #### 保留
 
-我们看到了删除旧的数据在 V2 存储系统中是一个缓慢的过程，并且消耗 CPU、内存和磁盘。如何才能在我们基于块的设计上清除旧的数据？相当简单，只要根据块文件夹下的配置的保留窗口里有无数据而删除该文件夹。在下面的例子中，块 1 可以被安全地删除，而块 2 则必须一直保持到界限后面。
+我们看到了删除旧的数据在 V2 存储系统中是一个缓慢的过程，并且消耗 CPU、内存和磁盘。如何才能在我们基于块的设计上清除旧的数据？相当简单，只要删除我们配置的保留时间窗口里没有数据的块文件夹即可。在下面的例子中，块 1 可以被安全地删除，而块 2 则必须一直保留，直到它落在保留窗口边界之外。
 
 ```
                       |
@@ -288,16 +289,19 @@ t0             t1            t2             t3             t4             now
              retention boundary
 ```
 
-得到越旧的数据，保存的块也就越大，因为我们会压缩之前的压缩块。因此必须为其设置一个上限，以防数据块扩展到整个数据库而损失我们设计的最初优势。
-方便的是，这一点也限制了部分存在于保留窗口内部分存在于保留窗口外的总磁盘块的消耗。例如上面例子中的块 2。当设置了最大块尺寸为总保留窗口的 10% 后，我们保留块 2 的总开销也有了 10% 的上限。
+随着我们不断压缩先前压缩的块，旧数据越大，块可能变得越大。因此必须为其设置一个上限，以防数据块扩展到整个数据库而损失我们设计的最初优势。
+
+方便的是，这一点也限制了部分存在于保留窗口内部分存在于保留窗口外的块的磁盘消耗总量。例如上面例子中的块 2。当设置了最大块尺寸为总保留窗口的 10% 后，我们保留块 2 的总开销也有了 10% 的上限。
 
 总结一下，保留与删除从非常昂贵到了几乎没有成本。
 
-> 如果你读到这里并有一些数据库的背景知识，现在你也许会问：这些都是最新的技术吗？——并不是。而且可能还会做的更好。
-
->  在内存中打包数据，定期的写入日志并刷新磁盘的模式在现在相当普遍。
->  我们看到的好处无论在什么领域的数据里都是适用的。遵循这一方法最著名的开源案例是 LevelDB，Cassandra，InfluxDB 和 HBase。关键是避免重复发明劣质的轮子，采用经得起验证的方法，并正确地运用它们。
->  这里仍有地方来添加你自己的黑魔法。
+> 如果你读到这里并有一些数据库的背景知识，现在你也许会问：这些都是最新的技术吗？——并不是；而且可能还会做的更好。
+> 
+> 在内存中批量处理数据，在预写日志中跟踪，并定期写入到磁盘的模式在现在相当普遍。
+> 
+> 我们看到的好处无论在什么领域的数据里都是适用的。遵循这一方法最著名的开源案例是 LevelDB、Cassandra、InfluxDB 和 HBase。关键是避免重复发明劣质的轮子，采用经过验证的方法，并正确地运用它们。
+> 
+> 脱离场景添加你自己的黑魔法是一种不太可能的情况。
 
 ### 索引