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

研究存储改进的最初想法是解决序列分流的问题。基于块的布局减少了查询所要考虑的序列总数。因此假设我们索引查找的复杂度是 O(n^2)，我们就要设法减少 n 个相当数量的复杂度，之后就相当于改进 O(n^2) 复杂度。——恩，等等……糟糕。

快速回顾一下“算法 101”课上提醒我们的，在理论上它并未带来任何好处。如果之前就很糟糕，那么现在也一样。理论是如此的残酷。

实际上，我们大多数的查询已经可以相当快响应。但是，跨越整个时间范围的查询仍然很慢，尽管只需要找到少部分数据。追溯到所有这些工作之前，最初我用来解决这个问题的想法是：我们需要一个更大容量的倒排索引。

倒排索引基于数据项内容的子集提供了一种快速的查找方式。简单地说，我可以通过标签 app="nginx" 查找所有的序列而无需遍历每个文件来看它是否包含该标签。

为此，每个序列被赋上一个唯一的 ID ，通过该 ID 可以恒定时间内检索它（O(1)）。在这个例子中 ID 就是我们的正向索引。

示例：如果 ID 为 10、29、9 的序列包含标签 app="nginx"，那么 “nginx”的倒排索引就是简单的列表 [10, 29, 9]，它就能用来快速地获取所有包含标签的序列。即使有 200 多亿个数据序列也不会影响查找速度。

简而言之，如果 n 是我们序列总数，m 是给定查询结果的大小，使用索引的查询复杂度现在就是 O(m)。查询语句依据它获取数据的数量 m 而不是被搜索的数据体 n 进行缩放是一个很好的特性，因为 m 一般相当小。

为了简单起见，我们假设可以在恒定时间内查找到倒排索引对应的列表。

实际上，这几乎就是 V2 存储系统具有的倒排索引，也是提供在数百万序列中查询性能的最低需求。敏锐的人会注意到，在最坏情况下，所有的序列都含有标签，因此 m 又成了 O(n)。这一点在预料之中，也相当合理。如果你查询所有的数据，它自然就会花费更多时间。一旦我们牵扯上了更复杂的查询语句就会有问题出现。

标签组合

与数百万个序列相关的标签很常见。假设横向扩展着数百个实例的“foo”微服务，并且每个实例拥有数千个序列。每个序列都会带有标签 app="foo"。当然，用户通常不会查询所有的序列而是会通过进一步的标签来限制查询。例如，我想知道服务实例接收到了多少请求，那么查询语句便是 __name__="requests_total" AND app="foo"。

为了找到满足两个标签选择子的所有序列，我们得到每一个标签的倒排索引列表并取其交集。结果集通常会比任何一个输入列表小一个数量级。因为每个输入列表最坏情况下的大小为 O(n)，所以在嵌套地为每个列表进行暴力求解brute force solution下，运行时间为 O(n^2)。相同的成本也适用于其他的集合操作，例如取并集（app="foo" OR app="bar"）。当在查询语句上添加更多标签选择子，耗费就会指数增长到 O(n^3)、O(n^4)、O(n^5)……O(n^k)。通过改变执行顺序，可以使用很多技巧以优化运行效率。越复杂，越是需要关于数据特征和标签之间相关性的知识。这引入了大量的复杂度，但是并没有减少算法的最坏运行时间。

这便是 V2 存储系统使用的基本方法，幸运的是，看似微小的改动就能获得显著的提升。如果我们假设倒排索引中的 ID 都是排序好的会怎么样？

假设这个例子的列表用于我们最初的查询：

__name__="requests_total"   ->   [ 9999, 1000, 1001, 2000000, 2000001, 2000002, 2000003 ]
     app="foo"              ->   [ 1, 3, 10, 11, 12, 100, 311, 320, 1000, 1001, 10002 ]
 
             intersection   =>   [ 1000, 1001 ]

它的交集相当小。我们可以为每个列表的起始位置设置游标，每次从最小的游标处移动来找到交集。当二者的数字相等，我们就添加它到结果中并移动二者的游标。总体上，我们以锯齿形扫描两个列表，因此总耗费是 O(2n)=O(n)，因为我们总是在一个列表上移动。

两个以上列表的不同集合操作也类似。因此 k 个集合操作仅仅改变了因子 O(k*n) 而不是最坏情况下查找运行时间的指数 O(n^k)。

我在这里所描述的是几乎所有全文搜索引擎使用的标准搜索索引的简化版本。每个序列描述符都视作一个简短的“文档”，每个标签（名称 + 固定值）作为其中的“单词”。我们可以忽略搜索引擎索引中通常遇到的很多附加数据，例如单词位置和和频率。

关于改进实际运行时间的方法似乎存在无穷无尽的研究，它们通常都是对输入数据做一些假设。不出意料的是，还有大量技术来压缩倒排索引，其中各有利弊。因为我们的“文档”比较小，而且“单词”在所有的序列里大量重复，压缩变得几乎无关紧要。例如，一个真实的数据集约有 440 万个序列与大约 12 个标签，每个标签拥有少于 5000 个单独的标签。对于最初的存储版本，我们坚持使用基本的方法而不压缩，仅做微小的调整来跳过大范围非交叉的 ID。

尽管维持排序好的 ID 听起来很简单，但实践过程中不是总能完成的。例如，V2 存储系统为新的序列赋上一个哈希值来当作 ID，我们就不能轻易地排序倒排索引。

（编辑：威海站长网）

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