Question

我尝试使用Google Cloud Datastore来存储METAR观测资料（机场天气观测），但我遇到了我认为爆炸指数的问题。我的station_id索引（4个字符的字符串）比实际数据本身大20倍。该数据库每天将增加大约25万个实体，因此索引大小将成为一个问题。

表格

 - observation_time (Date / Time) - indexed
 - raw_text (String) (which is ~200 characters) - unindexed
 - station_id (String) (which is always 4 characters) - indexed

综合指数：

  - station_id (ASC), observation_time (ASC)

查询

我将运行的唯一查询是：

query.add_filter('station_id', '=', station_icao)
query.add_filter('observation_time', '>=', before)
query.add_filter('observation_time', '<=', after)

其中before和after是日期时间值

索引大小

name               type         count         size      index size
observation_time   Date/Time    1,096,184     26.14MB   313.62MB    
station_id         String       1,096,184     16.73MB   294.8MB

数据存储报告：

Resource           Count        Size
Entities           1,096,184    244.62MB
Built-in-indexes   5,488,986    740.63MB
Composite indexes  1,096,184    137.99MB

帮助

我想我的第一个问题是：我错过了什么？我假设我做了一些未经优化的事情，但我无法弄清楚是什么。查询时间不是一个直接的问题，只要查找保持低于~2s。

我可以简单地删除内置索引，复合会继续工作吗？

我已经在谷歌和StackOverflow上阅读了，但似乎无法解决这个问题。我之所以不尝试删除所有内置索引的原因是下载/取消索引/放入所有数据需要相当长的时间我需要48小时才能更新仪表板摘要 - 即它在得到结果之前我会花几天时间。

Answer 1

正如+ Jeffrey Rennie指出的那样，“爆炸指数”是一个非常具体的术语，不适用于此。

您可以看到如何根据our documentation here计算存储空间大小，因此您可以将其应用于您的示例，以查看大小相加的位置。

TL; DR：您可以使用稍微简洁（但仍然可读！）的属性名称来节省空间。例如，observation_time到observation等

要记住的关键事项：

要获得复合索引，您需要将各个属性编入索引，因此请勿删除内置函数或它将停止工作
内置插件被索引两次 - 一次用于升序，一次用于降序
种类名称和属性名称是每个实体的索引中使用的字符串，因此它们越长索引越大

Cloud Datastore避免在非常简单的表上爆炸索引

1 个答案: