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

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

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

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

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

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

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

数据以图形绘制,并显示传感器值随时间的变化.

我们计划创建一个API,让我们的客户在他们感兴趣的任何时间段内获取传感器数据(...... 2年前的数据与上个月的数据一样重要).

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

将数据保留在SQL Server中

但是对表进行分区(它现在没有分区).这将需要企业版的SQL Server,其成本很高.

将数据移动到Azure SQL Server.

在那里我们将获得更少的资金,但是一旦我们的DB增长到250GB以上,它的成本会更高(并且超过500gb).

使用多个数据库

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

Azure存储表

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

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

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.

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