リアルタイム分析でBigQueryがClickHouse Cloudに及ばない理由

共通の検証ハーネス

両システムとも、同じソースデータセット、スキーマ、分析ワークロード、ペーシングモデル、クエリスケジュール、結果フォーマットを使用しました。送信先固有のアダプターが配信とタイミングを処理しました。第1回では共通の手法を解説しており、BigQuery ベンチマーク規約には今回のプロバイダーの実装が記録されています。

データセットと前処理

完全な NBBO データセットには、113,219,565,734 行の幅の狭い 12 カラムのデータが含まれています。生データテーブルは銘柄コードとイベントタイムスタンプの (sym, t) を使用し、デイリーサマリーは銘柄コードと UTC 日付の (sym, day) を使用しました。サマリーは、集計クエリで使用される件数、合計、価格の最小値・最大値を保持しました。

継続的なワークロード

新規の行は毎秒 100 万行を目標にペース調整され、その間、集計クエリとドリルダウンクエリがそれぞれ 10 分間隔および 1 時間間隔のスケジュールで実行されました。これにより、継続的に生成され到着と同時に前処理されるデータがモデル化されます。BigQuery の max_staleness オプションは未設定のままにされたため、MV クエリはより新しいベーステーブルのデータを含める必要がありました。

推奨構成とサイジング

ClickHouse Cloud は 16 CPU、64 GiB の読み取りノードを使用しました。BigQuery は動的にスロットが割り当てられ固定の予約を持たない オンデマンドのサーバーレスクエリコンピュートを使用しました。これは固定された 2 つの 16 CPU 割り当ての比較ではありません。Capacity の代替案は、同じ測定されたスロット消費量を Enterprise の定価で換算したものであり、独立した Capacity の実行を表すものではありません。

① 前処理コスト

完全なパスには、ClickHouse の完全な 2 ノード HA 取り込みサービスと、BigQuery の Storage Write API による取り込みおよび自動 MV 更新が含まれます。BigQuery の自動再クラスタリングには 個別の料金はかかりません。Capacity と On-demand の前処理の合計は両方とも同じ取り込みメーターを保持し、それぞれのコンピュートモデルに基づいて更新リソースに価格を適用しています。

② クエリコストと ③ 実行時間

ClickHouse のクエリコストは、記録された所要時間に読み取り側のコンピュート料金を掛けたものです。BigQuery Capacity はジョブのスロット秒数を使用し、On-demand は課金対象バイト数を使用します。両方の BigQuery 選択肢は、③ に対して同じ記録されたクエリ所要時間を使用します。これらの正規化されたコストは、プロバイダーの請求書全体ではなく、承認されたクエリ作業を表しています。

目標レートと観測レート

BigQuery は論理データセット全体を約 31.5 時間で確認応答(ACK)し、平均 999,495 行/秒でした。ClickHouse は約 36.75 時間で取り込みを完了し、平均約 毎秒 86 万行でした。取り込みサマリーには、BigQuery が確認応答した行がプロバイダーの書き込み成功メーターとは別に記録されています。そのメーターには 113,172,471,254 行の成功が記録されており、ClickHouse の書き込みコストのエビデンスには 113,217,743,918 行が含まれ、その差は 0.040% です。クエリの比較には、113,219,565,734 行の参照範囲を使用しています。

レポート期間

クエリごとのレイテンシプロットは 1,000 億行で停止します。前処理コストは、完全な取り込みメーターと収集された更新使用量を保持します。累積クエリコストと実行時間は、参照エンドポイントまでの承認されたアクティブな取り込みの観測値を使用し、その後のクエリ観測値は除外されます。表示される合計は四捨五入されています。料金に関する注記には、更新エクスポートの境界と除外事項が記載されています。

料金の基準

ClickHouse Cloud は 1 コンピュートユニット(CU)あたり 1 時間 $0.3903 を使用します。BigQuery はチェックイン済みの 米国の定価 を使用します: Storage Write API 取り込みが $0.025/GiB、Enterprise Capacity が $0.06/スロット時間、On-demand 分析が $6.25/TiB です。承認されたサマリーは完全な精度の入力を保持しています。Capacity と On-demand は、同一ジョブに対する代替のモデル化されたコストです。

① 完全な前処理コスト

これには、ストリーミング取り込みメーター全体、追加料金なしの自動再クラスタリング、および収集された MV 更新の使用量が含まれます。

CLICKHOUSE CLOUD

2 CU × 36.75 時間 × $0.3903/CU 時間 = $28.68705(両方の HA 取り込みノードを含む)。

