TSI 概述

【总览】

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

【背景资料】

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

时间结构合并树（TSM）

InfluxData于2015年构建并在2016年继续增强的时间结构化合并树（TSM）引擎旨在解决为原始时间序列数据获取最大吞吐量，压缩和查询速度的问题。直到TSI为止，反向索引都是一种内存中数据结构，该结构是在数据库启动期间基于TSM中的数据构建的。这意味着对于每个度量，标签键值对和字段名称，内存中都有一个查找表，用于将这些元数据位映射到基础时间序列。对于具有大量临时序列的用户，随着创建新的时间序列，内存使用率继续增加。而且，启动时间增加了，因为所有这些数据都必须在启动时加载到堆中。

TSI解决的问题，还有待解决的问题

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

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