时间序列索引 (TSI) 概述

在本主题中查找关于时间序列索引 (TSI) 的概述和背景信息。 有关详细信息，包括如何启用和配置 TSI，请参阅时间序列索引 (TSI) 详情。

概述

为了支持大量时间序列，即数据库存储的唯一时间序列数量非常多的高基数，InfluxData 添加了新的时间序列索引 (TSI)。 InfluxData 支持客户使用 InfluxDB 处理数千万个时间序列。 然而，InfluxData 的目标是扩展到数亿，最终达到数十亿。 使用 InfluxData 的 TSI 存储引擎，用户应该能够拥有数百万个唯一的时间序列。 目标是序列的数量不应受服务器硬件内存量的限制。 重要的是，数据库中存在的序列数量对数据库启动时间的影响可以忽略不计。 这项工作代表了自 2016 年 InfluxData 发布时间序列合并树 (TSM) 存储引擎以来，数据库领域最重大的技术进步。

背景信息

InfluxDB 实际上看起来像两个数据库合二为一，一个时间序列数据存储和一个用于 measurement、tag 和 field 元数据的倒排索引。

时间结构合并树 (TSM)

时间结构合并树 (TSM) 引擎解决了为原始时间序列数据获得最大吞吐量、压缩率和查询速度的问题。 在 TSI 之前，倒排索引是一个内存数据结构，它是在数据库启动期间基于 TSM 中的数据构建的。 这意味着对于每个 measurement、tag 键值对和 field 名称，内存中都有一个查找表，将这些元数据位映射到底层时间序列。 对于具有大量临时序列的用户，随着新时间序列的创建，内存利用率持续增加。 而且，由于所有这些数据都必须在启动时加载到堆中，因此启动时间会增加。

有关详细信息，请参阅基于 TSM 的数据存储和内存索引。

时间序列索引 (TSI)

新的时间序列索引 (TSI) 将索引移动到我们内存映射的磁盘文件上。 这意味着我们让操作系统处理最近最少使用 (LRU) 内存。 就像用于原始时间序列数据的 TSM 引擎一样，我们有一个预写日志，其中包含一个内存结构，该结构在查询时与内存映射索引合并。 后台例程不断运行，将索引压缩成越来越大的文件，以避免在查询时进行过多的索引合并。 在底层，我们正在使用诸如 Robin Hood Hashing 之类的技术来执行快速索引查找，并使用 HyperLogLog++ 来保留基数估计的草图。 后者将使我们能够向查询语言添加诸如 SHOW CARDINALITY 查询之类的功能。

TSI 解决和待解决的问题

时间序列索引 (TSI) 解决的主要问题是临时时间序列。 这种情况最常发生在希望通过在标签中放置标识符来跟踪每个进程指标或每个容器指标的用例中。 例如，Kubernetes 的 Heapster 项目就是这样做的。 对于不再频繁写入或查询的序列，它们不会占用内存空间。

Heapster 项目和类似的用例未解决的问题是限制 SHOW 查询返回的数据范围。 未来我们将更新查询语言，以按时间限制这些结果。 我们也没有解决所有这些序列都频繁读取和写入的问题。 对于这个问题，横向扩展集群是解决方案。 我们将不得不继续优化查询语言和引擎，以处理大量序列。 我们需要在语言中添加防护栏和限制，并最终添加溢出到磁盘的查询处理。 这项工作将在 InfluxDB 的每个版本中持续进行。