BIGQUERY の取り込み

Write API メーターは、成功した入力バイト数を使用して 9,642.7384687 GiB × $0.025/GiB = $241.06846172 を記録しています。クライアントが確認応答した Arrow バイト数とプロバイダーが計測した入力バイト数は別の指標です。

BIGQUERY のクラスタリング

自動再クラスタリングは個別の料金なしに含まれます。有料の手動再編成ジョブは追加されていません。

BIGQUERY の MV 更新

362 ジョブのエクスポートには 121,166.568 スロット秒が含まれており、$0.06/スロット時間で計算すると $2.0194428、または 4,137,783,656,448 課金対象バイト数で、$6.25/TiB で計算すると $23.52057695 となります。前処理の合計は、Capacity で $243.08790452、On-demand で $264.58903867 です。

② 正規化クエリコスト

BigQuery は、承認された同じクエリジョブに対し、消費されたスロット秒数または課金対象バイト数によって価格を算出します。ClickHouse は、記録された所要時間を読み取り側のレートで計算します。

CLICKHOUSE CLOUD

四捨五入されたコストサマリーの入力値を使用すると、8 CU × $0.3903/CU 時間 × (10.324 秒の集計 + 47.962 秒のドリルダウン) ÷ 3,600 ≈ $0.05055 となります。

BIGQUERY CAPACITY

集計ジョブのコストは $4.29558297、ドリルダウンジョブのコストは $0.45264198 で、合計 $4.74822495 です。合計 79.1370825 スロット時間 × $0.06/スロット時間の割り当てには、記録されたジョブのスロット消費量が使用されます。

BIGQUERY ON-DEMAND

集計ジョブのコストは $20.94800472、ドリルダウンジョブのコストは $3.85683775 で、合計 $24.80484247 です。合計の課金対象ボリュームは 3.9687748 TiB × $6.25/TiB です。これは Capacity 料金に対する代替案であり、追加される要素ではありません。

コストの境界

前処理モデルは、プロデューサー完了後の最終更新を含む、完全な書き込み成功メーターと収集された 362 件のすべての更新ジョブを保持します。クエリの合計からは、取り込み後のその後の観測値およびエビデンス収集ジョブが除外されます。データベースストレージ、無料枠、割引、アイドル時/最小容量料金、プロデューサーインフラストラクチャ、およびネットワーク料金は除外されます。

③ 累積クエリ実行時間

ClickHouse: 10.324 秒(集計)+ 47.962 秒(ドリルダウン)= 58.286 秒。BigQuery: どちらの料金モデルでも 2,751.868 秒(集計)+ 209.518 秒(ドリルダウン)= 2,961.386 秒。

比較の境界

① は完全な取り込みの前処理使用量を保持します。② と ③ は、参照範囲全体の行の進行状況に合わせて調整された、190 回の 4 クエリ集計バッチと 33 回の 2 クエリドリルダウンバッチを使用します。レイテンシの統計には、独立した 1,000 億行のウィンドウが使用されます。Capacity の代替案は、測定されたリソースに適用される価格を変更するだけであり、クエリハードウェアを変更したりワークロードを再実行したりするものではありません。

最終スコア

ClickHouse: ($28.68705 + $0.05055) × 58.286 = 1,674.99975。BigQuery Capacity: ($243.08790452 + $4.74822495) × 2,961.386 = 733,938.44411(比率は 438.172 倍)。BigQuery On-demand: ($264.58903867 + $24.80484247) × 2,961.386 = 857,006.98809(比率は 511.646 倍)。見出しの数値は四捨五入して 438 倍および 512 倍としています。

ClickHouse のライター使用率の結果は、バックグラウンドメンテナンスと並行して取り込みが継続していることを示しています。CPU 使用率は利用可能な 4 コア中約 3.1 コアで推移し、追跡メモリは許容量内に収まり、バックグラウンドマージは毎秒数百万行を処理し、パーティションあたりのアクティブパートの最大数は約 100 に保たれました。これらの診断情報は、今回の比較で再利用された ClickHouse のソース実行を説明するものです。

高可用性のために両方のノードが保持されたため、準備コストには 2 ノード分の完全なデプロイが含まれています。

同じ取り込みの課題

頻繁なアプリケーションの書き込みを、効率的なストレージへの書き込みに変換する必要があります。ClickHouse は取り込みノード上で INSERT リクエストをバッファリングしました。BigQuery は、測定対象のパスに Kafka ブローカーやファイル着信ステージを介さず、コミット済みの Storage Write API ストリームを通じて Arrow バッチを受け入れました。

