情境：我开始了一项新的工作，并被分配了一项任务，即弄清楚如何处理他们的传感器数据表。它有13亿行传感器数据。数据非常简单：基本上只是一个传感器id、一个日期和该时间点的传感器值（双倍）。
目前，数据存储在mssql服务器数据库的表中。
到今年年底，我预计排数将增加到20-30亿。
我正在寻找一种更好的方法来存储和查询这些数据（按日期），由于我们有很多“大数据”产品，而且我没有管理这些大数据集的实际经验，所以我想在这里提供一些建议。
这不是一家大公司，我们的资源也不是无限的；）
关于我们的用例的更多细节：
数据以图表形式绘制，并显示传感器值随时间的变化。
我们正计划创建一个api，让我们的客户在他们感兴趣的任何时间段获取传感器数据（。。。两年前的数据和上月的数据一样重要）。
到目前为止，我的研究使我考虑了以下解决方案：
将数据保存在sql server中
但是分区表（现在没有分区）。这将需要企业版的sqlserver，成本很高。
将数据移动到azure sql server。
在那里，我们可以用更少的钱获得分区功能，但是一旦我们的数据库增长到250gb以上，它的成本就会更高（而且超过500gb的成本太高了）。
使用多个数据库
我们可以使用每个客户1分贝。几个较小的数据库将比一个巨大的数据库便宜，但我们有很多客户和更多的计划，所以我真的不喜欢考虑管理所有这些数据库。
azure存储表
到目前为止，这是我最喜欢的选择。我们可以按公司/传感器/年/月对数据进行分区，使用日期作为行键并存储传感器值。
我还没来得及测试查询性能，但据我所知，应该是不错的。但是有一个主要的缺点，那就是每个http请求返回1000个项目的限制。如果我们需要获取一周的所有传感器数据，我们需要发出大量的http请求。我现在不确定这对我们的用例有多大问题。
azure hdinsight（azure中的hadoop）
如前所述，我没有大数据方面的经验，目前我对hadoop的了解还不够充分，不知道它是否适合我们的情况（在给定的时间跨度内，通过api公开传感器数据）。我应该更深入地挖掘和学习，还是把时间花在寻找另一种选择上更好？
有没有人有过类似的经历。什么对你有用？请记住，价格很重要，“简单”的解决方案可能比非常复杂的解决方案更受欢迎，即使复杂的解决方案在几秒钟内表现更好。
更新1：回答下面评论中的一些问题。
大约有12000个传感器，可能每15秒报告一个值。也就是说，每天约7000万美元。实际上，并不是所有这些传感器都开启了“报告”，因此我们每天获取的数据并不多，但由于我们自然希望扩大更多的客户和传感器，因此我真的需要一个每天可以扩展到数百万传感器值的解决方案。
分区是一种解决方案，使用多个数据库和/或多个表是我认为是的，但如果/当我用尽了其他解决方案时，我认为这是一种回退。
我读了更多关于hbase的书，http://opentsdb.net/ 还有谷歌的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请求中提取30万条记录（不过需要30秒）。
但是它的成本比azure表存储要高很多，我认为我可以通过azure表存储（更细粒度的分区键和并行运行请求）优化代码来提高查询性能。所以现在我倾向于azure表存储，因为它的简单性、价格和“足够好”的性能。
我很快就要把我的发现提交给一位外部顾问，所以我很高兴了解他对事情的看法。