时间序列索引 (TSI) 概述

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

概述

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

背景信息

实际上，InfluxDB 看起来像两个数据库合二为一，一个时间序列数据存储和一个用于度量、标签和字段元数据的倒排索引。

时间结构合并树 (TSM)

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

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

时间序列索引 (TSI)

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

TSI 解决和待解决的问题

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

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