迈向十亿时间序列之路:InfluxDB 高基数索引引擎已准备测试

导航至

我们一直以来的一个请求是支持大量的时间序列。也就是说,数据库存储的独特时间序列数量非常高。虽然我们目前有客户拥有数千万的时间序列,但我们希望扩展到数亿甚至数十亿。今天,我们发布了新时间序列索引引擎的第一个alpha版本,供测试使用。使用这个新引擎,用户应该能够拥有数百万个独特的时间序列(当这项工作完成后,我们的目标是10亿)。系列的数量不应该受服务器硬件内存的限制。此外,数据库中存在的系列数量对数据库启动时间的影响应该可以忽略不计。这项工作自去年8月开始,是自我们去年发布了时间序列合并树存储引擎以来,数据库在技术上取得的最重要的进步。请继续阅读,了解如何启用新的索引引擎以及这将使 InfluxDB 解决哪些类型的问题。

在我们深入细节之前,我们需要先简要介绍一些背景知识。实际上,InfluxDB 看起来像有两个数据库:一个是时间序列数据存储,另一个是测量、标签和字段元数据的倒排索引。我们在2015年和2016年构建的TSM引擎是解决这个问题的第一部分:为原始时间序列数据提供最大吞吐量、压缩和查询速度。到目前为止,倒排索引是一个内存中的数据结构,在数据库启动时根据TSM中的数据构建。这意味着对于每个测量、标签键/值对和字段名称,都有一个查找表映射这些元数据片段到底层时间序列。对于拥有大量临时系列的用户,他们会看到随着新时间序列的创建,内存使用量不断增加。此外,启动时间会随着所有数据必须加载到堆中而增加。

新的时间序列索引(TSI)将索引移动到磁盘上的文件,这些文件我们通过内存映射来访问。这意味着我们让操作系统来处理最近最少使用(LRU)的管理。就像我们用于原始时间序列数据的TSM引擎一样,我们有一个写前日志,内存中的结构在查询时与内存映射索引合并。后台程序持续运行,将索引压缩成更大的文件,以避免在查询时进行过多的索引合并。在底层,我们使用类似罗宾汉哈希这样的技术来进行快速的索引查找,并使用HyperLogLog++来保持基数估计的草图。后者将使我们能够在查询语言中添加诸如 SHOW CARDINALITY 查询 这样的功能。

TSI解决的问题和未解决的问题

当前TSI工作旨在解决的最大问题是短暂的时序数据。我们最常在那些希望通过将标识符放在标签中来跟踪每个进程或每个容器指标的场景中看到这个问题。例如,Kubernetes的Heapster项目就是这样做的。对于不再频繁进行写入或查询的系列,它们不会占用内存空间。

尚未解决的问题是限制由 SHOW 查询返回的数据范围。我们将在未来更新查询语言,以通过时间来限制这些结果。我们也没有解决所有这些系列都频繁进行读写的问题。对于这个问题,扩展集群是解决方案。我们还需要继续优化查询语言和引擎,以便与大量系列一起工作。短期内要解决的最大问题是,可能耗尽内存的数据库中所有系列的查询。我们需要在语言中添加防护措施和限制,并最终实现磁盘溢出查询处理。这项工作将在每个版本中持续进行。

启用新的时间序列索引

首先,您需要下载1.3的alpha版本。您可以在夜间构建中找到这些包

https://dl.influxdata.com/influxdb/artifacts/influxdb_1.3.0-alpha1_amd64.deb
https://dl.influxdata.com/influxdb/artifacts/influxdb-1.3.0-alpha1_linux_amd64.tar.gz

默认情况下,新的时间序列索引引擎是禁用的。要启用它,您需要编辑您的配置文件。在 data 部分添加一个新的设置

index-version = "tsi1"

然后重新启动数据库。如果您已经有数据,所有旧分片将继续使用内存索引。新分片将使用新的基于磁盘的时间序列索引。为了测试目的,最好从一个新的数据库开始。为了验证您正在使用基于磁盘的索引,进行一些写入操作并查看您的 data/<database>/<retention policy>/<shard id> 目录。您应该看到一个名为 index 的子目录。

结论

这项工作仍然处于早期阶段。我们还需要做更多工作来调整压缩过程,使其需要更少的内存,以及进行大量的测试和错误修复(查看 tsi 标签 以跟踪进度)。启用了此功能的使用者应仅在测试基础设施上使用。它不是为生产使用而设计的,在未来几个月内,我们可能会更新TSI文件的底层格式,这要求用户删除那些数据。然而,我们对这项工作将使数据库实现的新可能性感到非常兴奋。用户将能够跟踪短暂的时序数据,如进程或容器指标,或者大量传感器的数据。

我将在4月26日的PerconaLive活动(PerconaLive)和4月27日的DataEngConf活动(DataEngConf)上发表演讲,深入探讨TSM和TSI的细节。