为什么对于高基数的数据，Prometheus不是一个好的选择？

#1 楼

据我所知，普罗米修斯并不介意高基数数据。 Prometheus不喜欢的是高基数标签。

让我们从Prometheus官方文档开始，它给出了一个很好的高级解释，原因：


注意：请记住，键值标签对的每个唯一组合都代表一个新的时间序列，这可以显着增加
存储的数据量。请勿使用标签存储具有高基数（许多不同的标签值）的尺寸，例如用户ID，
电子邮件地址或其他无限制的值集。



https://prometheus.io/docs/practices/naming/

重要的部分实际上是键值的独特组合在Prometheus中创建了新的时间序列。 >
例如，如果您存储一个量表类型的度量标准registration_complete来记录用户完成其注册表格所花费的时间，则Prometheus对此不会有任何问题。您将拥有一个包含数十万个值的时间序列：每个注册用户的价值（花费了多长时间）。您将能够随时间绘制该指标的图形，并获取p95等。

如果要向其添加基数，可以添加一个标签，例如region：美国东部，亚洲-太平洋等。您将能够绘制所有区域的图并进行比较，或者将它们全部分组。区域的数量可能很少（<10），并且肯定会受到限制。如果在AWS上，则存在固定数量的区域，并且它们随时间变化不大。当然，AWS可能会添加，删除或重命名一个区域，但该区域并不会一时改变，而且也没有成千上万个区域。

因此，请返回普罗米修斯的建议：您不应创建高级别的区域，基数标签。您不应在user_id指标中添加registration_complete标签。如果这样做，您将有成千上万个不同的时间序列，每个用户一个！，它们都将只有一个数据点。那真的是最坏的情况。

在这种情况下，为了在所有标签上绘制registration_complete指标，Prometheus将必须查询所有单个时间序列（成千上万个X序列）并将它们汇总。

您说您来自SQL背景，因此我将尝试类推。键值标签对的独特组合在Prometheus中创建新的时间序列，相当于SQL中的各个表。带有标签user_id等于每个user_id有一个表。

注意：并非所有TSDB都以相同的方式工作，我不能全部代表它们。