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

Question

我想知道一个时间序列数据库是否会随着这个场景而崩溃：

我有数以万计的物联网，每5分钟发送4个不同的值。

我将查询每个IoT的值，并在一定时间内查询这些值。我的问题是：

tsdb方法是否可行并可扩展到，例如100万物联网，其指标如下：

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

？或者它们是不是“度量量”太大了？

留用政策为2年，可能在(TBA)个月后结业。但我认为这种考虑只会影响磁盘大小afaik。

现在我在用石墨

Answer 1

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

尽管如此，缩放石墨集群以满足您的需求并不容易，因为Whisper没有为此进行优化。有几个资源/故事，其他人分享了他们的沮丧，试图实现这一点，例如：这里和这里

还需要考虑其他限制，Whisper的配置方式是，它只能记录每个时间戳一个数据池，最后一个数据池接收到"wins“。这对您现在可能不是一个问题，但以后您可能会发现，您需要增加数据报告频率，以便更好地了解您的数据。

这就产生了一个问题，我怎么才能绕过它呢？通常情况下，StatsD就是答案--它是一个聚合器，它在一定的时间内获取您的单个指标，并生成一组类似直方图的度量，其中包含不同的数据统计导数(最小、最大值、X百分位数等等)。突然之间，您将面临管理石墨实例或集群、一个(或多个) StatsD服务的前景，而这甚至还没有到可视化数据的有趣部分: Grafana经常在这里使用，还需要您设置和维护。

相反，假设您将保持报告频率，但增加设备数量(正如您提到的)，您可能会发现您的石墨堆栈的另一个组件-碳中继-遇到一些瓶颈问题(如描述的这里)。

我在以前托管的Graphite MetricFire工作，在构建产品/服务时，我们考虑了很多这些考虑因素。我们通过数百个帐户每秒处理数百万个数据点。数据汇总并以四种分辨率存储:5秒、30秒、5分、1小时，每个分辨率分别可持续24小时、3天、6个月和2年。

我们的设置的一个关键组件是，我们的存储不是建立在典型的Whisper后端上，而是使用一个使用Riak的定制数据存储，允许我们做很多事情:在数据视图中，每个度量都可以轻松地扩展和聚合数据点。这篇关于数据视图的文章是由我们的一位工程师撰写的，它详细介绍了我们在构建存储层时所做的决定。