从零写一个时间序列数据库

在 Prometheus 的上下文context中，我们行使术语序列分流series churn来描写一个时刻序列荟萃变得不活泼，即不再吸取数据点，取而代之的是呈现一组新的活泼序列。

譬喻，由给定微处究竟例发生的全部序列都有一个响应的“instance”标签来标识其来历。假如我们为微处事执行了转动更新rolling update，而且为每个实例替代一个新的版本，序列分流便会产生。在越发动态的情形中，这些工作根基上每小时城市产生。像 Kubernetes 这样的集群编排Cluster orchestration体系应承应用持续性的自动伸缩和频仍的转动更新，这样大概会建设成千上万个新的应用措施实例，而且陪伴着全新的时刻序列荟萃，天天都是云云。

series
  ^
  |   . . . . . .
  |   . . . . . .
  |   . . . . . .
  |               . . . . . . .
  |               . . . . . . .
  |               . . . . . . .
  |                             . . . . . .
  |                             . . . . . .
  |                                         . . . . .
  |                                         . . . . .
  |                                         . . . . .
  v
    <-------------------- time --------------------->

以是即便整个基本办法的局限根基保持稳固，过一段时刻后数据库内的时刻序列照旧会成线性增添。尽量 Prometheus 很乐意收罗 1000 万个时刻序列数据，但要想在 10 亿个序列中找到数据，查询结果照旧会受到严峻的影响。

当前办理方案

当前 Prometheus 的 V2 存储体系对全部当前世存的序列拥有基于 LevelDB 的索引。它应承查询语句含有给定的标签对label pair，可是缺乏可伸缩的要领来从差异的标签选齐集组合查询功效。

譬喻，从全部的序列中选择标签 __name__="requests_total" 很是高效，可是选择  instance="A" AND __name__="requests_total" 就有了可伸缩性的题目。我们稍后会从头思量导致这一点的缘故起因和可以或许晋升查找耽误的调解要领。

究竟上正是这个题目才催生出了对更好的存储体系的最初试探。Prometheus 必要为查找亿万个时刻序列改造索引要领。

资源耗损

当试图扩展 Prometheus（或其他任何工作，真的）时，资源耗损是永恒稳固的话题之一。但真正困扰用户的并不是对资源的绝对渴求。究竟上，因为给定的需求，Prometheus 打点着令人难以置信的吞吐量。题目更在于面临变革时的相对未知性与不不变性。通过其架构计划，V2 存储体系迟钝地构建了样本数据块，这一点导致内存占用随时刻递增。当数据块完成之后，它们可以写到磁盘上并从内存中破除。最终，Prometheus 的内存行使达到不变状态。直到监测情形产生了改变——每次我们扩展应用可能举办转动更新，序列分流城市增进内存、CPU、磁盘 I/O 的行使。

假如改观正在举办，那么它最终照旧会达到一个不变的状态，但比起越发静态的情形，它的资源耗损会明显地进步。过渡时刻凡是为数个小时，并且难以确定最大资源行使量。

为每个时刻序列生涯一个文件这种要领也使得一个单个查询就很轻易瓦解 Prometheus 历程。当查询的数据没有缓存在内存中，查询的序列文件就会被打开，然后将含有相干数据点的数据块读入内存。假如数据量超出内存可用量，Prometheus 就会因 OOM 被杀死而退出。

在查询语句完成之后，加载的数据便可以被再次开释掉，但凡是会缓存更长的时刻，以便更快地查询沟通的数据。后者看起来是件不错的工作。

最后，我们看看之条件到的 SSD 的写入放大，以及 Prometheus 是怎样通过批量写入来办理这个题目的。尽量云云，在很多处所照旧存在由于批量太小以及数据未准确对齐页界线而导致的写入放大。对付更大局限的 Prometheus 处事器，实际傍边会发明缩减硬件寿命的题目。这一点对付高写入吞吐量的数据库应用来说如故相等广泛，但我们应该放眼看看是否可以办理它。

从头开始

到今朝为止我们对付题目域、V2 存储体系是怎样办理它的，以及计划上存在的题目有了一个清楚的熟悉。我们也看到了很多很棒的设法，这些或多或少都可以拿来直接行使。V2 存储体系相等数目的题目都可以通过改造和部门的从头计划来办理，但为了好玩（虽然，在我细心的验证设法之后），我抉择试着写一个完备的时刻序列数据库——从新开始，即向文件体系写入字节。

机能与资源行使这种最要害的部门直接影响了存储名目标选取。我们必要为数据找到正确的算法和磁盘机关来实现一个高机能的存储层。

这就是我办理题目的捷径——跳过令人头疼、失败的设法，数不尽的草图，泪水与绝望。

V3—宏观计划

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!