我们正在考虑使用Riak TS或InfluxDB作为时间序列存储，用于我们可以拥有数亿个系列的用例。 每个系列将随着时间的推移进行少量写入，每小时或每日写入。每个系列的数据点数也将很少。查询的复杂性可能也很低。
在调查两者时，我们发现InfluxDB对它可以处理的系列数量有一些限制，因此可能不是一个有效的解决方案。
我无法找到有关Riak TS此限制的信息。 我想，因为它建立在Riak KV的核心之上，它没有这么严格的限制，但我想确定。
当考虑到每个系列的数据点数量将会很少时，InfluxDB仍然是一个有效的解决方案。 Riak TS是否受到同样的限制？
答案 0 :(得分：2)
Riak TS确实没有这些限制，因此您可以自由使用它。 RiakTS也很好地扩展。实际上它在群集中效果最好，所以你应该从3个盒子开始。您可以配置复制因子和许多设置。
你说你的查询复杂度很低，所以RiakTS内置的查询功能绰绰有余。
RiakTS允许您配置＆＃34; quanta＆＃34;的大小，这将使您的RiakTS实例更加面向读取或面向写入。但是，在您的情况下，如果您的流量较低且您没有太多复杂的查询，我不会担心这一点。
有人要记住，Riak TS并没有跟踪系列名称，因此您必须要有可以计算的系列名称（例如 _），或者有一个单独的DB来存储，列出和查找系列名称。如果这对您来说是一个问题，我可以为您提供有关如何使其发挥作用的更多信息/提示/示例。
如果你想留在开源方面，我不认为InfluxDB会很适合你。如果您支付企业版本的InfluxDB，它可能会起作用，正如deniszh所说，但是您将被迫进行群集扩展以便能够存储更多系列，而不是因为您的流量需要它。
InfluxDB的一些例子： Apple documentation
您可能希望对DalmatinerDb（https://www.reddit.com/r/Database/comments/2nw9k0/practical_limits_of_influxdb/）感兴趣，因为它基于与RiakTS相同的一些技术，但为您提供了存储和索引的系列名称;它也被认为更快。但是，似乎需要更复杂的设置才能启动并运行。它也很新。
答案 1 :(得分：1)
IMO在InfluxDB中有数亿个系列的情况下，您需要检查其Enterprise版本以进行群集。 RiakTS可以在OSS版本中进行集群（只有interDC复制需要Enterprise订阅）