Question

我正在计划MySql数据库的结构，并且可以使用来自更多经验丰富的专业人士的一些建议。数据库所属的网站为每个注册用户收集90天的天气数据，并且必须支持数百万用户。

我已经为用户提供了一张表，其中包含他们的登录信息和联系信息，但我认为我需要第二张表来显示所有天气数据......

我打算做的基本上是为每个用户存储平均温度，湿度，风向等每天第四。每天使用新的一天的数据更新数据库，同时保留所有用户的昨天的条目（但限制为89天的旧数据+当天的数据）。

现在，拥有一个巨大的“数据”表，每个用户拥有90行（拥有数百万用户）是否最有意义？或者是否有一种更聪明的方法可以做到这一点，出于性能原因或类似原因更好？

每次用户登录并查看自己的个人资料或浏览其他人的个人资料时，都会访问（阅读和显示等）90天的数据。但它每天只会更新一次（覆盖最旧的条目，每个用户保持90行的限制。）

Answer 1

编辑：刚看到每个用户都有不同的天气数据。保持答案中的“共享数据”，但您对第二种情况感兴趣。

用户分享天气数据

基于最近的气象站ID。

我会存储一个（userId，stationId，isActive，isPreferred）表来了解用户感兴趣的数据，然后我会对stationWeatherData运行查询以获取该站的90行天气数据。

每个用户都有自己的天气数据

处理9亿用户时应该没有特别的问题。如果你真的不得不，你可以根据userId在不同的表上“分片”，例如，table weather174将保存所有用户的数据（userId％1000）给出174，你会发现自己拥有1000个表 - 可能在不同的服务器 - 千分之一。

所以你从一个大表开始，准备分片（或转移到云存储和无SQL密钥库数据库，例如MongoDB，VoltDB）。或者，只要UserID达到一百万，就会根据UserID进行分区。

甚至，您根本不使用数据库。如果您需要搜索或关联/加入数据，数据库是有意义的 - 这里您只是访问用户的“气象站”。

如果您知道自己永远不会查询“有多少用户有60％的湿度？”，但始终只有“用户1234567有什么数据？”，那么您可以将数据保存在二进制的滚动缓冲区中，JSON或HTML格式（在云存储，S3或MongoDB上 - 现在每个用户只有一个文档）。那么很大程度上取决于要更新的数据是如何到达的，即来自集中器或每个用户上传其自己的一大批。

Answer 2

对于我的回答（下面），我假设数据是特定于用户的，例如来自他们的个人后院气象站。如果它是与其他用户共享的数据，那么我的答案是次优的。

这似乎是合理的，但为什么要在90天停止？只要他们是有效用户，就保留每个用户的每日信息。所描述的查询总是类似于

SELECT temperature_avg, humidity, wind_direction, wind_speed
FROM weather_summary
WHERE user_id = (current_user)
ORDER BY sample_date DESC
LIMIT 90;

只要sample_date和user_id上有索引，这就非常有效。

根据我的经验，每个用户都有一个单独的表格。

Answer 3

如果您要存储每个用户的位置，则根据位置存储天气数据并根据需要将其映射到用户会更简单。

UserId - ＆gt; LocationId - ＆gt;天气详情。

假设平均每个位置会有多个用户，这应该会减少您的数据库大小，并且还应该更好地扩展。

Answer 4

我建议使用单个表来查看天气数据，按日期划分（参见MySQL documentation on range partitioning）。

通过这种方式，您可以轻松摆脱旧数据（只需删除最旧的分区），查询天数（例如，过去7天的平均温度）将非常有效。

Answer 5

在表格列上创建索引（id，全文索引）。
作为一个想法，您可以在此表上创建一些视图，其中包含基于位置，天，周，月或季度或字母表或其他条件的过滤数据，并基于您的代码将决定使用哪个视图获取搜索结果。
如果您的表有很多插入/更新操作，您可以创建多个表，并根据某些条件选择表名，以使用您的服务器端编程语言更新/插入数据。

我应该为每个用户（拥有数百万用户）存储90行数据吗？

5 个答案: