时序数据库永远的难关 — 时间线膨胀(高基数 Cardinality)问题的解决方案

作者 | 徐建伟 （竹影）

前序

随着移动端发展走向饱和，现在整个 IT 行业都期待着“万物互联”的物联网时代。在物联网场景中，往往有许多各类不同的终端设备，布署在不同的位置，去采集各种数据，比如某一区域有 10万个 loT 设备，每个 loT 设备每 5 秒发送一次数据。那么每年会产生 6307亿 个数据点。而这些数据都是顺序产生的，并且 loT 设备产生数据的格式全部是一致的，并且没有删除和修改的需求。针对这样按时海量写入无更新场景，时序数据库应运而生。

​

时序数据库在假定没有数据插入和更新需求，数据结构稳定的前提下，极限追求快速写入，高压缩，快速检索数据。时序数据的 Label(tag）会建立索引，以提高查询性能，以便你可以快速找到与所有指定标签匹配的值。如果 Label(tag）值的数量过多时（高基数 Cardinality 问题），索引会出现各种各样的问题， 本文主要讨论 influxdb 在遇到写入的数据出现高基数 Cardinality 问题时，一些可行的解决方案。
​

高基数Cardinality问题（时间线膨胀）

​

时序数据库主要存储的是 metric 数据，每一条数据称为一个样本（sample），样本由以下三部分组成：

• 指标（时间线 time-series）：metric name 和描述当前样本特征的 labelsets;
• 时间戳（timestamp）：一个精确到毫秒的时间戳;
• 样本值（value）：表示当前样本的值。

<-------------- time-series="" --------=""><-timestamp -----=""> <-value->

node_cpu{cpu=“cpu0”,mode=“idle”} @1627339366586 70
node_cpu{cpu=“cpu0”,mode=“sys”} @1627339366586 5
node_cpu{cpu=“cpu0”,mode=“user”} @1627339366586 25

通常情况下， time-series 中的 lablelsets 是有限的，可枚举的，比如上面的例子 model 可选值为 idle，sys，user。

prometheus 官方文档中对于 Label 的建议：

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

时序数据库的设计时，也是假定在时间线低基数的前提下。但是随着 metric 的广泛使用，在很多场景下无法避免出现时间线膨胀。

比如，在云原生场景下 tag 出现 pod/container ID之类，也有些 tag 出现 userId，甚至有些 tag 是 url，而这些 tag 组合时，时间线膨胀得非常厉害。

这个矛盾出现是必然的，怎么解决呢？是写入数据方调整写入数据时，控制写入的 time-series的数量，还是时序数据库去更改设计来适用这种场景？这个问题没有完美的解决方案，我们需要做出平衡。

从实际情况出发，如果时间线膨胀后，时序数据库不会出现不可用，性能也不会出现指数级别下降。也就是说时间线不膨胀时，性能优秀。时间线膨胀后，性能能达到良好或者及格就好。

那怎么让时序数据库在时间线膨胀的情况下性能还能良好呢？接下来我们通过