BIGQUERY のストリーミングパス

フル実行構成では、40 本のコミット済みストリーム、明示的な行オフセット、131,000 行のクライアントバッチ、および 16,000,000 バイトのリクエスト制限を使用しました。グローバルレートコントローラーがアペンド開始ペースを毎秒 100 万行に向けて調整しました。Parquet から読み取られた行数ではなく、正常な確認応答(ACK)が進捗を定義しました。

CLICKHOUSE のネイティブパス

async_insert を有効にした通常の INSERT リクエストが、受信側の各ノードでバッファリングされました。適応型フラッシュタイムアウトが受信トラフィックに対応しました。順序付けと事前集約は取り込みノード上で実行され、専用の取り込みサービスは独立してサイズ設定された読み取りサービスとストレージを共有しました。

共通のペーシング

両方のアダプターは同じ Parquet データセットを読み取り、同じ目標レートモデルの下で同じスキーマをデコードしました。並列度とクライアントのバッチサイズは、各送信先の API に合わせて調整されており、強制的に同一にはしていません。

CLICKHOUSE のバッチ

クライアントは非同期挿入を通じて 3,000 行のバッチを送信しました。デフォルトのバッファリングでは、バッファサイズ 100 MiB、50 ミリ秒から 1 秒の間の適応型タイムアウト、または 450 件のキュー内挿入クエリという 3 つのしきい値のうち、最初に達した時点でフラッシュされました。

BIGQUERY のバッチ

各ワーカーは 1 本のコミット済みストリームを所有し、シリアライズされた Arrow レコードバッチを送信しました。これはリアルタイムのストリーミング配信であり、後のロードジョブのためにファイルとして行がアップロードされたわけではありません。保留中ストリーム(pending stream)のバッチコミットは使用されませんでした。

バッチサイズの境界

ClickHouse の 3,000 行と BigQuery の 131,000 行というサイズはクライアント配信の単位です。これらは最終的な MergeTree パートや BigQuery のストレージブロックサイズを規定するものではありません。

リトライと整合性確認

明示的なオフセットにより、BigQuery は確認応答の喪失後に正確なリプレイを検知できます。クライアントの規約では、確認済みのリプレイを 1 回だけカウントして再接続します。これにより、クラッシュからの再開が可能なソースチェックポイントではなく、ライブ実行内での exactly-once のリトライ処理が実現します。クライアントの確認応答、プロバイダーの書き込み成功行数、テーブルメタデータは、明確に区別されたエビデンスとして保持されます。

インクリメンタルなメンテナンス

MV の定義には、アペンド専用ソースに対するサポート対象の COUNT、MIN、MAX、および SUM 操作を使用しました。リフレッシュジョブのエクスポートには、失敗したジョブはなく、362 回の成功した自動リフレッシュジョブが含まれています。リフレッシュのスロット秒数と請求対象バイト数は、ダッシュボードジョブとは独立して記録されます。

レイアウトとパーティショニング

D1 と D2 は時間述語なしで、取り込まれた履歴全体にわたってシンボルでフィルタリングするため、生データテーブルは意図的に非パーティション構成としました。(sym, t) のクラスタリングがそのワークロードに対応します。自動再クラスタリングはマネージド機能であり、個別のコンピュート料金はかかりません。手動の書き換えはベンチマークに追加されませんでした。

BIGQUERY の時系列

鮮度モニターは 1 分に 1 回 refresh_watermark をサンプリングしました。ラグは、そのウォーターマークから観測時までの経過時間です。最初の全行観測までに 1,889 件のアクティブサンプルが含まれ、その後の 441 件のサンプルは除外されています。これはメンテナンスのウォーターマークの尺度であり、結果の陳腐化(staleness)を示すものではありません。

表示と読み取り値

グラフは、完全に観測された各リフレッシュウォーターマークサイクルから測定された最大値を 1 つ選択し、359 件のサイクルピークを生成しています。最初と最後の部分的なサイクルは除外されています。その平均は 4.861 分、最大値は 6.100 分であり、それぞれ 4.9 と 6.1 に丸められています。アクティブな生の全時系列には 8.023 分の起動時ピークが存在しますが、このサイクルピーク表示からは除外されています。読み取り値は表示されている曲線に基づいています。

CLICKHOUSE のベースライン

