通往十亿时间序列之路：InfluxDB 高基数索引已准备就绪，可供测试
作者：Paul Dix / 产品, 用例, 开发者
2017 年 4 月 4 日
导航至
长期以来，我们收到的关于 InfluxDB 的请求之一是支持大量时间序列。也就是说，数据库存储的唯一时间序列数量具有非常高的基数。虽然我们目前有客户拥有数千万个时间序列，但我们希望扩展到数亿甚至数十亿。今天，我们发布了首个 alpha 版本，用于测试我们新的时间序列索引引擎。借助这个新引擎，用户应该能够拥有数百万个唯一的时间序列（我们完成这项工作的目标是 10 亿个）。序列的数量应该不受服务器硬件上内存量的限制。此外，数据库中存在的序列数量对数据库启动时间的影响可以忽略不计。这项工作自去年 8 月以来一直在进行中，代表了自我们去年发布 时间序列合并树存储引擎 以来，数据库最重大的技术进步。请继续阅读，了解如何启用新的索引引擎以及这将为 InfluxDB 打开哪些类型的问题来解决。
在我们深入细节之前，我们需要介绍一些背景知识。InfluxDB 实际上看起来像两个数据库合二为一：一个时间序列数据存储和一个用于测量、标签和字段元数据的倒排索引。我们在 2015 年和 2016 年构建的 TSM 引擎是为了解决这个问题的第一个部分：为原始时间序列数据获得最大的吞吐量、压缩率和查询速度。到目前为止，倒排索引是一个内存中的数据结构，它是在数据库启动期间根据 TSM 中的数据构建的。这意味着对于每个测量、标签键/值对和字段名称，内存中都有一个查找表，将这些元数据位映射到基础时间序列。对于拥有大量临时序列的用户，他们会看到随着新时间序列的创建，他们的内存利用率不断上升。此外，启动时间也会增加，因为所有这些数据都必须在启动时加载到堆上。
新的时间序列索引或 TSI 将索引移动到我们内存映射的磁盘文件上。这意味着我们让操作系统处理成为 LRU。与原始时间序列数据的 TSM 引擎非常相似，我们有一个预写式日志，其中包含一个内存结构，该结构在查询时与内存映射索引合并。后台例程不断运行，以将索引压缩成越来越大的文件，以避免在查询时进行过多的索引合并。在底层，我们正在使用诸如 Robin Hood 哈希之类的技术来进行快速索引查找，并使用 HyperLogLog++ 来保持基数估计的草图。后者将使我们能够向查询语言添加诸如 SHOW CARDINALITY 查询 之类的东西。
TSI 解决和未解决的问题
当前 TSI 工作旨在解决的最大问题是临时时间序列。我们最常见的情况是，用例希望通过将每个进程指标或每个容器指标的标识符放在标签中来跟踪它们。例如，Kubernetes 的 Heapster 项目 就是这样做的。对于那些不再是写入或查询热点的序列，它们不会占用内存空间。
这个问题尚未解决的是限制 SHOW 查询返回的数据范围。我们将在未来更新查询语言，以按时间限制这些结果。我们也没有解决所有这些序列都成为读取和写入热点的问题。对于这个问题，横向扩展集群是解决方案。我们将不得不继续优化查询语言和引擎，以处理大量序列。近期要解决的最大问题是，命中数据库中所有序列的查询可能会耗尽内存使用量。我们需要在语言中添加保护措施和限制，并最终实现溢出到磁盘的查询处理。这项工作将在每个版本中持续进行。
启用新的时间序列索引
首先，您必须下载 1.3 的 alpha 版本。您可以在 nightly builds 中找到这些软件包
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 和 4 月 27 日的 DataEngConf 上发表演讲，深入探讨 TSM 和 TSI 的细节。
