我们需要将天气预报数据存储在数据库中,以便可以通过API通过纬度/经度查询它。
预测数据本来是GRIB2文件的,这是一种具有多个波段的地理参考栅格格式。可以将GRIB2文件转换为csv,这会使文件大小增加20-40倍。如果将csv存储在数据库中,则数据约为35GB,并包含以下列:
0,rt,timestamp
1,vt,timestamp
2,param,string
3,level,string
4,lon,float
5,lat,float
6,value,float
此数据每小时都会更改,需要重新输入到数据库中。这意味着在任何情况下,摄取的时间都不能超过一个小时(最好短得多)。
最重要的是,必须将30天前期的预测数据存储在另一个数据库表中,并且还可以通过API查询这些数据。30天的预测数据价值720小时,即720 * 35gb = 25.2 TB。每小时最旧的721小时必须删除,并且数据将从最新的预测表传输到存档表。
我研究了多个托管的google数据库解决方案(BigQuery,Cloud Spanner,Datastore,BigTable)。到目前为止,似乎BigTable定价结构最适合此API。
但是,似乎无法按列值查询数据,更不用说按两个列值(纬度和经度)查询数据了。是这样吗有什么方法可以结构化数据来解决此限制?如果是这样,我将如何查询?
如果BigTable是执行该工作的错误工具,我建议您提供一种更合适的服务。
但是,您必须要牢记两个主要的restrictions of BigTable key-row design:
根据您的查询,您将具有数据库设计或其他设计,您将不得不在设计和查询之间找到折衷方案。
在这种情况下,您必须将(纬度,经度)映射到单个键,主要可以这样做:
带有唯一列stats
(来自Cloud Shell)的具有30天数据的表的示例:
cbt createinstance my-instance "My instance" my-instance-c1 europe-west1-b 3 SSD
cbt createtable weather-ts "families=stats:maxage=30d||maxversions=31"
将值作为CSV(所有字符串)设置为键123123:
cbt set weather-ts 123123 stats:value='FIRST_CSV'
cbt set weather-ts 123123 stats:value='SECOND_CSV'
查看存储的值:
cbt read weather-ts
我的输出:
2020/01/06 10:29:37 -creds flag unset, will use gcloud credential
----------------------------------------
123123
stats:value @ 2020/01/06-10:29:35.093000
"SECOND_CSV"
stats:value @ 2020/01/06-10:29:33.224000
"FIRST_CSV"
----------------------------------------
Bigtable automatically compresses text,因此总存储空间使用量可能少于您的预期。