diff --git a/translated/tech/20170410 Writing a Time Series Database from Scratch.md b/translated/tech/20170410 Writing a Time Series Database from Scratch.md index 60d302b2de..9093e4dc2a 100644 --- a/translated/tech/20170410 Writing a Time Series Database from Scratch.md +++ b/translated/tech/20170410 Writing a Time Series Database from Scratch.md @@ -1,6 +1,12 @@ 从零写一个时间序列数据库 ================== +编者按：Prometheus 是 CNCF 旗下的开源监控告警解决方案，它已经成为 Kubernetes 生态圈中的核心监控系统。本文作者 Fabian Reinartz 是 Prometheus 的核心开发者，这篇文章是其于 2017 年写的一篇关于 Prometheus 中的时间序列数据库的设计思考，虽然写作时间有点久了，但是其中的考虑和思路非常值得参考。长文预警，请坐下来慢慢品味。 + +--- + +![](https://img.linux.net.cn/data/attachment/album/201906/11/180646l7cqbhazqs7nsqsn.jpg) + 我从事监控工作。特别是在 [Prometheus][2] 上，监控系统包含一个自定义的时间序列数据库，并且集成在 [Kubernetes][3] 上。 在许多方面上 Kubernetes 展现出了 Prometheus 所有的设计用途。它使得持续部署continuous deployments，弹性伸缩auto scaling和其他高动态环境highly dynamic environments下的功能可以轻易地访问。查询语句和操作模型以及其它概念决策使得 Prometheus 特别适合这种环境。但是，如果监控的工作负载动态程度显著地增加，这就会给监控系统本身带来新的压力。考虑到这一点，我们就可以特别致力于在高动态或瞬态服务transient services环境下提升它的表现，而不是回过头来解决 Prometheus 已经解决的很好的问题。 @@ -52,16 +58,16 @@ requests_total{path="/", method="GET", instance=”10.0.0.2:80”} ``` series ^ - │ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="GET"} - │ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="POST"} - │ . . . . . . . - │ . . . . . . . . . . . . . . . . . . . ... - │ . . . . . . . . . . . . . . . . . . . . . - │ . . . . . . . . . . . . . . . . . . . . . {__name__="errors_total", method="POST"} - │ . . . . . . . . . . . . . . . . . {__name__="errors_total", method="GET"} - │ . . . . . . . . . . . . . . - │ . . . . . . . . . . . . . . . . . . . ... - │ . . . . . . . . . . . . . . . . . . . . + | . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="GET"} + | . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="POST"} + | . . . . . . . + | . . . . . . . . . . . . . . . . . . . ... + | . . . . . . . . . . . . . . . . . . . . . + | . . . . . . . . . . . . . . . . . . . . . {__name__="errors_total", method="POST"} + | . . . . . . . . . . . . . . . . . {__name__="errors_total", method="GET"} + | . . . . . . . . . . . . . . + | . . . . . . . . . . . . . . . . . . . ... + | . . . . . . . . . . . . . . . . . . . . v <-------------------- time ---------------------> ``` @@ -93,13 +99,13 @@ Prometheus 通过定期地抓取一组时间序列的当前值来获取数据点 我们创建一个时间序列的文件，它包含所有样本并按顺序存储。因为每几秒附加一个样本数据到所有文件中非常昂贵，我们在内存中打包 1Kib 样本序列的数据块，一旦打包完成就附加这些数据块到单独的文件中。这一方法解决了大部分问题。写入目前是批量的，样本也是按顺序存储的。基于给定的同一序列的样本相对之前的数据仅发生非常小的改变这一特性，它还支持非常高效的压缩格式。Facebook 在他们 Gorilla TSDB 上的论文中描述了一个相似的基于数据块的方法，并且[引入了一种压缩格式][7]，它能够减少 16 字节的样本到平均 1.37 字节。V2 存储使用了包含 Gorilla 变体等在内的各种压缩格式。 ``` - ┌──────────┬─────────┬─────────┬─────────┬─────────┐ series A - └──────────┴─────────┴─────────┴─────────┴─────────┘ - ┌──────────┬─────────┬─────────┬─────────┬─────────┐ series B - └──────────┴─────────┴─────────┴─────────┴─────────┘ + +----------+---------+---------+---------+---------+ series A + +----------+---------+---------+---------+---------+ + +----------+---------+---------+---------+---------+ series B + +----------+---------+---------+---------+---------+ . . . - ┌──────────┬─────────┬─────────┬─────────┬─────────┬─────────┐ series XYZ - └──────────┴─────────┴─────────┴─────────┴─────────┴─────────┘ + +----------+---------+---------+---------+---------+---------+ series XYZ + +----------+---------+---------+---------+---------+---------+ chunk 1 chunk 2 chunk 3 ... ``` @@ -124,17 +130,17 @@ Prometheus 通过定期地抓取一组时间序列的当前值来获取数据点 ``` series ^ - │ . . . . . . - │ . . . . . . - │ . . . . . . - │ . . . . . . . - │ . . . . . . . - │ . . . . . . . - │ . . . . . . - │ . . . . . . - │ . . . . . - │ . . . . . - │ . . . . . + | . . . . . . + | . . . . . . + | . . . . . . + | . . . . . . . + | . . . . . . . + | . . . . . . . + | . . . . . . + | . . . . . . + | . . . . . + | . . . . . + | . . . . . v <-------------------- time ---------------------> ``` @@ -176,29 +182,29 @@ series ``` $ tree ./data ./data -├── b-000001 -│ ├── chunks -│ │ ├── 000001 -│ │ ├── 000002 -│ │ └── 000003 -│ ├── index -│ └── meta.json -├── b-000004 -│ ├── chunks -│ │ └── 000001 -│ ├── index -│ └── meta.json -├── b-000005 -│ ├── chunks -│ │ └── 000001 -│ ├── index -│ └── meta.json -└── b-000006 - ├── meta.json - └── wal - ├── 000001 - ├── 000002 - └── 000003 ++-- b-000001 +| +-- chunks +| | +-- 000001 +| | +-- 000002 +| | +-- 000003 +| +-- index +| +-- meta.json ++-- b-000004 +| +-- chunks +| | +-- 000001 +| +-- index +| +-- meta.json ++-- b-000005 +| +-- chunks +| | +-- 000001 +| +-- index +| +-- meta.json ++-- b-000006 + +-- meta.json + +-- wal + +-- 000001 + +-- 000002 + +-- 000003 ``` 在最顶层，我们有一系列以 `b-` 为前缀编号的块block。每个块中显然保存了索引文件和含有更多编号文件的 `chunk` 文件夹。`chunks` 目录只包含不同序列数据点的原始块raw chunks of data points。与 V2 存储系统一样，这使得通过时间窗口读取序列数据非常高效并且允许我们使用相同的有效压缩算法。这一点被证实行之有效，我们也打算沿用。显然，这里并不存在含有单个序列的文件，而是一堆保存着许多序列的数据块。 @@ -214,15 +220,15 @@ $ tree ./data ``` t0 t1 t2 t3 now - ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ - │ │ │ │ │ │ │ │ ┌────────────┐ - │ │ │ │ │ │ │ mutable │ <─── write ──── ┤ Prometheus │ - │ │ │ │ │ │ │ │ └────────────┘ - └───────────┘ └───────────┘ └───────────┘ └───────────┘ ^ - └──────────────┴───────┬──────┴──────────────┘ │ - │ query - │ │ - merge ─────────────────────────────────────────────────┘ + +-----------+ +-----------+ +-----------+ +-----------+ + | | | | | | | | +------------+ + | | | | | | | mutable | <--- write ---- ┤ Prometheus | + | | | | | | | | +------------+ + +-----------+ +-----------+ +-----------+ +-----------+ ^ + +--------------+-------+------+--------------+ | + | query + | | + merge -------------------------------------------------+ ``` 每一块的数据都是不可变的immutable。当然，当我们采集新数据时，我们必须能向最近的块中添加新的序列和样本。对于该数据块，所有新的数据都将写入内存中的数据库中，它与我们的持久化的数据块一样提供了查找属性。内存中的数据结构可以高效地更新。为了防止数据丢失，所有传入的数据同样被写入临时的预写日志write ahead log中，这就是 `wal` 文件夹中的一些列文件，我们可以在重新启动时通过它们重新填充内存数据库。 @@ -262,15 +268,15 @@ t0 t1 t2 t3 now ``` t0 t1 t2 t3 t4 now - ┌────────────┐ ┌──────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ - │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 mutable │ before - └────────────┘ └──────────┘ └───────────┘ └───────────┘ └───────────┘ - ┌─────────────────────────────────────────┐ ┌───────────┐ ┌───────────┐ - │ 1 compacted │ │ 4 │ │ 5 mutable │ after (option A) - └─────────────────────────────────────────┘ └───────────┘ └───────────┘ - ┌──────────────────────────┐ ┌──────────────────────────┐ ┌───────────┐ - │ 1 compacted │ │ 3 compacted │ │ 5 mutable │ after (option B) - └──────────────────────────┘ └──────────────────────────┘ └───────────┘ + +------------+ +----------+ +-----------+ +-----------+ +-----------+ + | 1 | | 2 | | 3 | | 4 | | 5 mutable | before + +------------+ +----------+ +-----------+ +-----------+ +-----------+ + +-----------------------------------------+ +-----------+ +-----------+ + | 1 compacted | | 4 | | 5 mutable | after (option A) + +-----------------------------------------+ +-----------+ +-----------+ + +--------------------------+ +--------------------------+ +-----------+ + | 1 compacted | | 3 compacted | | 5 mutable | after (option B) + +--------------------------+ +--------------------------+ +-----------+ ``` 在这个例子中我们有顺序块 `[1,2,3,4]`。块 1、2、3 可以压缩在一起，新的布局将会是 `[1,4]`。或者，将它们成对压缩为 `[1,3]`。所有的时间序列数据仍然存在，但现在整体上保存在更少的块中。这极大程度地缩减了查询时间的消耗，因为需要合并的部分查询结果变得更少了。 @@ -281,9 +287,9 @@ t0 t1 t2 t3 t4 now ``` | - ┌────────────┐ ┌────┼─────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ - │ 1 │ │ 2 | │ │ 3 │ │ 4 │ │ 5 │ . . . - └────────────┘ └────┼─────┘ └───────────┘ └───────────┘ └───────────┘ + +------------+ +----+-----+ +-----------+ +-----------+ +-----------+ + | 1 | | 2 | | | 3 | | 4 | | 5 | . . . + +------------+ +----+-----+ +-----------+ +-----------+ +-----------+ | | retention boundary @@ -352,7 +358,7 @@ __name__="requests_total" -> [ 9999, 1000, 1001, 2000000, 2000001, 2000002, 另一个艰巨的任务是当磁盘上的数据被更新或删除掉后修改其索引。通常，最简单的方法是重新计算并写入，但是要保证数据库在此期间可查询且具有一致性。V3 存储系统通过每块上具有的独立不可变索引来解决这一问题，该索引仅通过压缩时的重写来进行修改。只有可变块上的索引需要被更新，它完全保存在内存中。 -### 基准测试 +## 基准测试 我从存储的基准测试开始了初步的开发，它基于现实世界数据集中提取的大约 440 万个序列描述符，并生成合成数据点以输入到这些序列中。这个阶段的开发仅仅测试了单独的存储系统，对于快速找到性能瓶颈和高并发负载场景下的触发死锁至关重要。 @@ -436,7 +442,7 @@ __name__="requests_total" -> [ 9999, 1000, 1001, 2000000, 2000001, 2000002, > 注意：在撰写本文的同时，Prometheus 1.6 正在开发当中，它允许更可靠地配置最大内存使用量，并且可能会显著地减少整体的消耗，有利于稍微提高 CPU 使用率。我没有重复对此进行测试，因为整体结果变化不大，尤其是面对高序列分流的情况。 -### 总结 +## 总结 Prometheus 开始应对高基数序列与单独样本的吞吐量。这仍然是一项富有挑战性的任务，但是新的存储系统似乎向我们展示了未来的一些好东西。