公開データセットを使用して BigQuery のベンチマークを行っています。同じテーブルを日ごとに分割しましたが、多くの利点が得られているかどうかは明らかではありません。良いバランスとは？
SELECT sum(score)
FROM `fh-bigquery.stackoverflow_archive.201906_posts_questions`
WHERE creation_date > "2019-01-01"
1 秒かかり、270.7MB を処理します。
同じ、パーティションで：
SELECT sum(score)
FROM `temp.questions_partitioned`
WHERE creation_date > "2019-01-01"
2 秒かかり、14.3 MB を処理します。
したがって、処理される MB には利点が見られますが、クエリは遅くなります。
いつ分割するかを決定するための良い戦略は何ですか?
（今日届いたメールより）
テーブルを分割するときは、各パーティションに十分なデータがあることを考慮する必要があります。各パーティションは別のファイルのように考えてください。365 個のファイルを開くのは、巨大なファイルを開くよりも遅くなる可能性があります。
この場合、ベンチマークに使用されるテーブルには、2019 年の 1.6 GB のデータがあります (このテーブルでは 6 月まで)。これは、毎日のパーティションごとに 1.6GB/180 = 9 MB のデータです。
このような少量のデータの場合、日ごとのパーティションに配置してもあまりメリットはありません。代わりに、年ごとにデータを分割することを検討してください。方法については、次の質問を参照してください。
もう 1 つの方法は、テーブルをまったく分割せず、代わりにクラスタリングを使用してデータを日付で並べ替えることです。その後、BigQuery は各ブロックの理想的なサイズを選択できます。
独自のベンチマークを実行する場合は、次のようにします。
CREATE TABLE `temp.questions_partitioned`
PARTITION BY DATE(creation_date)
AS
SELECT *
FROM `fh-bigquery.stackoverflow_archive.201906_posts_questions`
vsパーティションなし、日付によるクラスタリングのみ：
CREATE TABLE `temp.questions_clustered`
PARTITION BY fake_date
CLUSTER BY creation_date
AS
SELECT *, DATE('2000-01-01') fake_date
FROM `fh-bigquery.stackoverflow_archive.201906_posts_questions`
次に、クラスター化されたテーブルに対する私のクエリは次のようになります。
SELECT sum(score)
FROM `temp.questions_clustered`
WHERE creation_date > "2019-01-01"
そして、0.5 秒かかり、17 MB が処理されました。
比較:
勝者がいます！クラスタリングは、日ごとのデータを厳密に分割するよりも効率的なブロックに日単位のデータ (このテーブルにはあまり関係ありません) を編成しました。
これらのテーブルに対する各クエリの実行の詳細を確認することも興味深いです。
消費スロット時間
ご覧のとおり、未加工のテーブルに対するクエリは、1 秒で結果を取得するために多くのスロット (並列処理) を使用しました。この場合、50 人のワーカーが複数年のデータを含むテーブル全体を処理し、1,770 万行を読み取りました。パーティション化されたテーブルに対するクエリでは、多くのスロットを使用する必要がありましたが、これは、各スロットに小さい日次パーティションが割り当てられたためであり、0.9M 行で 153 の並列ワーカーを使用したことがわかりました。代わりに、クラスター化されたクエリは非常に少量のスロットを使用できました。データは、112 万行を読み取り、57 の並列ワーカーが読み取れるように適切に編成されていました。
以下も参照してください。