加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

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

发布时间:2019-06-19 07:24:07 所属栏目:编程 来源:Fabian Reinartz
导读:编者按:Prometheus 是 CNCF 旗下的开源监控诉警办理方案,它已经成为 Kubernetes 生态圈中的焦点监控体系。本文作者Fabian Reinartz 是Prometheus 的焦点开拓者,这篇文章是其于 2017 年写的一篇关于Prometheus 中的时刻序列数据库的计划思索,固然写作时

对付旋转式磁盘,它的磁头始终得在物理上向差异的扇区上移动,这是一个不敷为奇的究竟。而固然我们都知道 SSD 具有快速随机写入的特点,但究竟上它不能修改单个字节,只能写入一页或更多页的 4KiB 数据量。这就意味着写入 16 字节的样内情当于写入满满一个 4Kib 的页。这一举动就是所谓的写入放大,这种特征会消费你的 SSD。因此它不只影响速率,并且还绝不浮夸地在几天或几个周内粉碎掉你的硬件。

关于此题目更深条理的资料,“Coding for SSDs”系列博客是极好的资源。让我们想想首要的用处:次序写入和批量写入别离对付旋转式磁盘和 SSD 来说都是抱负的写入模式。大道至简。

查询模式比起写入模式明明更差异。我们可以查询单一序列的一个数据点,也可以对 10000 个序列查询一个数据点,还可以查询一个序列几个周的数据点,乃至是 10000 个序列几个周的数据点。因此在我们的二维平面上,查询范畴不是完全程度或垂直的,而是二者形成矩形似的组合。

记录法则可以减轻已知查询的题目,但对付点对点ad-hoc查询来说并不是一个通用的办理要领。

我们知道我们想要批量地写入,但我们获得的仅仅是一系列垂直数据点的荟萃。当查询一段时刻窗口内的数据点时,我们不只很难弄清晰在哪才气找到这些单独的点,并且不得不从磁盘上大量随机的处所读取。大概一条查询语句会稀有百万的样本,纵然在最快的 SSD 上也会很慢。读入也会从磁盘上获取更多的数据而不只仅是 16 字节的样本。SSD 会加载一整页,HDD 至少会读取整个扇区。岂论哪一种,我们都在挥霍名贵的读取吞吐量。

因此在抱负环境下,统一序列的样本将按次序存储,这样我们就能通过尽也许少的读取来扫描它们。最重要的是,我们仅必要知道序列的起始位置就能会见全部的数据点。

显然,将网络到的数据写入磁盘的抱负模式与可以或许明显进步查询服从的机关之间存在着明明的抵触。这是我们 TSDB 必要办理的一个根基题目。

当前的办理要领

是时辰看一下当前 Prometheus 是怎样存储数据来办理这一题目的,让我们称它为“V2”。

我们建设一个时刻序列的文件,它包括全部样本并按次序存储。由于每几秒附加一个样本数据到全部文件中很是昂贵,我们在内存中打包 1Kib 样本序列的数据块,一旦打包完成绩附加这些数据块到单独的文件中。这一要领办理了大部门题目。写入今朝是批量的,样本也是按次序存储的。基于给定的统一序列的样内情对之前的数据仅产生很是小的改变这一特征,它还支持很是高效的压缩名目。Facebook 在他们 Gorilla TSDB 上的论文中描写了一个相似的基于数据块的要领,而且引入了一种压缩名目,它可以或许镌汰 16 字节的样本到均匀 1.37 字节。V2 存储行使了包括 Gorilla 变体等在内的各类压缩名目。

  1. +----------+---------+---------+---------+---------+ series A
  2. +----------+---------+---------+---------+---------+
  3. +----------+---------+---------+---------+---------+ series B
  4. +----------+---------+---------+---------+---------+
  5. . . .
  6. +----------+---------+---------+---------+---------+---------+ series XYZ
  7. +----------+---------+---------+---------+---------+---------+
  8. chunk 1 chunk 2 chunk 3 ...

尽量基于块存储的要领很是棒,但为每个序列生涯一个独立的文件会给 V2 存储带来贫困,由于:

  • 现实上,我们必要的文件比当前网络数据的时刻序列数目要多得多。多出的部门在序列分流Series Churn上。有几百万个文件,早晚会行使光文件体系中的 inode。这种环境我们只能通过从头名目化来规复磁盘,这种方法是最具有粉碎性的。我们凡是不想为了顺应一个应用措施而名目化磁盘。
  • 纵然是分块写入,每秒也会发生数千块的数据块而且筹备耐久化。这依然必要每秒数千次的磁盘写入。尽量通过为每个序列打包许多几何个块来缓解,但这反过来照旧增进了守候耐久化数据的总内存占用。
  • 要保持全部文件打开来举办读写是不行行的。出格是由于 99% 的数据在 24 小时之后不再见被查询到。假如查询它,我们就得打开数千个文件,找到并读取相干的数据点到内存中,然后再关掉。这样做就会引起很高的查询耽误,数据块缓存加剧会导致新的题目,这一点在“资源耗损”一节另作报告。
  • 最终,旧的数据必要被删除,而且数据必要从数百万文件的头部删除。这就意味着删除现实上是写麋集型操纵。另外,轮回遍历数百万文件而且举办说明凡是会导致这一进程耗费数小时。当它完成时,也许又得从头来过。喔天,继承删除旧文件又会进一步导致 SSD 发生写入放大。
  • 今朝所蕴蓄的数据块仅维持在内存中。假如应用瓦解,数据就会丢失。为了停止这种环境,内存状态会按期的生涯在磁盘上,这比我们能接管数据丢失窗口要长的多。规复搜查点也会耗费数分钟,导致很长的重启周期。

我们可以或许从现有的计划中学到的要害部门是数据块的观念,我们虽然但愿保存这个观念。最新的数据块会保持在内存中一样平常也是好的主意。事实,最新的数据会大量的查询到。

一个时刻序列对应一个文件,这个观念是我们想要替代掉的。

序列分流

(编辑:湖南网)

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

热点阅读