我正在尝试将大量日常天气数据存储到 postgreSQL 数据库中。这看起来似乎不是很多数据，但大约有 95,000 个站点的每日数据可以追溯到 100 年前。这可能意味着数百万条记录 (95,000 * 365 * 100) = 3,467,500,000。虽然这是一个高估，但对我来说，将所有日常数据存储在一个表中，并将电台 ID 作为外键映射到另一个包含电台信息的表，似乎仍然不切实际。构建此数据以按站查询数据系列的最佳方法是什么？我应该为每个电台创建一个表(将产生 95,000 个表)还是应该尝试更广泛的内容，例如为每个区域创建一个表？有什么优点和缺点？非常感谢任何帮助。
我的数据如下所示:
Stations
*ID
-longitude
-latitude
-elevation
-country
-state
-name
...
Weather
*Station ID
*Date
-Precipitation
-High Temp
-Low Temp
最佳答案
这还不是足够的信息。
您要优化哪些方面:查询性能、磁盘使用情况、更新速度？
- 您正在运行什么类型的查询？
- 您通常会获取某个电台的所有数据(似乎不太可能)？日期范围？
- 如果按日期查询，通常的分辨率是多少:日、月、年？
- 这些是“天气”表中的所有字段，还是只是一个示例？
- 您通常会检索单个值还是多个不同的值？
- 您只是检索这些值，还是在数据库中进行聚合/分析？
- 您可以接受的查询性能是多少？
根据您对这些问题的回答，“捆绑”您的数据可能是有意义的(每条记录存储超过一天的数据；我假设“日期”意味着它是一天，还是更精细？ )，以减少总行数。 Postgres 的每行开销相对较高 - 根据您的估计，仅行标题就会占用约 75GB。
或者，您可能想调查如下内容:https://github.com/citusdata/cstore_fdw
使用更多表的优点是较小的索引大小和(可能)物理数据局部性。在每个 station_id 一个表的极端情况下(在您的情况下不实用)，您根本不需要 station_id 上的索引，并且查询最终可能只是对数据进行简单的 seq 扫描你需要。
缺点是许多数据库操作涉及对所有表的线性扫描(尤其是在规划期间)，并且管理数据库更加复杂。
典型的建议是将表的数量保持在几百到也许几千。当然，除非您有一个非典型案例，并且您已经对其进行了测试，并且它对您有用。
关于postgresql - SQL优化数据库结构: NOAA Data，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30621476/