2

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

1 回答 1

2

这真的是不够的信息。

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

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

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

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

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

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

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

于 2015-06-03T17:59:24.600 回答