Question

到目前为止，我和我的朋友已经建立了一个小型系统，用于从我们地区周围的传感器收集天气数据。这是我们数据库中的一个表：

CREATE TABLE `Measurement` (
  `Id` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `SensorId` varchar(16) COLLATE utf8_unicode_ci NOT NULL,
  `Time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `Battery` double DEFAULT NULL,
  `Rain` double DEFAULT NULL,
  `Humidity` double DEFAULT NULL,
  PRIMARY KEY (`Id`,`Time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

环境：

ASP.Net Framework 4.6。
Web API 2。
MySQL社区版。

部署：

有一个数据库用于存储部署在单个服务器上的用户信息，天气测量和传感器信息。
有一个WEB API可以帮助客户端应用程序连接并获取数据。

我们的情况是：

此表用于存储60个传感器每10秒的气候元素测量值。目前，我们面临的问题是数据急剧增加，只需进行简单的计算：

1 （每10秒记录一次）* 6 （一小时内记录）* 24 （一天一小时）* 365 （一年中的一天）= 52 560 （记录一年）

52 560 （记录一年）* 60 （传感器）= 3 153 000 （记录）

因此，在从 60 传感器收集数据一年后，我们有 3 153 000 记录。这是太多的记录存储在一个表中（在我看来）。这就是我考虑解决方案的原因： - 将传感器的测量数据划分为多个数据库并部署到许多服务器上。每个传感器都有一台小型PC来存储其信息（使用API） - 当用户想要查询数据库以搜索他们所需的信息时，基于他们提供的传感器信息，Web服务器将调用不同的API端点来获取数据并汇总信息，然后将其显示给UI。

我的问题是：

排除我们用于部署数据库和微观服务的PC成本。这种部署是一种有效的做法吗？
有没有办法管理这种测量表？（数据每10秒钟增加一次，可以多次查询）？
如果有办法优化我的桌子，请告诉我？
我应该将传感器测量收集功能部署为微服务以提高性能和可扩展性吗？

谢谢，

Answer 1

你的整体问题太过宽泛。但是：

我们有3 153 000条记录。这是太多的记录存储到一个表（在我看来）

你的观点完全错了。存储数百万（或数千万甚至数亿或数十亿行）的数据库表没有问题。您需要开始更多地关注数据结构。

有两项关键技术可以提供帮助：

分区（您可以了解它here）
索引

更新速率为10次/秒，您不应该在插入数据时遇到任何问题。

Answer 2

似乎在＆＃34;简单的计算中有一些东西＆＃34;关于每年的读数。

24小时内有86,400秒。这是8,640＆＃34;十秒间隔＆＃34;每天。

每年365天，即3,153,600＆＃34;十秒间隔＆＃34;每年。

时间60个传感器（每个传感器每10秒读取一次），即每年1.89亿（189,216,000）个读数。

要管理包含大量行的表，请考虑Time列上的范围分区。例如，按周或按月。

我们确实需要多少VARCHAR(255)来识别读数/传感器？如果我们可以使用INT数据类型，那将只有四个字节。 DATETIME数据类型将花费我们八个字节，其中TIMESTAMP数据类型只需要四个字节。

如果我沿着将桌子分成小桌子的路线走下去，我会考虑60张桌子，每张桌子一张。并将Id / SensorId值（列）移出表格，并将其移动到表格的标识符中。这将使我们只用Time作为PRIMARY KEY，并保存一大堆重复数据。

我们仍然可以在每个表上实现分区。

但到目前为止，我们只讨论插入行。讨论缺少什么，真正重要的是我们将如何查询数据;我们需要支持哪些查询模式。

在使用微服务进行操作之前，我会先处理数据结构。如果每个读取都在一个单独的表中，那么这有助于跨多个服务器对这些表进行分片。但它对应用程序来说不会透明。应用层需要知道这一点，并使用每个表的正确连接来使用多个数据库连接。

Answer 3

因为你的目标是一个巨大的＆＃39;表，您需要尽可能地缩小数据类型。使用当前架构的189M /年行可能是40GB /年

  `Id` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `SensorId` varchar(16) COLLATE utf8_unicode_ci NOT NULL,

他们需要是utf8吗？无论您是否需要utf8，请对Id和SensorId中的每一个进行标准化，或对该对进行标准化。可能MEDIUMINT UNSIGNED（3个字节，16M限制）就足够了。

  `Battery` double DEFAULT NULL,
  `Rain` double DEFAULT NULL,
  `Humidity` double DEFAULT NULL,

DOUBLE需要8个字节，并为您提供16位有效数字。我怀疑你是否可以读取湿度超过3位有效数字。 FLOAT只占用4个字节，并为您提供7位有效数字。 DECIMAL(4,2)可能值得考虑 - 值高达99.99，仅占用2个字节。（等）

  PRIMARY KEY (`Id`,`Time`)

在不知道SELECTs的情况下，我们无法判断这是多么有用。

上述更改可能会降低到10GB /年。

完成一些这样的工作，然后让我们谈谈摘要表 - 你不想要扫描189M行的任何内容！

您还没有说过任何会触发使用分区的内容。

＆＃34;它可以帮助用户按照＆＃34; - 过滤怎么样？你真的在帮助用户获取189M行吗？

Answer 4

可能是一个完整的不同的解决方案可以查看您实际想要长期存储的内容。当然，您希望通过数据收集结果回答这么多问题。

解决方案是否可以定期运行，生成一些关键见解，长期存储，然后修剪表格以创建更多空间 - 或归档“旧”数据？

只是一个 - 拉尔斯

Answer 5

简而言之：您可能希望查看更专用于时间序列数据的解决方案。例如influxdb。为了使您的系统更加强大，您可能还希望包含快速流处理器，例如Apache Kafka。

以下是您的问题的答案：

排除我们用于部署数据库和微服务的PC成本是否测量。这种部署是一种有效的做法吗？

这个问题对于您的要求并不是很清楚，但我认为您在询问为数据库/服务设置使用无服务器云部署是否有效。如果是这样，那么答案可能是：是的，因为作为一个所谓的小团队，您不必处理硬件的设置和维护（避免这种成本）。

有没有办法管理这种测量表？（数据是增加每10秒钟，可以多次查询）？

再次，将influxdb视为一种更专业的解决方案，可以帮助您解决有关时间序列数据管理的许多典型问题。

如果有办法优化我的桌子，请告诉我？

请参阅所有数据库专家的其他精彩答案。

我应该将传感器测量采集功能部署为微型提高性能和可扩展性的服务？

您的收集功能实际上是一个数据流端点，因此您可能希望使用流处理器（例如Kafka）来实现此目的。现在，当您的流保存在一个大队列中（在kafka中称为主题）时，您可以随时使用任何大数据技术（例如使用spark / hadoop）来处理它。以任何格式/分析的方式存储它（这很可能是传统的rdb或nosql数据库发挥作用的地方）。

微服务是一种架构风格，旨在帮助解决具有复杂解决方案的大型组织的组织挑战。根据您的应用程序设置的大小，但如果您在开发/ devops团队中超过10人，您可能想要考虑将您的实现分成多个微服务。有关详细信息，请阅读this awesome article。

管理经常更新和查询的表

5 个答案: