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

Question

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

目前,数据存储在MSSQL Server数据库的表中.

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

我正在寻找一种更好的方式来存储和查询这些数据(按日​​期),因为我们有很多"大数据"产品,而且我没有管理这些大数据集的真实经验,我在这里问对于任何指针.

它不是一家大公司,我们的资源不是无限的;)

关于我们的用例的更多细节:

• 数据以图形绘制,并显示传感器值随时间的变化.
• 我们计划创建一个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公开传感器数据).我应该更深入地学习,还是我的时间更好地花在追求另一种选择上？

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

更新1: 回答以下评论中的一些问题.

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

更新2: 今天我体验了azure表存储和HDInsight(HDI).我们在查询"灵活性"方面并不需要太多,因此我认为Azure表存储看起来很有前景.由于我提到的每个请求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.

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

Answer 1

所以我以某种方式使用了你列出的所有技术。您需要执行什么类型的查询？因为根据这一点，您可以决定一些解决方案。如果您不需要以多种不同的方式进行查询，那么表存储可能会很适合您。如果您遵循指导原则，它的扩展性会非常好，而且价格便宜。但是，如果您不能只对所需的数据进行点查询，那么它可能不会很好地工作，或者过于复杂而不是一个好的选择。如果您想要一个时间序列数据库，Opentsdb 是很棒的选择。这将限制您只能进行时间​​序列类型的查询。那里有很多时间序列数据库，并且有很多构建在其之上的应用程序，例如Bosun和Grafana，仅列出我使用的两个。最后一个选项 HDI，我将以镶木地板格式（或某种列式格式）存储数据，在数据之上创建一个配置单元表并使用Spark SQL进行查询。实际上，您不需要使用 Spark，您也可以使用 Hive。但是你应该远离传统的 MapReduce，这种范式现在基本上已经死了，你不应该在其中编写新的代码。最重要的是，如果您不知道，那么它的学习曲线很陡峭。我使用所有技术，并将它们用于系统的不同部分，这实际上取决于应用程序的读写要求。如果我是你，我会考虑使用 Spark 和 Parquet，但它可能不需要很多新工具。