我见过很少的地方给出时间序列基数的定义类似于：
假设您在 20 个地点有 1000 台 IoT 设备，它们正在运行一个 5 个固件版本，并报告来自 5 种传感器的输入 设备。这组的基数是 500,000 (1000 x 20 x 5 x 5)。 在某些情况下，这很快就会变得难以管理，甚至添加和 跟踪设备的新固件版本将增加设置 到 600,000 (1000 x 20 x 6 x 5)
或
我觉得这是非常夸张的定义。例如，如果您有一组 10 行，每行用于不同的设备，来自不同的位置、不同的固件、不同的传感器，它会将基数气球增加到 10x10x10x10 = 10,000。而且只有 10 行！
时间序列数据集基数能否超过数据集的总行数？
【问题讨论】：
标签： time-series timescaledb questdb
在时间序列中，通常将时间序列的基数估计为唯一标签/标签值和测量次数的所有可能组合。该估计有助于了解在数据库的生命周期内，有多少不同的时间序列可能存储在数据库中，即，不仅仅是在当前状态。请注意，估计假设标签之间的独立性，通常不成立。 This definition of series cardinaliry in InfluxDB 讨论了这方面，除了问题中的链接之外，这也是一个有趣的阅读。
最好提前了解时间序列的可能基数，因为某些时间序列数据库不能很好地处理高基数。例如，请参阅this article 处理 InfluxDB 中的高基数问题。
其他时间序列数据库，例如 TimescaleDB，在处理高基数方面没有任何问题，因为标签没有特殊处理。在创建索引时了解基数可能很有用，因为更高的基数使索引更有用，但占用更多空间。
【讨论】：
时间序列基数是实际存储在数据库中的唯一时间序列的数量。就是这样！
让我们从基础开始。时间序列包含一系列由timestamp 排序的(timestamp, value) 对。每个时间序列都有一个名称（名称由 InfluxDB 线路协议中的测量值 + 字段名称构成）。此外，时间序列可以有一组key=value 标签（它们在某些系统中被命名为标签，例如 Prometheus）。 InfluxDB 行协议中的每个字段共享同一行中定义的同一组标签。时间序列由其名称和一组标签唯一标识。例如，temperature{city="Paris",country="France"} 和 temperature{city="Marseille",country="France"} 是不同的时间序列，因为它们包含标签 city 的不同值。
考虑到以下限制，让我们计算具有temperature 名称的时间序列的最大可能基数：
那么最大可能的基数将是10000*250=2.5 millions。但这是不正确的计算，因为每个城市都完全属于一个国家。所以最大可能的基数受到城市数量的限制，例如10000。实际上，基数通常较低，因为它受到数据库中存储的实际城市的限制。
时间序列基数有两种类型：
某些时间序列数据库可能会消耗与时间序列总数成比例的内存（例如，InfluxDB）。其他人可能只消耗活动时间序列的内存（例如，VictoriaMetrics）。还有一些数据库，每个新时间序列消耗的额外内存为零（例如，TimescaleDB 或ClickHouse）。所有这些数据库都有各种权衡、性能特征和资源使用（cpu、磁盘、ram）。因此，建议先针对特定用例对它们进行评估，然后再为给定的工作负载选择最佳的。
【讨论】：