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

将数百万个小文件归并为少数几个大文件使得我们用很小的开销就能保持全部的文件都打开。这就扫除了对 mmap(2) 的行使的阻碍，这是一个应承我们通过文件透明地回传假造内存的体系挪用。简朴起见，你可以将其视为互换空间swap space，只是我们全部的数据已经生涯在了磁盘上，而且当数据换出内存后不再见产生写入。

这意味着我们可以看成全部数据库的内容都视为在内存中却不占用任何物理内存。仅当我们会见数据库文件某些字节范畴时，操纵体系才会从磁盘上惰性加载lazy load页数据。这使得我们将全部数据耐久化相干的内存打点都交给了操纵体系。凡是，操纵体系更有资格作出这样的抉择，由于它可以全面相识整个呆板和历程。查询的数据可以相等起劲的缓存进内存，但内存压力会使得页被换出。假如呆板拥有未行使的内存，Prometheus 今朝将会兴奋地缓存整个数据库，可是一旦其他历程必要，它就会立即返回那些内存。

因此，查询不再等闲地使我们的历程 OOM，由于查询的是更多的耐久化的数据而不是装入内存中的数据。内存缓存巨细变得完全自顺应，而且仅当查询真正必要时数据才会被加载。

就小我私人领略，这就是当今大大都数据库的事变方法，假如磁盘名目应承，这是一种抱负的方法，——除非有人自信能在这个进程中逾越操纵体系。我们做了很少的事变但确实从表面得到了许多成果。

压缩

存储体系必要按期“切”出新块并将之前完成的块写入到磁盘中。仅在块乐成的耐久化之后，才会被删除之前用来规复内存块的日记文件（wal）。

我们但愿将每个块的生涯时刻配置的相对短一些（凡是设置为 2 小时），以停止内存中蕴蓄太多的数据。当查询多个块，我们必需将它们的功效归并为一个整体的功效。归并进程显然会耗损资源，一个礼拜的查询不该该由高出 80 个的部门功效所构成。

为了实现两者，我们引入压缩compaction。压缩描写了一个进程：取一个或更多个数据块并将其写入一个也许更大的块中。它也可以在此进程中修改现有的数据。譬喻，破除已经删除的数据，或重建样本块以晋升查询机能。

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]。块 1、2、3 可以压缩在一路，新的机关将会是 [1,4]。可能，将它们成对压缩为 [1,3]。全部的时刻序列数据如故存在，但此刻整体上生涯在更少的块中。这极洪流平地缩减了查询时刻的耗损，由于必要归并的部门查询功效变得更少了。

保存

我们看到了删除旧的数据在 V2 存储体系中是一个迟钝的进程，而且耗损 CPU、内存和磁盘。怎样才气在我们基于块的计划上破除旧的数据？相等简朴，只要删除我们设置的保存时刻窗口里没稀有据的块文件夹即可。在下面的例子中，块 1 可以被安详地删除，而块 2 则必需一向保存，直到它落在保存窗口界线之外。

                      |
 +------------+  +----+-----+  +-----------+  +-----------+  +-----------+
 | 1          |  | 2  |     |  | 3         |  | 4         |  | 5         |   . . .
 +------------+  +----+-----+  +-----------+  +-----------+  +-----------+
                      |
                      |
             retention boundary

跟着我们不绝压缩先前压缩的块，旧数据越大，块也许变得越大。因此必需为其配置一个上限，以防数据块扩展到整个数据库而丧失我们计划的最初上风。

利便的是，这一点也限定了部门存在于保存窗口内部门存在于保存窗口外的块的磁盘耗损总量。譬喻上面例子中的块 2。当配置了最大块尺寸为总保存窗口的 10% 后，我们保存块 2 的总开销也有了 10% 的上限。

总结一下，保存与删除从很是昂贵到了险些没有本钱。

假如你读到这里并有一些数据库的配景常识，此刻你大概会问：这些都是最新的技能吗？——并不是；并且也许还会做的更好。

在内存中批量处理赏罚数据，在预写日记中跟踪，并按期写入到磁盘的模式在此刻相等广泛。

我们看到的甜头无论在什么规模的数据里都是合用的。遵循这一要领最闻名的开源案例是 LevelDB、Cassandra、InfluxDB 和 HBase。要害是停止一再发现劣质的轮子，回收颠末验证的要领，并正确地运用它们。

离开场景添加你本身的黑邪术是一种不太也许的环境。

索引

（编辑：湖南网）

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