什么是时间序列数据基数？
What is timeseries data cardinality?
我看到很少有地方给出时间序列基数的定义，类似于：
Assume you have 1000 IoT devices in 20 locations, they're running one
of 5 firmware versions, and report input from 5 types of sensor per
device. The cardinality of this set is 500,000 (1000 x 20 x 5 x 5).
This can quickly get unmanageable in some cases, as even adding and
tracking a new firmware version for the devices would increase the set
to 600,000 (1000 x 20 x 6 x 5)
或
我觉得这个定义很夸张。例如，如果您有一组 10 行，每行用于不同的设备、不同的位置、不同的固件、不同的传感器，它会将基数膨胀到 10x10x10x10 = 10,000。而且只有 10 行！
时间序列数据集的基数能否超过数据集的总行数？
在时间序列中，通常将时间序列的基数估计为唯一 tag/label 值和测量次数的所有可能组合。该估计有助于了解在数据库的生命周期内有多少不同的时间序列可能存储在数据库中，即，不仅仅是在当前状态。请注意，估计假设标签之间的独立性，这通常是不成立的。 This definition of series cardinaliry in InfluxDB 讨论了这方面的内容，除了问题中的链接之外，这本书还很有趣。
最好提前了解时间序列的可能基数，因为某些时间序列数据库不能很好地处理高基数。例如，参见 this article 处理 InfluxDB 中的高基数问题。
其他时间序列数据库，例如 TimescaleDB，在处理高基数方面没有任何问题，因为没有对标签进行特殊处理。在创建索引时了解基数可能会有用，因为较高的基数使索引更有用，但占用更多 space.
时间序列基数是实际存储在数据库中的唯一时间序列的数量。就是这样！
让我们从基础开始。时间序列包含按 timestamp 排序的一系列 (timestamp, value) 对。每个时间序列都有一个名称（名称由 InfluxDB 行协议中的测量值 + 字段名称构成）。此外，时间序列可以有一组 key=value 标签（它们在某些系统中被命名为标签，例如 Prometheus）。 InfluxDB 行协议中的每个字段共享同一行中定义的同一组标签。时间序列由其名称加上一组标签唯一标识。例如，temperature{city="Paris",country="France"} 和 temperature{city="Marseille",country="France"} 是不同的时间序列，因为它们包含标签 city.
的不同值
让我们计算名称为 temperature 的时间序列的最大可能基数，条件如下：
- 世界上有10000个城市
- 世界上有250个国家
那么最大可能的基数将是 10000*250=2.5 millions。但这是不正确的计算，因为每个城市都属于一个国家。所以最大可能的基数受城市数量的限制，例如10000。实际上，基数通常较低，因为它受到数据库中存储的实际城市的限制。
时间序列基数有两种：
- 活动时间序列的数量，例如最近摄入样本的时间序列。
- 数据库中存储的时间序列总数。
一些时间序列数据库消耗的内存可能与时间序列的总数成比例（例如，InfluxDB). Others may consume memory only for active time series (for example, VictoriaMetrics). There are also databases, which consume zero additional memory for each new time series (for example, TimescaleDB or ClickHouse）。所有这些数据库都有各种权衡、性能特征和资源使用（cpu、磁盘、内存）。因此，建议在为给定工作负载选择最佳选择之前，针对特定用例评估它们。
我看到很少有地方给出时间序列基数的定义，类似于：
Assume you have 1000 IoT devices in 20 locations, they're running one of 5 firmware versions, and report input from 5 types of sensor per device. The cardinality of this set is 500,000 (1000 x 20 x 5 x 5). This can quickly get unmanageable in some cases, as even adding and tracking a new firmware version for the devices would increase the set to 600,000 (1000 x 20 x 6 x 5)
或
我觉得这个定义很夸张。例如，如果您有一组 10 行，每行用于不同的设备、不同的位置、不同的固件、不同的传感器，它会将基数膨胀到 10x10x10x10 = 10,000。而且只有 10 行！
时间序列数据集的基数能否超过数据集的总行数？
在时间序列中，通常将时间序列的基数估计为唯一 tag/label 值和测量次数的所有可能组合。该估计有助于了解在数据库的生命周期内有多少不同的时间序列可能存储在数据库中，即，不仅仅是在当前状态。请注意，估计假设标签之间的独立性，这通常是不成立的。 This definition of series cardinaliry in InfluxDB 讨论了这方面的内容，除了问题中的链接之外，这本书还很有趣。
最好提前了解时间序列的可能基数，因为某些时间序列数据库不能很好地处理高基数。例如，参见 this article 处理 InfluxDB 中的高基数问题。
其他时间序列数据库，例如 TimescaleDB，在处理高基数方面没有任何问题，因为没有对标签进行特殊处理。在创建索引时了解基数可能会有用，因为较高的基数使索引更有用，但占用更多 space.
时间序列基数是实际存储在数据库中的唯一时间序列的数量。就是这样！
让我们从基础开始。时间序列包含按 timestamp 排序的一系列 (timestamp, value) 对。每个时间序列都有一个名称（名称由 InfluxDB 行协议中的测量值 + 字段名称构成）。此外，时间序列可以有一组 key=value 标签（它们在某些系统中被命名为标签，例如 Prometheus）。 InfluxDB 行协议中的每个字段共享同一行中定义的同一组标签。时间序列由其名称加上一组标签唯一标识。例如，temperature{city="Paris",country="France"} 和 temperature{city="Marseille",country="France"} 是不同的时间序列，因为它们包含标签 city.
让我们计算名称为 temperature 的时间序列的最大可能基数，条件如下：
- 世界上有10000个城市
- 世界上有250个国家
那么最大可能的基数将是 10000*250=2.5 millions。但这是不正确的计算，因为每个城市都属于一个国家。所以最大可能的基数受城市数量的限制，例如10000。实际上，基数通常较低，因为它受到数据库中存储的实际城市的限制。
时间序列基数有两种：
- 活动时间序列的数量，例如最近摄入样本的时间序列。
- 数据库中存储的时间序列总数。
一些时间序列数据库消耗的内存可能与时间序列的总数成比例（例如，InfluxDB). Others may consume memory only for active time series (for example, VictoriaMetrics). There are also databases, which consume zero additional memory for each new time series (for example, TimescaleDB or ClickHouse）。所有这些数据库都有各种权衡、性能特征和资源使用（cpu、磁盘、内存）。因此，建议在为给定工作负载选择最佳选择之前，针对特定用例评估它们。