SQL 最佳数据库结构：NOAA 数据答案

【问题标题】：SQL Optimal Database Structure: NOAA DataSQL 最佳数据库结构：NOAA 数据
【发布时间】：2015-08-17 17:52:15
【问题描述】：

我正在尝试将大量每日天气数据存储到 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

【问题讨论】：

为什么不使用表分区？数据库负责为您创建和维护 95000 个单独的表：postgresql.org/docs/9.1/static/ddl-partitioning.html
唉，在 PostgreSQL 中没有内置分区，您基本上必须自己滚动或使用 pg_partman 等外部工具。它也不能很好地扩展到数百或数千个表。我强烈怀疑最好的选择是用几张大桌子保持简单。
按日期分区似乎是最合乎逻辑的。 3400 万行/年；它可能是每年或每 5 年或 10 年。
@wildplasser 如果 OP 想按站查询数据，按日期分区有什么意义？
你可能有一点。但我怀疑 station_ids 不会均匀分布，所以分裂可能会变得丑陋。（95K 分区不是一个选项；无论如何他都必须聚合）

标签： postgresql database-design relational-database noaa

【解决方案1】：

这还不够信息。

您在优化什么：查询性能、磁盘使用率、更新速度？

您正在运行哪些类型的查询？
您是否通常为一个电台获取所有数据（似乎不太可能）？日期范围？
如果您按日期查询，通常的分辨率是什么：日、月、年？
是“天气”表中的所有字段，还是只是一个示例？
您通常检索单个值还是多个不同的值？
您只是检索这些值，还是在数据库中进行聚合/分析？
您可以接受的查询性能是多少？

根据您对这些问题的回答，“捆绑”您的数据可能是有意义的（每条记录存储一天以上；我假设“日期”意味着它是一天，还是更细化？ )，以减少总行数。 Postgres 的每行开销相对较高 - 在您的估计中，仅行标题将占用 ~75GB。

或者，您可能想要调查以下内容：https://github.com/citusdata/cstore_fdw

使用更多表的优势在于更小的索引大小和（可能）物理数据局部性。在每个 station_id 一个表的极端情况下（不在您的情况下不实用），您根本不需要 station_id 上的索引，并且查询最终可能是对数据的简单 seq 扫描你需要。

缺点是许多数据库操作涉及对所有表的线性扫描（尤其是在规划期间），并且管理数据库更加复杂。

典型的建议是将表的数量保持在几百到可能几千。当然，除非您有一个非典型病例，并且您已经对其进行了测试，并且它对您有效。

【讨论】：