database - 时间序列数据库“指标限制”？

Question

我想知道时间序列数据库是否会在这种情况下崩溃：

我有成千上万的物联网每 5 分钟发送 4 个不同的值。

我将在特定时间跨度内查询每个物联网的这些值。我的问题是：

tsdb 方法是否可行且可扩展至例如一百万个物联网，其指标如下：

iot.key1.value1
iot.key1.value2
iot.key1.value3
iot.key1.value4
iot.key2.value1
.
.
.
iot.key1000000.value4

? 还是他们的“指标数量”太多了？

保留政策为 2 年，可能会在 (TBA) 个月后汇总。但我认为这个考虑只对磁盘大小 afaik 很重要。

现在我正在使用石墨

标签： databasetime-seriesgraphitegraphite-carbon

Answer 1

五分钟的报告频率应该是相当易于管理的，只需确保将您的存储模式设置为五分钟作为最小分辨率数据以节省空间，因为您不需要在更短的时间内保留数据.

话虽如此，扩展石墨集群以满足您的需求并不容易，因为 Whisper 并未为此进行优化。有几个资源/故事，其他人分享了他们试图实现这一目标的沮丧，例如：here和here

还有其他限制需要考虑，Whisper 的配置方式是每个时间戳只能记录一个数据点，并且最后一个接收到的数据点“获胜”。现在这对您来说可能不是问题，但稍后您可能会发现您需要增加数据点报告频率才能更好地了解您的数据。

随之而来的问题是，我该如何解决这个问题？通常，StatsD就是答案 - 它是一个聚合器，可以在定义的时间段内获取您的各个指标，并生成一组类似直方图的指标，其中包含您数据的不同统计衍生品（最小值、最大值、X 百分位数等）在）。突然之间，您面临管理 Graphite 实例或集群、一个（或多个）StatsD服务的前景，而这还没有达到可视化数据的有趣部分：这里经常使用 Grafana，还需要您设置和维护。

相反，假设您将保持该报告频率，但增加设备数量（如您所述），您可能会发现 Graphite 堆栈的另一个组件 - Carbon-relay - 遇到一些瓶颈问题（如此处所述）。

我在MetricFire工作，以前是Hosted Graphite，我们在构建产品/服务时考虑了很多这些因素。我们共同处理数百个帐户每秒数百万个数据点。数据以四种分辨率汇总和存储：5 秒、30 秒、5 分钟、1 小时，其中每种分辨率分别可用于 24 小时、3 天、6 个月和 2 年。

我们设置的一个关键组成部分是我们的存储不是建立在典型的 Whisper 后端上 - 相反，我们使用使用 Riak 的定制数据存储允许我们做很多事情：轻松扩展并将每个指标的数据点聚合到数据视图中，仅举几例。那篇关于数据视图的文章是由我们的一位工程师撰写的，详细介绍了我们在构建存储层时所做的决策。