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

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

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

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

@H_404_3@关于我们的用例的更多细节：

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

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

@H_404_3@>将数据保存在sql Server中

@H_404_3@但是对表进行分区(它现在没有分区).这将需要企业版的sql Server,其成本很高.
>将数据移动到Azure sql Server.

@H_404_3@在那里我们将获得更少的资金分区功能,但是一旦我们的DB增长到250GB以上,它就会花费更多(并且超过500gb).
>使用多个数据库

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

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

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

@H_404_3@如上所述,我没有大数据的经验,目前我还没有充分了解Hadoop是否适合我们的情况(在给定的时间跨度内通过API公开传感器数据).我应该更深入地学习,还是我的时间更好地花在追求另一种选择上？

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

@H_404_3@更新1：
在下面的评论中回答一些问题.

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

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

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

@H_404_3@但它的成本远远超过Azure表存储,我认为我可以优化我的代码以提高Azure表存储的查询性能(更细粒度的分区键和并行运行的请求).因此,由于简单,价格和“足够好”的性能,我现在倾向于Azure Table Storage.

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