BigQuery料金FAQ

ワークロード次第です。定額制でアイドル状態のスロットがあった場合は、EditionsとAutoscalingの組み合わせでコンピュート費用を下げられる可能性があります。Compressed Storageによりストレージ側のコストも削減できます。単一の項目ではなく、TCO全体で捉えてください。

別物です。BigQueryのコミットは、スロット/時間あたりのレートを引き下げます。3年コミットで分析コストが約40%割引されます。ストレージ料金は割引対象外です。

はい。Editionsの挙動、特にAutoscalingの最低単位や1分のスケールダウンは、想定外の形でコストに影響することがあります。コミット前に、代表的なワークロードでPOCを実施してください。

長時間安定して稼働し、大量のデータをスキャンするワークロードはEditionsが最適です。短時間でスパイク的なクエリは、Autoscalingが100スロット単位で割り当て、最低1分間分課金されるため、通常はオンデマンドの方が割安です。

圧縮率次第です。文字列中心のデータはよく圧縮されます。整数中心のデータは圧縮が効きにくい傾向にあります。以下のGitHub gistに、選択肢を比較するクエリを用意しています:https://gist.github.com/sayle-doit/264d28dd990c478beb90b90ac3923681

はい。BigQuery Current Usage Analysis Toolのシートを複製し、手順に従ってください:https://docs.google.com/spreadsheets/d/1Sv6SzATtAyGYID2Wg0qGdcpLfe7YdOsH4dFKHHtS59c/edit

はい。あるプロジェクトはオンデマンド、別のプロジェクトはStandard Edition、さらに別のプロジェクトはEnterprise、という運用が可能です。プロジェクト単位でワークロードを分割することは、最も効果的な最適化手段の1つです。

SQLはそのまま動作します。ただし、Flexスロットを動的に購入するコードがある場合は、それが動作しなくなります。Terraformのサポートは対応中のため、当面はignore_changesを利用してください。総スロット消費量を減らすためのリファクタリングも検討する価値があります。

はい。定額制コミットは、期間中はコミット価格のままEnterprise Editionに変換されます。ベースラインを超えるスロットは通常のEnterpriseレートで課金されます。Autoscalerで設定した上限まで拡張可能です。

いいえ。Googleのツール側で、定額制の予約がある場合はCompressed Storageの利用が明示的にブロックされます。利用にはEdition、またはオンデマンドのみのプロジェクトが必要です。

非圧縮バイトです。オンデマンドのプロジェクトから圧縮データをクエリしても、コンピュートコスト面での利点はありません。削減効果はストレージのみに限られます。

いいえ。長期保存の仕組みは、圧縮データにも非圧縮データにも引き続き適用されます。

はい。Editionsのクエリは、Autoscalerの1分間のスケールダウンにより、最低1分間の課金となります。10秒のクエリでも1分間分のスロット料金が発生します。

Google Cloud ConsoleでMonitoringを開き、Metric Explorerでスロット関連のメトリクスを検索してください。DoiTのお客様は、チケットを起票いただければBigQueryスペシャリストと一緒に確認できます。

はい。常時利用するスロットのベースラインと、許容できる上限を設定できます。アイドル時間帯がある場合は、割り当て済みの未使用スロットに課金されないよう、ベースラインを0に設定してください。

BigQuery上のdbtはコンピュート負荷の高い処理です。Editionsではコンピュートコストが上がっているため、スロット使用量をチューニングし、適切なプロジェクトに分離しない限り、dbtワークロードのコストは通常上昇します。

タイムトラベルは無効化できませんが、期間を7日から3日に短縮できます。フェイルセーフは無効化可能です。フェイルセーフからの復元にはGoogle Cloudのサポートチケットが必要です。

はい。たとえばBigLakeのメタデータ更新はスロット時間を消費しますが、スキャンバイト数はゼロのため、オンデマンドでは無料です。Editionsではスロット分の料金が発生します。こうしたジョブはオンデマンドのプロジェクトに分離してください。