Question

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

Answer 1

这些信息确实不够。

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

您正在运行哪些类型的查询？
您是否通常为电台提取所有数据（似乎不太可能）？日期范围？
如果您按日期查询，通常的解决方案是什么：日，月，年？
那些天气中的所有字段都是＆＃39;表，或者只是一个样本？
您通常会检索单个值还是许多不同的值？
您只是检索这些值，还是在数据库中进行聚合/分析？
什么是可接受的查询性能？

根据你对这些问题的回答，将＃34;束起来＆＃34;您的数据（每条记录的存储时间超过一天;我假设＆＃39;日期＆＃39;表示它是一天，还是更精细？），以减少总行数。 Postgres具有相对较高的每行开销 - 在您的估计中，行标题将占用大约75GB。

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

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

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

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

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

1 个答案: