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

Question

情况： 我开始了一份新工作，并被分配了弄清楚如何处理他们的传感器数据表的任务。它有 13 亿行传感器数据。数据非常简单：基本上只是一个传感器 ID、一个日期和那个时间点的传感器值（双精度）。

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

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

我正在寻找一种更好的方式来存储和查询这些数据（按日​​期），并且由于我们那里有很多“大数据”产品，而我没有管理此类大数据集的实际经验，我'我在这里询问任何指针。

这不是一家大公司，我们的资源也不是无限的；）

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

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

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

1. 将数据保存在 SQL Server 中

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

2. 将数据移动到 Azure SQL Server。

   在那里，我们将以更少的钱获得分区功能，但是一旦我们的数据库增长到 250GB 以上，它的成本就会高得多（而且超过 500GB 的成本太高了）。

3. 使用多个数据库

   我们可以为每位客户使用 1 个数据库。几个较小的 DB 会比 1 个大 DB 便宜，但我们有很多客户并计划更多，所以我不太喜欢考虑管理所有这些数据库。

4. Azure 存储表

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

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

5. Azure HDInsight（Azure 中的 Hadoop）

   如前所述，我没有使用大数据的经验，目前我对 Hadoop 的了解还不够好，无法知道它是否适合我们的情况（通过 API 在给定的时间跨度内公开传感器数据）。我应该深入挖掘并学习，还是将时间花在寻找另一种选择上更好？

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

更新 1： 回答下面cmets中的一些问题。

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

更新 2： 今天，我对 azure table storage 和 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 表存储。

我很快将向外部顾问展示我的发现，因此我也很高兴了解他对事物的看法。

Answer 1

因此，到今年年底，您将拥有 30 亿条记录（这才刚刚开始）。每条记录是 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

对于现代时间序列数据库（例如 VictoriaMetrics）来说，每年 30 亿个数据点是相当少的数字。它可以在具有 64 个 vCPU 的计算机上以每秒 1900 万个样本的摄取速度在不到 3 分钟的时间内持久保存这么多数据点。详情请见this article。

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

Answer 3

所以我以某种方式使用了您列出的所有技术。您需要执行什么样的查询？因为根据这一点，您可以统治一些解决方案。如果您不需要查询很多不同的方式，Table Storage 可以很好地为您工作。如果您关注guidelines，它的扩展性会非常好，而且很便宜。但是，如果您不能只对所需的数据进行点查询，那么它可能效果不佳，或者过于复杂而成为一个不错的选择。如果您想要一个时间序列数据库，Opentsdb 非常棒。这将限制您使用时间序列类型的查询。那里有a lot of time series dbs，还有很多基于它构建的应用程序，比如Bosun 和Grafana，列出我使用的两个。最后一个选项 HDI，我将以 parquet 格式（或某些列格式）存储数据，在数据顶部创建一个配置单元表并使用 Spark SQL 进行查询。你真的不需要使用 Spark，你也可以使用 Hive。但是你应该远离传统的 Map Reduce，这种范式现在基本上已经死了，你不应该在其中编写新代码。最重要的是，如果你不知道它，它周围有陡峭的学习曲线。我我们所有的技术，我们将它们用于系统的不同部分，这实际上取决于应用程序的读写要求。如果我是你，我会考虑使用 spark 和 parquet，但它可能不需要很多新工具。