1年後の更新:
この状況以降、いくつかの大きな進展に注意してください。
- クエリ料金が 85% ダウン。
- GithubArchive は現在、日次および年次のテーブルを公開しています。そのため、クエリを開発している間は、常に小さなデータセットでテストしてください。
BigQuery の料金は、クエリされるデータの量に基づいています。そのハイライトの 1 つは、数ギガバイトから数秒で数テラバイトをスキャンする簡単なスケーリングです。
私が知っているほとんどの (またはすべて?) 他のデータベースは、指数関数的に高価なリソースを必要とするか、これらの量のデータを処理することができません - 少なくとも合理的な時間枠では.
つまり、線形スケーリングとは、テラバイトを超えるクエリは、ギガバイトを超えるクエリよりも 1000 倍高価であることを意味します。BigQuery ユーザーはこれを認識し、それに応じて計画する必要があります。これらの目的のために、BigQuery は「dry run」フラグを提供します。これにより、クエリを実行する前にクエリされるデータの量を正確に確認し、それに応じて調整できます。
この場合、WeiGong は 105 GB のテーブルをクエリしていました。10 個のSELECT * LIMIT 10
クエリはすぐに 1 テラバイトのデータに達します。
これらの同じクエリで消費するデータを大幅に減らす方法があります。
- クエリ
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 分の 1 以上低くなります。
たとえば、クエリを使用して 1 月のデータをすべて抽出すると、わずか 91.7 MB の新しいテーブルが残ります。このテーブルのクエリは、大きなテーブルよりも 1000 分の 1 のコストで済みます。
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 アーカイブの所有者と協力して、1 つのモノリシック テーブルの代わりに毎月のデータを保存して、これをさらに簡単にするようにしています)