时间序列指数 (TSI) 概述

在这个主题中找到时间序列索引（TSI）的概述和背景信息。有关详细信息，包括如何启用和配置TSI，请参见 时间序列索引（TSI）详细信息。

概述

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

背景信息

InfluxDB 实际上看起来像是一个数据库中的两个数据库，一个是时间序列数据存储，另一个是用于测量、标签和字段元数据的反向索引。

时间结构合并树 (TSM)

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

有关详细信息，请参见 TSM-based data storage and in-memory indexing。

时间序列索引 (TSI)

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

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

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

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