一年后更新:
请注意自这种情况以来的一些重大发展:
- 查询价格下降85%。
- GithubArchive 现在正在发布每日和每年的表格 - 因此在开发查询时始终在较小的数据集上测试它们。
BigQuery 定价基于查询的数据量。它的一大亮点是它的扩展性,从几千兆字节扫描到几兆兆字节。
线性定价是一个特点:我所知道的大多数(或全部?)其他数据库将需要成倍增加的资源,或者只是无法处理这些数据量——至少在合理的时间范围内是这样。
也就是说,线性扩展意味着 TB 上的查询比 GB 上的查询贵 1000 倍。BigQuery 用户需要意识到这一点并做出相应的计划。出于这些目的,BigQuery 提供了“试运行”标志,它允许人们在运行查询之前准确查看将要查询的数据量 - 并相应地进行调整。
在本例中,WeiGong 正在查询一个 105 GB 的表。十个SELECT * LIMIT 10
查询将很快达到 1 TB 的数据量,依此类推。
有一些方法可以使这些相同的查询消耗更少的数据:
- 而不是查询
SELECT * LIMIT 10
,只调用您要查找的列。BigQuery 根据您查询的列收费,因此拥有不必要的列会增加不必要的成本。
例如,SELECT * ...
查询 105 GB,而SELECT repository_url, repository_name, payload_ref_type, payload_pull_request_deletions FROM [githubarchive:github.timeline]
仅经过 8.72 GB,使此查询的成本降低了 10 倍以上。
例如,使用查询提取所有一月份的数据会留下一个只有 91.7 MB 的新表。查询这张表比大表便宜一千倍!
SELECT *
FROM [githubarchive:github.timeline]
WHERE created_at BETWEEN '2014-01-01' and '2014-01-02'
-> save this into a new table 'timeline_201401'
结合这些方法,您可以从一张 4000 美元的钞票变成一张 4 美元的钞票,获得同样数量的快速和有见地的结果。
(我正在与 Github 存档的所有者合作,让他们存储月度数据而不是一个单一的表,以使这更容易)