共通のテスト基盤
両システムとも、同じソースデータセット、スキーマ、ワークロード定義、ペーシングモデル、クエリスケジュール、結果フォーマットを使用しました。送信先固有のアダプターが配信とタイミングを処理しました。パート 1 で共通の手法を説明しており、Databricks ベンチマーク規約に本プロバイダーの実装が記録されています。
データセットと準備
完全な NBBO データセットには、113,219,565,734 行の幅の狭い 12 カラムのデータが含まれています。生テーブルには (sym, t) (銘柄記号とイベントタイムスタンプ) を使用し、日次サマリーには (sym, day) (銘柄記号と UTC 日) を使用しました。サマリーには、集計クエリで使用される件数、合計、価格の最小値と最大値が保持されました。
継続的なワークロード
集計クエリとドリルダウンクエリが 10 分および 1 時間のスケジュールで実行される間、新鮮な行は毎秒 100 万行を目指してペース調整されました。これは、既存のデータセットをどれだけ迅速に一括ロードまたはバックフィルできるかを測定するのではなく、データが継続的に生成され、届いたそばから準備される様子をモデル化しています。Databricks の MV パスはネイティブのスナップショットセマンティクスを維持したため、取り込みの進行状況を揃えても、両システムのサマリーの新鮮さが同一になるわけではありません。
推奨構成とサイジング
ClickHouse Cloud は 16 CPU、64 GiB の読み取りノードを使用しました。Databricks は 1 クラスターに固定された X-Small Serverless SQL ウェアハウス (約 16 ワーカー vCPU) を使用しました。このサイジングは同一のハードウェアやメモリを意味するものではありません。Liquid クラスタリング、Predictive Optimization、およびトリガー方式のインクリメンタル MV リフレッシュが有効化されました。テストワークスペースでは Lakehouse//RT が利用できなかったため、採用された比較では Serverless SQL ベースラインを使用しています。
① 準備コスト
完全な取り込みには、ClickHouse の完全な 2 ノード HA 取り込みサービスと、Databricks の Zerobus 取り込み、非同期クラスタリング、MV リフレッシュが含まれます。Databricks の取り込みとリフレッシュには割り当てられた DBU 使用量が使用され、クラスタリングには採用された Predictive Optimization DBU 割り当てが使用されます。3 つすべてが準備コストモデルに記載されています。
② クエリコストと ③ 実行時間
採用された各クエリの記録された所要時間は、読み取り側コンピュート料金で価格換算され、累積実行時間に加算されます。Databricks は結果取得を除いたクエリ履歴の合計所要時間を使用し、ClickHouse は記録されたランナー所要時間を使用します。これらの正規化コストは、採用されたクエリ作業を表しており、ウェアハウスの請求額全体ではありません。以下のクエリ比較と価格設定の注記に、タイミングと境界の詳細が記載されています。
目標レートと実測レート
Databricks は、約 31.5 時間で永続的取り込みウィンドウを完了し、平均約 100 万行/秒を記録しました。ClickHouse は約 36.75 時間で取り込みを完了し、平均約 86 万行/秒を記録しました。目標は共通でしたが、観測された進捗は異なりました。Databricks の最終照合により、重複する余剰分なしに 113,219,565,734 行すべてが確認されました。耐久性の確認とテーブルクエリの可視性は別のマイルストーンです。
レポーティング対象期間
クエリごとのレイテンシグラフは 1,000 億行で終了します。準備コストはアクティブな取り込み全体を対象とし、累積クエリコストと実行時間は、各ワークロードの共通の比較終了地点までの採用されたアクティブ取り込み時の観測値を使用します。取り込み後のクエリとメンテナンスは、ヘッドラインスコアの対象外です。表示されている合計値は四捨五入されています。
料金基準
ClickHouse Cloud は、コンピュートユニット (CU) あたり 1 時間 0.3903 ドルを使用します。Databricks は、AWS eu-west-1、Premium のリポジトリ登録済み公開定価を使用しています。割り当てられた取り込みとメンテナンスは 1 DBU あたり 0.39 ドル、Serverless SQL は 1 DBU あたり 0.91 ドルです。採用されたサマリーは完全な精度を保持しています。これらは定価に基づくモデルコストであり、過去の請求書の再構築ではありません。
① 完全な準備コスト
これは、必要な準備コンポーネントを含む、全 113,219,565,734 行のアクティブな取り込みを対象としています。
CLICKHOUSE CLOUD
両方の HA 取り込みノードを含めて、2 CU × 36.75 時間 × 0.3903 ドル/CU 時 = 28.68705 ドルです。
DATABRICKS の取り込み
割り当てられた Zerobus 使用量は、1,098.9261167 DBU × 0.39 ドル = 428.58119 ドルです。ソースのバイト量を料金のプロキシに変換するのではなく、この採用された DBU 割り当てをヘッドラインで使用しています。
DATABRICKS のクラスタリング
Predictive Optimization の割り当てには、151.8613011 DBU × 0.39 ドル = 59.22591 ドルが含まれます。このコンポーネントは、Predictive Optimization の操作レベルの DBU 割り当てを使用します。これは請求金額ではなく、モデル化されたメンテナンス費用です。
DATABRICKS の MV リフレッシュ
532.8145064 割り当て DBU × 0.39 ドル = 207.79766 ドルです。取り込み、クラスタリング、リフレッシュを合わせると、採用された準備モデルでは合計 695.60475 ドルになります。
② 正規化クエリコスト
採用された各クエリの記録された所要時間に、秒あたりの読み取り側コンピュート料金を掛けます。これは採用された作業をモデル化したものであり、アイドル容量やウェアハウスの最低請求額は除外されています。
CLICKHOUSE CLOUD
8 CU × 0.3903 ドル/CU 時 × (集計 10.312 秒 + ドリルダウン 46.074 秒) ÷ 3,600 = 0.04890 ドルです。
DATABRICKS SERVERLESS SQL
X-Small の料金は、6 DBU/時 × 0.91 ドル/DBU = 5.46 ドル/時です。集計作業: 613.164 秒 × 5.46 ドル/時 ÷ 3,600 = 0.92997 ドルです。
DATABRICKS のドリルダウン作業
1,133.002 秒 × 5.46 ドル/時 ÷ 3,600 = 1.71839 ドルです。正規化クエリコストの合計は 2.64835 ドルです。
割り当ての境界
Databricks の取り込みとメンテナンスは、2026-09-18 17:04:53 UTC から 2026-09-20 00:33:42.627 UTC までのプロデューサー稼働ウィンドウ (終了時刻は含まず) に割り当てられます。取り込み後のメンテナンス、検証/制御 SQL、データベースストレージ、プロデューサーインフラストラクチャ、ネットワーク料金、およびアイドル時/最低ウェアハウス料金は除外されます。取り込み後にもメンテナンスが観察されましたが、その後の作業はこのスコアには請求されません。
③ 累積クエリ実行時間
ClickHouse: 集計 10.312 秒 + ドリルダウン 46.074 秒 = 56.386 秒。Databricks: 集計 613.164 秒 + ドリルダウン 1,133.002 秒 = 1,746.166 秒。
比較の境界
① はアクティブな取り込み全体をカバーします。② と ③ は、189 回の 4 クエリ集計バッチと 32 回の 2 クエリドリルダウンバッチを使用します。これらの行数比較対象期間は、1,000 億行のレイテンシプロットとは異なります。耐久性の整合は、クエリで可視な行や MV の新鮮さが同一であることを示すものではありません。これはモデル化された完全な準備パスと正規化クエリ作業であり、プロバイダーの請求額全体ではありません。
最終スコア
ClickHouse: (28.68705 ドル + 0.04890 ドル) × 56.386 = 1,620.30528。Databricks: (695.60475 ドル + 2.64835 ドル) × 1,746.166 = 1,219,265.82646。全精度の入力値を使用した比率は 752.491 倍となり、四捨五入して 752 倍となります。
ClickHouse のライター使用率の結果は、バックグラウンドのメンテナンスタスクと並行して取り込みが継続していることを示しています。CPU 使用率は利用可能な 4 コア中約 3.1 コアにとどまり、追跡されたメモリは許容量の範囲内に収まり、バックグラウンドマージは毎秒数百万行を処理し、パーティションあたりの最大アクティブパート数は約 100 を維持しました。これらの診断情報は、この比較で再利用された ClickHouse のソース実行のものです。
高可用性を維持するために両方のノードが保持されたため、準備コストには完全な 2 ノード構成のデプロイが含まれています。
同一の取り込み課題
アプリケーションは頻繁な書き込みを発生させ、それを効率的なストレージへの書き込みに変換する必要があります。どちらの移行先も、マネージドバッファリングを備えた直接の「アプリケーションからテーブルへ」の取り込みを使用しました。測定対象のパスには、Kafka ブローカー、ファイルランディングステージ、Auto Loader ジョブなどは追加されていません。
DATABRICKS のマネージドパス
採用されたランナーは、Zerobus Arrow Flight DoPut インターフェースを使用し、16 の同時実行ストリームと 50,000 行のクライアントバッチを使用しました。ストリームは 10 分ごとにローテーションされ、SDK のリカバリと有界リトライが有効化されました。Zerobus の取り込みコンピュートは、クラスタリング、MV のリフレッシュ、SQL サービスとは個別に割り当てられ、価格設定されました。
CLICKHOUSE のネイティブパス
async_insert が有効化された通常の INSERT リクエストは、受信側の各ノードでバッファリングされました。適応型フラッシュタイムアウトが、受信トラフィックに応じて応答しました。並べ替えと事前集計は取り込みノード上で実行され、専用の取り込みサービスは、個別にサイジングされた読み取りサービスとストレージを共有しました。
共通のペース調整
両方のアダプターは同一の Parquet データセットを読み取り、同一の目標レートモデルのもとで同一のスキーマをデコードしました。並列度とクライアントのバッチサイズは各移行先の API に適合させたものであり、強制的に同一にはしていません。
CLICKHOUSE のバッチ
クライアントは非同期挿入を通じて 3,000 行のバッチを送信しました。デフォルトのバッファリングは、3 つのしきい値(100 MiB のバッファ蓄積、50 ミリ秒〜1 秒の間の適応型タイムアウト、または 450 件のキューイングされた挿入クエリ)のいずれかに最初に達した時点でフラッシュされました。
DATABRICKS のバッチ
各 Arrow Flight ストリームは、IPC 圧縮を無効にして 50,000 行のバッチを送信しました。目標レートは論理ソース行に基づいており、確認応答された永続的な進捗状況は、テーブルでの可視性とは個別に記録されました。それらのバッチは、後からのバルクロードのためにファイルとしてステージングされたものではありません。
バッチサイズの境界
これらはクライアントの配信バッチサイズです。両システムとも配信をストレージへの書き込みへとバッファリングするため、3,000 行や 50,000 行という数値は、最終的なパートや Parquet ファイルのサイズを指定するものではありません。
リトライと整合性確認
Zerobus は永続的なストリームオフセットと SDK リカバリを使用しました。確定後の検証により、正確な行の整合性が確認され、余分な重複がないことが確認されました。ClickHouse は、依存するマテリアライズドビューを含め、リトライに対する挿入の重複排除をサポートしています。最終的な行チェックは配信を検証するものであり、取り込み中のサマリーの鮮度が同等であることを検証するものではありません。
インクリメンタルメンテナンス
生の Delta テーブルは、行の追跡、チェンジデータフィード、削除ベクターを有効にしました。MV はインクリメンタル処理の適格性チェックに合格し、INCREMENTAL STRICT を使用しました。リフレッシュのエビデンスには、収集された実行全体(取り込み後の観察期間を含む)で、1,028 回のインクリメンタルなグループ集計リフレッシュが記録され、フルリフレッシュは 0 回でした。
テストされた構成
サービング層は Serverless SQL X-Small でした。Lakehouse//RT はワークスペースで利用できなかったため、テストされませんでした。この記事では、利用できないサービング製品のパフォーマンスを予測するのではなく、採用された構成とその結果について説明します。
DATABRICKS の系列
鮮度の履歴は 1 分ごとにポーリングされました。プロットされたメトリクスは、明確に観察された完了リフレッシュ ID 間の時間です(floor(現在の completed_at − 直前の観察された completed_at)、単位は秒)。選択されたアクティブ取り込みのエビデンスには、このような間隔が 1,021 個含まれています。高密度のポーリングでは、途中の完了を見落とす可能性があります。
平滑化と読み取り値
中央揃えの 61 観測ローリング平均は、間隔の観測全体で平均約 1.8 分となります。さらに 11 観測の表示用平均と形状を保持する補間により、プロットされたピークは約 2.0 分になります。読み取り値はその表示された曲線に沿っています。これはリフレッシュ間隔のプロキシ(代替指標)であり、直接ポーリングされた生データと MV 間のウォーターマーク遅延や、クエリごとの古い行数ではありません。
CLICKHOUSE のベースライン
ゼロのラインはベンチマークのセマンティクス上のベースラインであり、個別にポーリングされたプロバイダーのメトリクスではありません。生テーブルとインクリメンタル MV は、同一のフラッシュされた挿入ブロックを消費するため、それらの間に独立したサマリーリフレッシュ間隔はありません。これは、ソースからクエリまでの取り込み遅延がゼロであると主張するものではありません。
Lakehouse//RT は現在ベータ版です。アクセスをリクエストしていますが、まだ付与されていません。
Lakehouse//RT が一般提供(GA)され、アクセスできるようになり次第、Lakehouse//RT でクエリを処理する完全な CostBench ワークロードを再度実行し、その結果を公開する予定です。
スナップショットの契約
リフレッシュは、ソーステーブルから MV を更新します。測定された集計クエリは、そのマテリアライズされた結果を直接読み取りました。各クエリの前に同期リフレッシュを強制したり、生テーブルの差分を結果にマージしたりはしていません。したがって、測定されたレイテンシには、サマリーが古くなることを許容する Databricks のネイティブな仕様が含まれています。
トリガーの契約
TRIGGER ON UPDATE は、アップストリームのデータが変更されたときにリフレッシュをスケジュールします。AT MOST EVERY INTERVAL 1 MINUTE はトリガー間の最小間隔を課すものであり、データの古さやリフレッシュ完了に対する 1 分の最大制限ではありません。
インクリメンタルの契約
INCREMENTAL STRICT はメンテナンス方法を制御します。対象となる変更は、暗黙のうちにフル再構築にフォールバックすることなく、インクリメンタルに処理されます。これは、MV の可視性を取り込まれた各ブロックに結び付けたり、MV を継続的に最新に保ったりするものではありません。
可視性の契約
ランナーの raw_rows は、確認応答された永続的な取り込みの進捗を記録します。Zerobus は、行が Delta テーブルに公開される前に、行を永続的に受け入れることができます。したがって、永続的な取り込みの進捗によって揃えられたクエリのペアは、両方のクエリがまったく同じ生の行数や、同様に新鮮なサマリースナップショットを見たことの証明にはなりません。
比較の境界
ヘッドラインの結果は、その鮮度の挙動を含め、テストされた MV サービングパスをそのまま維持しています。リフレッシュを強制したり、生テーブルをクエリして再集計したりするような設計は、レイテンシとコストのプロファイルが異なってきます。その作業はこの結果には含まれていません。
クエリの定義
パート 1 で A1〜A4 および D1〜D2 について説明しています。両システムとも同じ分析ワークロードとスケジュールを使用し、SQL は各エンジンに合わせて調整されました。カウント、合計、極値は厳密に比較されました。D2 の近似パーセンタイル部分には、契約の明示的な許容差が使用されました。MV の鮮度は同一であるとは想定されていません。
キャッシュポリシー
クエリ結果のキャッシングは無効にされました。Databricks のコンパクトなクエリエビデンスでは、採用されたクエリに対する結果キャッシュのヒットは報告されませんでした。基礎となるデータキャッシュは通常通りウォームアップすることが許可され、ベンチマークではクエリ間でキャッシュをフラッシュしませんでした。
計測方法
Databricks のレイテンシは、結果の取得時間を除いた Query History の total_duration_ms ÷ 1,000 を使用しています。ClickHouse は記録されたクエリ実行時間を使用します。これらの時間計測の慣例は、正規化されたクエリコストにも引き継がれます。中央値、P99、最大値の統計は、1,000 億行までの平滑化されていないクエリごとの観測値をプールしたもので、P99 には線形補間が使用されています。
レイテンシのグラフ
各システムは、それぞれが観測した取り込みの進捗に合わせてプロットされています。集計の傾向線には中央揃えの 7 観測ローリング中央値を使用し、ドリルダウンには端のウィンドウを縮小させた 5 観測値を使用しています。外れ値は除去されていません。曲線は表示上の平滑化であり、統計と累積合計には記録された元の実行時間が使用されています。
インタラクティブな読み取り値
プロットの下の値は、選択された行数における表示された傾向線に従っています。対数スケールによりミリ秒と秒を一緒に読みやすくしており、線形スケールは絶対的な差異を示します。各グラフには独自の再生コントロールと行位置コントロールがあります。
採用された累積ワークロード
採用されたデータセットには、システムあたり 189 回の 4 クエリ集計バッチと 32 回の 2 クエリドリルダウンバッチが含まれており、756 + 64 = 820 回の実行となります。ClickHouse の観測値は、Databricks の永続性の進捗(集計では 1,128 億 4,900 万行まで、ドリルダウンでは 1,116 億 4,900 万行まで)に揃えられました。最初の完全データセット観測値と、その後の取り込み後のサンプルは除外されています。
累積グラフ
クエリの実行時間は、対応する取り込み件数におけるステップ合計として加算され、将来の実行を前の位置に平滑化したり補間したりすることはありません。準備コストの線は、完全な取り込みの合計を行の進捗に応じて比例配分したものであり、時間ごとの従量課金コストの推移ではありません。スコアは取り込みの経過時間ではなく、クエリの実行時間を合計したものです。