如何有效地存储和查询十亿行传感器数据

Question

情况： 我已经开始了一项新工作，并被分配了如何处理传感器数据表的任务。它有13亿行传感器数据。数据非常简单：基本上只是传感器ID，日期和该时间点的传感器值（双倍）。

目前，数据存储在MSSQL Server数据库的表中。

到今年年底，我预计行数将增加到2-3亿。

我正在寻找一种更好的方式来存储和查询这些数据（按日​​期），因为有很多大数据＆＃34;我们的产品，我没有管理这些大数据集的真实经验，我在这里要求任何指示。

它不是一家大公司，我们的资源不是无限制的;）

有关我们用例的更多详细信息：

• 数据以图形绘制，并显示随时间变化的传感器值。
• 我们正计划创建一个API，让我们的客户在他们感兴趣的任何时间段内获取传感器数据（...... 2年前的数据与上个月的数据一样重要）数据）。

到目前为止，我的研究使我考虑了以下解决方案：

1. 将数据保存在SQL Server中

   但是对表进行分区（它现在没有分区）。这将需要企业版的SQL Server，其成本很高。

2. 将数据移至Azure SQL Server。

   在那里我们可以获得更少的分配功能，但是一旦我们的DB增长到250GB以上，它就会花费更多（并且超过500gb）。

3. 使用多个数据库

   我们每个客户可以使用1个DB。几个较小的数据库将比一个巨大的数据库便宜，但我们有很多客户和计划更多，所以我不想考虑管理所有这些数据库。

4. Azure存储表

   这是我到目前为止最喜欢的选项。我们可以按公司/传感器/年/月对数据进行分区，使用行键日期并存储传感器值。

   我还没来得及测试查询性能，但从我读到的内容应该是好的。但是有一个主要的缺点，那就是每个HTTP请求返回1000个项目的限制。如果我们需要获取一周的所有传感器数据，我们需要进行大量的HTTP请求。我现在不确定这对我们的用例有多大问题。

5. Azure HDInsight（Azure中的Hadoop）

   如上所述，我没有大数据的经验，目前我还没有充分了解Hadoop是否适合我们的情况（在给定的时间跨度内通过API公开传感器数据）。我应该更深入地学习，还是花更多的时间去寻找另一种选择？

有没有人有类似案例的经验。什么对你有用？请记住，价格很重要，而且简单＆＃34;解决方案可能比非常复杂的解决方案更受欢迎，即使复杂的解决方案可以更好地执行几秒钟。

更新1： 要回答以下评论中的一些问题。

• 大约有12 000个传感器，可能每15秒报告一次。这相当于每天约7000万。实际上，并非所有这些传感器都有＆＃34;报告＆＃34;因为我们每天都没有获得那么多数据，但由于我们自然希望扩展更多客户和传感器，我真的需要一种可以每天扩展到数百万传感器值的解决方案。
• 分区是一个解决方案，并且使用了几个数据库和/或几个表，但我确实是这样，但是如果/当我用尽其他解决方案时，我认为这是一个后备。
• 我已经阅读了更多关于HBase，http://opentsdb.net/和谷歌https://cloud.google.com/bigtable/的信息，看起来Hadoop至少可以成为一个真正的替代品。

更新2： 今天我体验了天蓝色表存储和HDInsight（HDI）。我们在查询和灵活性方面并不需要太多，因此我认为Azure Table Storage看起来很有前途。由于我提到的每个请求1000项限制，抽出数据有点慢，但在我的测试中，我认为它对我们的用例来说足够快。

我也偶然发现了OpenTSDB，这是我首先尝试HDI的原因。在关于Azure（https://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-tutorial-get-started/）的教程之后，我能够快速存储一百万条记录并测试一些查询。查询比Azure表存储快得多。我甚至可以在一个http请求中删除300 000条记录（虽然耗时30秒）。

但它的成本远远超过Azure表存储，我认为我可以优化我的代码以提高Azure表存储的查询性能（更细粒度的分区键和并行运行请求）。所以现在我倾向于Azure Table Storage，因为它的简单性，价格和足够好的＆＃34;性能

我很快就会向外部顾问介绍我的发现，所以我很高兴能够了解他对事物的看法。

Answer 1

因此，到今年年底（刚刚开始）你将拥有3亿条记录。每条记录为4字节ID + 4字节日期时间+ 8字节双值，总计3 * 10 ^ 9 *（4 + 4 + 8）== 48Gb。

您可以在内存数据库（如Redis，CouchBase，Tarantool，Aerospike）中轻松存储和处理此48Gb。所有这些都是开源的，因此您不需要支付许可费。

内存消耗可能会有10-30％的额外开销，因此48Gb可以增长到64Gb或更多。您应该使用您的真实数据提供这些数据库，以便为您的案例选择最经济的数据。

对于整个工作负载，只有一台物理机应该足够，因为内存数据库每个节点每秒能够处理100K-1M查询/更新（实际数量取决于您的特定工作负载模式）。为了更好的可用性，我将设置两个服务器 - 主服务器和从服务器。

根据我的经验，64Gb的物理服务器的价格是2-3K美元。请注意，您甚至不需要SSD磁盘。旋转的应该没问题，因为所有读取都会占用RAM，所有写入只会附加到事务日志中。这就是内存数据库的工作方式。如果您有任何问题，我可以详细说明。

Answer 2

所以我以某种方式使用了您列出的所有技术。您需要执行哪些查询？因为依赖于此，您可以统治一些解决方案。如果您不需要查询很多不同的方式，Table Storage可以很好地为您服务。如果你遵循guidelines，它会很好地扩展，并且很便宜。但是，如果你不能只对你需要的数据进行点查询，那么它可能效果不好，或者是复杂的选择。如果你想要一个时间序列数据库，Opentsdb很棒。将限制您到时间序列类型查询。有a lot of time series dbs那里有许多应用程序构建在它之上，如Bosun和Grafana，列出我使用的两个应用程序。最后一个选项HDI，我将数据存储在镶木地板格式（或某些列式格式）中，在数据顶部创建一个hive表，并使用Spark SQL进行查询。真的你不需要使用Spark，你也可以使用Hive。但是你应该远离的是传统的Map Reduce，这种范式现在几乎已经死了，你不应该在其中编写新的代码。最重要的是，如果你不知道它，它周围有陡峭的学习曲线。我是所有技术，我们将它们用于不同的部分是系统，它实际上取决于应用程序的读写要求。如果我是你，我会考虑使用火花和镶木地板，但它可能不需要很多新的工具。

Answer 3

对于现代时间序列数据库（例如VictoriaMetrics）而言，每年

30亿个数据点的数量非常少。它可以在具有64个vCPU的计算机上以每秒1900万个样本的摄取速度在不到3分钟的时间内保留此数量的数据点。有关详细信息，请参见this article。

VictoriaMetrics的生产设置中，每个单个节点具有多达10万亿个数据点。还有scales to multiple nodes。