ゼロの基準線はベンチマークのセマンティクスに基づくベースラインであり、個別にポーリングされたプロバイダーのメトリクスではありません。生データテーブルとインクリメンタル MV はフラッシュされた同じ挿入ブロックを消費し、それらの間に独立した要約リフレッシュの間隔はありません。これは、ソースからクエリまでの取り込み遅延がゼロであることを主張するものではありません。

最新結果の規約

max_staleness が設定されていない場合、マテリアライズドビューへの直接クエリには、MV にまだ反映されていないベーステーブルの変更が含まれます。リフレッシュウォーターマークの遅れは、返される回答が古いことを意味するわけではありません。準備作業の一部がクエリパスに残っていることを意味します。

リフレッシュ規約

1 分のリフレッシュ間隔は頻度の上限(frequency cap)です。自動リフレッシュはベストエフォートであり、負荷がかかると完了頻度が下がることがあります。リフレッシュウォーターマークのラグとクエリレイテンシは個別に測定されます。このベンチマークでは、レイテンシの差のすべてをデルタ処理に帰するものではありません。

コンピュート規約

測定されたジョブは、オンデマンドで動的に割り当てられたスロット上で実行されました。Enterprise Capacity 料金は、測定されたジョブのスロット秒数に対してスロット時間あたり $0.06 を適用します。固定の予約スロットでジョブを再実行したり、測定されたレイテンシを変更したりするものではありません。

オンデマンド規約

もう一方の選択肢では、各ジョブの請求対象バイト数に対して TiB あたり $6.25 を適用します。バイト数とスロット秒数は、異なる料金体系における同一のジョブを表すものであり、それらのコストが合算されることは決してありません。

可視性の境界

コミットされたアペンドが成功すると行がクエリ可能になりますが、テーブルメタデータは後で更新される場合があります。ランナーの進捗シグナルには確認済みの行が使用されます。クエリ可能性、メタデータの更新、クラスタリング、および要約リフレッシュは、明確に区別されたマイルストーンのままです。

クエリの定義

パート 1 で A1〜A4 および D1〜D2 について説明しています。BigQuery SQL は、シンボルフィルター、全履歴の対象範囲、グループ化、順序付け、および LIMIT を維持しています。D2 は母中心モーメントとパーセンタイル用の APPROX_QUANTILES を使用しています。このパーセンタイルアルゴリズムは ClickHouse の quantilesTDigest と異なるため、許容範囲に基づいた比較が必要です。

キャッシュポリシー

クエリ結果のキャッシュは、use_query_cache=False で無効化されました。基礎となるデータキャッシュは正常に動作することが許可されており、クエリ間でフラッシュされることはありませんでした。

タイミング

BigQuery のレイテンシは、完了したジョブの finalExecutionDurationMs を 1,000 で割った値です。ClickHouse は記録されたランナーの所要時間を使用します。中央値、P99、および最大値は、0 < raw_rows ≤ 1,000 億 の平滑化されていないクエリごとの観測値をプールします。P99 は線形補間を使用します。記録されたタイミングの慣例は、累積実行時間にも引き継がれます。

レイテンシグラフ

各システムは、観測された自身の取り込み進捗の位置にプロットされています。集約トレンドには中央寄せの 7 観測値の移動中央値を使用し、ドリルダウンには端のウィンドウを狭めた 5 観測値を使用しています。外れ値は除外されていません。曲線は表示用の平滑化であり、統計と累積合計には記録された元の所要時間を使用しています。

インタラクティブな読み取り値

プロットの下の値は、選択された行数における表示トレンドに沿ったものです。対数スケールによりミリ秒と秒を一緒に読み取れるように維持し、線形スケールでは絶対的な差を示します。各グラフには独自の再生および行位置のコントロールがあります。

受け入れられた累積ワークロード

抽出データには、システムごとに 190 回の 4 クエリ集約バッチと 33 回の 2 クエリドリルダウンバッチが含まれており、760 + 66 = 826 回の実行となります。ClickHouse の観測値は、113,219,565,734 行の参照範囲を通じて BigQuery の行進捗と揃えられています。初期の観測値が存在する場合は維持され、取り込み完了後の遅い観測値は除外されています。

累積グラフ

クエリ所要時間は、将来の実行を前の位置に平滑化または補間することなく、対応する取り込みカウントの位置でステップ合計として加算されます。準備コストの線は、取り込み全体の合計を行の進捗に応じて比例配分したものであり、時間ごとの課金コストを追跡したものではありません。スコアはクエリ所要時間を合算したものであり、取り込みの経過時間ではありません。