5万
TL;DR
リアルタイム分析システムにおいて、最新の応答を高速に返し続けるには、最新データを処理する効率的な経路が欠かせません。CostBench では、ClickHouse Cloud と Snowflake の両環境で 1,132 億行の株式市場クオートデータを取り込みながら、同一の継続的なクエリワークロードを実行して比較しました。
-
ClickHouse Cloud は、取り込み、ソート、事前集約をストレージエンジンに統合しています。 個別のリフレッシュサイクルを介さずに生データと集約結果の同期が維持されるため、クエリ側に未完了の事前準備処理の負担がかかりません。
-
Snowflake の取り込みと事前集約は、それぞれ独立したサービスとして進行します。 事前準備が遅延すると、最新の結果を得るためにクエリ実行時の追加処理が必要になります。その回避策は、鮮度、レイテンシ、インフラ、コストの間でトレードオフを招きます。
-
ClickHouse Cloud は、検証対象の Snowflake 構成に対して 412 倍優れたエンドツーエンドのリアルタイムコストパフォーマンスを達成しました。 低コストな最新データ経路と高速なクエリ性能を両立しています。
412 倍の差はどこから生じるのか
パート 1 では、最新データパス が 1 ドルあたりの性能に 2 度 影響を与えることを示しました。新しいデータを クエリ可能な状態 にするための直接的なコストが発生することに加え、クエリエンジン側に残される作業量もこのパスによって決まります。
パート 2 では、ClickHouse Cloud と Snowflake におけるこれら 2 つの影響を検証します。両システムで推奨されているリアルタイムコンポーネントを使用し、同一の株式市場クオートデータ 1,132 億行を毎秒 100 万行のペースで取り込みました。また、取り込みの実行中には同一の集計クエリおよびドリルダウンクエリを実行し続けました。
取り込み、継続的なデータ準備、そしてクエリ処理は並行して実行されます。以下のインタラクティブな図は、データ準備がクエリ側に残る作業量にどのように影響するかを示しています。ループを確認するかスライダーをドラッグしてみてください。ソートと事前集計が追いつくほど、クエリエンジンが行うスキャンや集計の作業量は少なくなります。一方、データ準備が遅れるとそれらの作業量が増大し、クエリレイテンシとコストが上昇します。
この一連の動作ループ全体が比較の境界となります。両システムは同一のストリーム、スキーマ、クエリワークロード、および実行スケジュールを受け取りました。
生データと日次事前集計の双方について、両システム間で一致するソートキーまたはクラスタリングキーを設定しました。これらのレイアウトは、ワークロードに含まれる銘柄コード(ティッカーシンボル)のフィルター処理を支えます。事前集計では見積もりデータを銘柄コードと日付ごとにグループ化し、集計クエリで使用する件数、合計値、価格の最小値・最大値を維持します。したがって各システムは、新しい行が届くたびに、同じクエリワークロードに向けて同じ事前処理を最新状態に保つ必要がありました。
クエリ処理用のコンピュートはおよそ 16 CPU で揃え、各システムは推奨アーキテクチャと従量課金される最新データパス全体を維持しました。
ベンチマークの方法と構成の詳細(クリックして展開)
共通のテスト基盤
両システムの実行には、同一のソースファイル、スキーマ、行デコードロジック、ワークロード生成コード、クライアントホスト(AWS EC2 m6i.8xlarge)、レートコントローラー、スケジューラー、タイミング測定、結果記録ロジックを使用しました。変更したのは宛先固有の配信アダプターのみです。共通手法の全体はこちらで確認できます。
一括ロードではなくリアルタイム処理
CostBench は、ソース側で継続的に新しいデータが生成され、届いたデータが即座にクエリ可能な状態になるリアルタイム分析システムをシミュレートしています。そのため本テスト基盤は、既存データの一括ロードやバックフィルではなく、ペース調整された継続的なデータ取り込みをモデル化しています。
データセットとレイアウト
両システムは、12 カラムのナローな行で構成される合計 1,132 億行の同一の NBBO 株式市場データセットを受け取りました。
両システムでは、以下のソートキーまたはクラスタリングキーを使用しました。
-
イベントレベルのデータ:
(sym, t)— 銘柄コードとイベントのタイムスタンプ。 -
日次事前集計:
(sym, day)— 銘柄コードと日付。
ワークロードとクエリスケジュール
テスト基盤は、毎秒 100 万行を目標レートとしてソースを 1 つの連続ストリームとして再生しました。取り込み開始から最後の行に至るまで、同じ 4 つの対話型集計クエリを 10 分ごと、同じ 2 つの選択的なドリルダウンクエリを 1 時間ごとに実行しました。
リソースサイジング方針
クエリ処理用コンピュートは、各プラットフォームで可能な限り近づけました。ClickHouse Cloud は 16 CPU・64 GiB メモリのリードノード 1 台を使用しました。Snowflake は Small Interactive Warehouse と Gen2 Small フォールバックウェアハウスを使用しました。Snowflake は CPU 数を公開していないため、これらはそれぞれ約 16 CPU と推定されています。この推定は SELECT.dev および第三者による Gen2 の検証に基づいています。取り込みについて、ClickHouse はキャリブレーション時に目標レートを維持できた最小の高可用性構成(各 2 CPU のノード 2 台)を使用し、Snowpipe Streaming と Interactive MV の更新は個別に課金されるサーバーレスサービスとして実行されました。それらの測定された作業全体は、Snowflake の最新データパスのコストに含まれています。
4 CPU コアでの完全な最新データパス
ライターの使用率結果は、2 ノードの取り込みサービスが継続的な取り込みとバックグラウンドメンテナンスをどのように処理したかを示しています。バックグラウンドのマージは毎秒数百万行を処理し、パーティションごとのアクティブパートの最大数は約 100 件にとどまりました。CPU 使用率はサービスで利用可能な 4 コア中約 3.1 コアで推移し、余力を保ちつつ継続的に利用されていることが示されました。追跡されたメモリ使用量もサービスの容量内に収まりました。
高可用性のために 2 つのノードを維持したため、報告されている取り込みコストには HA デプロイの双方のノードが含まれています。
ベストプラクティスに基づくプラットフォーム構成
各プラットフォームの最新データパスは、届いたデータをクエリ可能な状態に保つための、ベンダー推奨の低レイテンシコンポーネントと文書化されたベストプラクティスを用いて構成しました。それらのパスの違いも本ベンチマークの対象です。
実行とレポートの範囲
分かりやすさのため、以下の大半のグラフでは 1,000 億行到達時点までの結果を示しています。ベンチマーク自体は 1,132 億行のデータセット全体が両システムに取り込まれるまで継続され、コスト計算にはその完全な取り込みが含まれます。
目標レートと実測レート
毎秒 100 万行の目標レートでは、1,000 億行の取り込みにおよそ 28 時間かかります。クライアント側のペース調整、並列取り込みストリーム、バッチサイズ設定によって正確なエンドツーエンドのレートを目指したものの、それを保証することはできず、1 日を超える実行中に変動が生じるのは正常です。実測スループットの平均は、ClickHouse が毎秒約 86 万行、Snowflake が毎秒約 90 万行でした。したがって、ClickHouse は約 32 時間後に 1,000 億行に到達し、約 37 時間後に 1,132 億行のデータセットを完了しました。Snowflake は約 31 時間後に 1,000 億行に到達し、約 35 時間後にデータセットを完了しました。
各システムを取り巻くワークロードを一定に保ったところで、両者のアーキテクチャ内部の比較に移ります。
最新データパスのアーキテクチャ
今回の CostBench ではプッシュ型の取り込みを採用しました。共通のクライアントが、ペース調整された同一のストリームを各システム推奨の低レイテンシ取り込みパス経由で送信しました。Snowflake の場合は Snowpipe Streaming、ClickHouse Cloud の場合はネイティブの非同期挿入です。
なぜ SNOWPIPE STREAMING と CLICKHOUSE の非同期挿入を比較するのか？(クリックして展開)
同一の取り込み課題
オブザーバビリティ、エンドユーザー向けアプリケーション、IoT、不正検知、分析エージェントをはじめとするリアルタイムアプリケーションでは、多数のクライアントから小さく頻繁な書き込みが頻発します。取り込みパスはそれらの書き込みを継続的に受け入れ、効率的なストレージへの書き込みへと集約しなければなりません。Snowpipe Streaming と ClickHouse の非同期挿入は、いずれもこの目的のためにサーバー側バッファリングを提供します。
SNOWFLAKE: フルマネージドの取り込みサービス
Snowpipe Streaming を使用すると、アプリケーションはステージングファイルを自ら管理することなく行を送信できます。ここで使用した高性能アーキテクチャでは、クライアントが PIPE オブジェクトに対してチャネルを開きます。Snowflake の取り込みサービスは、対象テーブルに行をコミットする前に、バッファリング、スキーマ検証、設定された変換、およびオプションの事前クラスタリングを処理します。Snowflake が取り込みコンピュートを管理およびスケールし、取り込み料金は非圧縮データ量に応じて個別に請求されます。
CLICKHOUSE: エンジン内での取り込み
アプリケーションは async_insert を有効にした通常の INSERT リクエストを送信します。受信側の各ノードは適合するリクエストをバッファリングし、受信トラフィックに応じて変化する適応型フラッシュタイムアウトによって、それらをより大きな書き込みに集約します。この機能は、オープンソースの ClickHouse と ClickHouse Cloud の双方に標準で備わっています。
エンジンは取り込み中に順序付けや変換も行います。受信ノードは、データパートを書き込む際に、書き込み先となる各 MergeTree ファミリーテーブルのソートキーに従って受信行をソートします。受信データは、何かがストレージに保存される前の挿入パス上で、フィルター処理、ルーティング、エンリッチメント(辞書参照、UDF)、再形成を行うことができます。これらの処理は、挿入を受信したノード上で実行されます。
ClickHouse Cloud では、保存された同一データを共有しながら、クエリを処理するサービスとは独立してコンピュートがスケールする専用サービス上でデータ取り込みを実行できます。
リトライとリカバリ
Snowpipe Streaming のオフセットトークンは、チャネルごとにコミット済みのソースの進行状況を記録します。再起動後、アプリケーションは最後にコミットされたトークンを取得してソースと照合し、次のレコードから再開する必要があります。Snowflake の Kafka コネクタは、Kafka パーティションに対してこのマッピングを実行します。カスタムアプリケーションの場合、そのリカバリロジックはアプリケーション側で実装する必要があり、オフセットトークン自体がコミット済みの行の再送を安全にするわけではありません。
ClickHouse は、挿入の重複排除を通じて冪等なリトライをサポートしています。同一データを伴うリトライ挿入はサーバー側で検出・破棄されます(同期挿入および非同期挿入で重複排除され、依存するマテリアライズドビューも含まれます)。クラッシュや確認応答(ACK)の喪失後もオフセット管理は不要で、クライアントは直近のバッチを再送するだけでよく、ClickHouse がすでに書き込み済みのデータを無視します。
CLICKPIPES の位置付け
ClickPipes は、Kafka、オブジェクトストレージ、Postgres などの外部ソースからの取り込みを管理します。したがって、適切な比較はデータの発生元によって決まります。
- 行を直接プッシュするアプリケーション: Snowpipe Streaming と ClickHouse ネイティブの非同期挿入(今回のベンチマーク対象)。
- Kafka トピック: Snowflake Kafka コネクタ付き Snowpipe Streaming と Kafka 向け ClickPipes。
- オブジェクトストレージ内のファイル: 従来の Snowpipe と Object Storage 向け ClickPipes。
後者の組み合わせは、外部ソースからデータを取り込む完全な統合同士の比較となります。本ベンチマークでは、アプリケーションからテーブルへの直接パスを測定しています。
まずは ClickHouse Cloud から始め、受信した行からクエリ可能なイベントレベルおよび事前集計データに至るまでの最新データパスを追っていきます。
ストリームの取り込み - ClickHouse Cloud
ベンチマークでは、高可用性のために 2 台の 2 CPU ノードを備えた専用の ClickHouse Cloud 取り込みサービスを使用しました。これは、キャリブレーション中に目標を維持できた最小の HA 構成です。共有クライアントは、エンジンに組み込まれた非同期挿入を通じて行を送信しました。
これら同じ 2 台のノードがソート、インクリメンタルな事前集計、バックグラウンドマージも処理し、完全な最新データパスを合計わずか 4 つの CPU コアで実行しました。
データをクエリ可能な状態に維持 - ClickHouse Cloud
これら 2 つの取り込みノードのいずれかが非同期挿入バッファをフラッシュすると、イベントレベルの行がターゲット MergeTree テーブルの (sym, t) ソートキーでソートされ、順序付けられたデータパートが書き込まれます。
並行して、同じノードがメモリ内のそのブロックに対してインクリメンタルなマテリアライズドビューのクエリを実行し、集計状態を計算し、生成された行をターゲットの AggregatingMergeTree テーブルの (sym, day) ソートキーでソートして、事前集計データを含む順序付けられたパートを書き込みます。
バックグラウンドマージによって両方のテーブルのパートが統合されます。どちらの書き込みパスも同じフラッシュされた挿入ブロックを処理し、取り込み時に順序付けと事前集計が行われるため、別個のリフレッシュサイクルは不要です。
結果として、未加工データと事前集計の同期が維持されます。 両者は同じフラッシュされた挿入ブロックから処理を進めるため、両者の間に別個のリフレッシュサイクルは存在しません。
次に、Snowflake での同じ 2 つのステージを見ていきます。Snowflake では、取り込みとマテリアライズドビューのリフレッシュが別々のサービスに分かれています。
ストリームの取り込み - Snowflake
本ベンチマークでは、Snowpipe Streaming のハイパフォーマンスアーキテクチャを使用しました。これは、アプリケーションによる書き込みと Interactive Table の間にマネージドなサーバー側取り込みバッファを配置します。
データをクエリ可能な状態に維持する - Snowflake
Snowpipe Streaming は、行を Interactive Table へ直接書き込みます。CLUSTER_AT_INGEST_TIME=TRUE を設定すると、Snowflake の列指向ストレージ単位であるマイクロパーティションへ書き込む前に、共通の (sym, t) キーで受信行をあらかじめクラスタリングします。
Interactive Table にはストレージのトレードオフが伴います。以前の調査では、約 1,130 億行の時点で、Snowflake の未加工 Interactive Table の専有容量は 2.9 TiB でした。これに対し、Snowflake の標準テーブルは 701 GiB、ClickHouse の未加工テーブルは 362 GiB であり、それぞれ約 4 倍と 8 倍のストレージを消費していました。これらの測定値は以前の構成によるものです。
独立した Snowflake 管理のサーバーレスサービスが、そのテーブルから非同期に Interactive MV をリフレッシュします。このビューには、ClickHouse の事前集計テーブルのソートキーと一致する (sym, day) クラスタリングキーを設定しました。リフレッシュを実行するタイミングと使用するコンピュート量は Snowflake 側で制御され、ユーザー側でリフレッシュスケジュールを設定したり、リフレッシュ用コンピュートのサイズを指定したりすることはできません。
その結果、未加工データと事前集計データの同期がずれる可能性があります。 Interactive Table は取り込みに伴って進むのに対し、Interactive MV は独立した非同期リフレッシュサイクルに沿って進むためです。
内部の仕組み:両システムを毎秒 100 万行へペース調整する手法(クリックして展開)
共通クライアントとレート制御
両取り込み先とも、同一の Parquet ソース、行デコーダー、クライアント側コンピュート、ペース制御ロジック、および 8 ワーカーの並列処理を使用しました。共通のレートコントローラーが、毎秒 100 万行に向けてストリームのペースを制御しました。変更したのは配信アダプターと取り込み先固有のバッチ処理のみです。
CLICKHOUSE CLOUD
クライアントは、非同期挿入を介して 3,000 行のバッチを送信しました。受信した各ノードは、サーバー側のバッファにこれらのリクエストを蓄積しました。
ベンチマークでは、実行時に使用されたデフォルトのバッファ設定を維持しました。バッファが 100 MiB に達する、50 ミリ秒から 1 秒のアダプティブタイムアウトに達する、キュー内の INSERT クエリが 450 件に達する、という 3 つのしきい値のうち最初に到達した時点でフラッシュが実行されました。
SNOWFLAKE
クライアントは、ワーカーごとに 1 つの Snowpipe Streaming チャネル経由で append_row を呼び出しました。SDK はファイルモードを選択し、それらの行単位の呼び出しをクライアント側で平均約 61,500 行の NDJSON バッチにまとめました。
8 チャネル全体で、これにより毎秒約 14.6 回のファイルアップロードが発生しました。その後、Snowpipe Streaming は行をコミットする前に、アップロードされたバッチをサーバー側で再度バッファリングしました。
これらのバッチサイズの読み解き方
3,000 行および約 61,500 行という数値は、クライアント側の配信バッチを示しています。どちらのシステムもサーバー側でさらにバッファリングを行うため、いずれの数値も最終的なストレージへの書き込みサイズを直接表すものではありません。
クエリ提供アーキテクチャ
読み取り側が受け取るのは、こうしたそれぞれ異なる「クエリ可能な状態」です。ClickHouse Cloud は、1 つの 16 CPU 読み取りサービスから両方のワークロードを処理します。一方、Snowflake はほぼ同等の構成となる Small Interactive Warehouse を使用し、その周囲で個別のコンパイルとフォールバック動作を伴います。
読み取り側のコンピュート - ClickHouse Cloud
サイジング: 読み取りサービスには、Snowflake の Small ウェアハウスの推定 CPU 数に合わせた、16 CPU・64 GiB メモリのノード 1 台を使用しました。
サービングモデル: この単一サービスで両方のワークロードを処理しました。集計クエリは常に最新の AggregatingMergeTree テーブルを読み取ります。このテーブルは 生の MergeTree テーブル と同じフラッシュされた挿入ブロックによって更新されるため、最新の結果を得るためのクエリ時リコンサイルは不要です。ドリルダウンクエリはイベントレベルの MergeTree テーブルを読み取ります。
同様の処理パスは Snowflake のサービングレイヤーも経由しますが、そこでは Interactive Warehouse を中心としたコンパイルやフォールバックの挙動が加わります。
読み取り側のコンピュート - Snowflake
サイジング: Snowflake はウェアハウスの CPU やメモリを公開していません。SELECT.dev と Gen2 に関する独自の調査に基づき、Small の Interactive Warehouse を ClickHouse Cloud の 16 CPU 読み取りサービスと同等の約 16 CPU と推定しました。また、Snowflake のドキュメントでは、このサイズに対して約 600 GB の ローカル SSD キャッシュが記載されています。
提供モデル: 両ワークロードのプライマリサービスとして Interactive Warehouse を使用しました。集計クエリは Interactive MV を対象としました。前述のとおり、Snowflake はこのビューを非同期で更新するため、Interactive Table に対して遅延が生じる可能性があります。最新の結果を返すため、Snowflake は実行がウェアハウスに到達する前に、Cloud Services レイヤーでのクエリコンパイル時に未更新のベーステーブル差分を調整します。ドリルダウンクエリは Interactive Table を直接読み取ります。
タイムアウトとフォールバック: Interactive Warehouse は5 秒を超えるクエリをキャンセルし、この上限は引き下げることしかできません。そこで、Snowflake の自動フォールバック機構を通じて、タイムアウトした対象クエリを受け取るために、同じく 16 CPU と推定される別の Gen2 Small 標準ウェアハウスを構成しました。
クエリの即応性は取り込みに追従できたか？
このグラフは、取り込みが続く中で、各システムのイベントレベルのテーブルに対して事前集計データがどれだけ遅延していたかを示しています。値が小さいほど、事前集計が最新の取り込みデータに近いことを意味します。
ClickHouse Cloud: インクリメンタル MV はフラッシュされた各挿入ブロックを挿入処理の一環として処理したため、生の MergeTree と事前集計された AggregatingMergeTree は連動して進み、全体を通して生データから事前集計データへの遅延はゼロでした。
Snowflake: Snowpipe Streaming によって Interactive Table は進み続けましたが、別個のサーバーレス更新によって Interactive MV に遅れが生じました。取り込み中の遅延トレンドは平均 1.4 分、最大 2.0 分に達したため、最新の集計結果を得るにはクエリ実行時の調整が必要でした。
測定の詳細: 鮮度 (クリックして展開)
SNOWFLAKE LAG SERIES
この MV 遅延系列 は、アクティブな 1 分ごとの 2,072 個の behind_by サンプルを使用しています。ポーリングのタイムスタンプは、208 個のアクティブなダッシュボード観測値の間を線形補間することで、生の行数と整合させました。
報告されている平均値と最大値は、中心化された 61 サンプルの移動平均から算出されています。表示されているトレンドには、さらに中心化された 11 サンプルの移動平均と形状保持補間が適用されています。その結果得られた平均 1.372 分および最大 2.033 分が、本文中では 1.4 分および 2.0 分に丸められています。インタラクティブな読み取り値は、選択された行数における表示トレンドに従います。
CLICKHOUSE BASELINE
ClickHouse のゼロラインは、個別にポーリングされたプロバイダーのメトリクスではなく、ベンチマークセマンティクス上のベースラインです。生テーブルと インクリメンタル MV は同じフラッシュされた挿入ブロックを消費するため、両者の間に独立した更新間隔は存在しません。
412 倍優れたリアルタイムコストパフォーマンス
CostBench の継続的な負荷環境下で、ClickHouse Cloud が Snowflake と比較して達成した成果です。自社データでの効果をぜひお試しください。今すぐサインアップ。
ClickHouse Cloud を試すクエリの即応性が低下したときに何が起きたか？
取り込み中に各システムで実行された同じ 906 回の一致したクエリ実行全体で、ClickHouse Cloud の累積クエリ実行時間は 61.8 秒でした。Snowflake は 2.13 時間に達し、約 124 倍でした。
以下のチャートは、取り込みが進むにつれて集計クエリとドリルダウンクエリの合計実行時間がどのように累積していったかを示しています。
Snowflake の累積実行時間の大半は、Interactive MV に対する集計クエリによるものでした。まずその経路を検証し、次にイベントレベルのデータを直接読み取って別のボトルネックを露呈させたドリルダウンクエリを見ていきます。
測定の詳細: クエリ結果の比較方法(クリックして展開)
完全なクエリ定義、および新規に取り込まれたデータがその結果にどう寄与するかについては、パート 1 をご覧ください: 継続的な負荷のもとでのリアルタイムなコストパフォーマンスの測定: CostBench 初のエンドツーエンド結果。
キャッシュポリシー
両システムともクエリ結果キャッシュは無効化されていたため、測定対象のすべてのクエリが実際に実行されました。基盤となるデータキャッシュはウォーム状態の維持が許可されました。データキャッシュがウォームであっても、クエリ自体の実行は依然として必要です。
読み取り側のサイジング
ClickHouse Cloud は 16 CPU の読み取りノードを 1 台使用しました。Snowflake は Small Interactive Warehouse と、フォールバック用として Gen2 Small ウェアハウスを使用し、それぞれ約 16 CPU と推定されます。このサイジング基準が以下のクエリ比較に適用されます。
クエリのタイミング
クエリレイテンシと累積実行時間には、記録された各クエリについてクライアントから観測可能な所要時間の全体を使用しています。コンパイルと実行のチャートは、Snowflake が個別に報告するフェーズごとの所要時間を示しています。それらの合計はクライアントから観測可能なレイテンシと異なる場合があります。フェーズチャートは、実行時間やコストに使用されるエンドツーエンドのタイミングを置き換えることなく、時間がどこで費やされたかを説明するものです。
クエリごとのチャート
レイテンシチャートは、イテレーションによる一致やシステム間の補間を行わず、1,000 億行のマイルストーンに至るまで各システムが独自に観測した行数に対してプロットしています。生テーブルの代替案を含む集計クエリのトレンドには、中央揃えの 7 観測値移動中央値を使用しています。ドリルダウントレンドには、中央揃えの 5 観測値移動中央値を使用しています。
集計チャートには Snowflake 専用のテューキーの上側フェンス(Tukey upper-fence)ルールが維持されており、除外されたポイントもソースデータとサマリーには残っています。ドリルダウンチャートには外れ値フィルターを適用していません。
フェーズチャートでは、累積コンパイル境界と累積実行境界に対応する 7 観測値または 5 観測値のスムージングを使用しています。
インタラクティブチャートの見方
レイテンシの比較は、ミリ秒スケールと秒スケールの値を一緒に読み取れるよう対数スケールで開きます。絶対的な差異を比較するには「Linear」を選択してください。
累積実行時間とクエリコスト
実行時間と正規化されたクエリコストには、合意された 行数一致アクティブ取り込みセットを使用しています: システムごとに 4 クエリの集計バッチが 209 回、2 クエリのドリルダウンバッチが 35 回で、システムあたり計 906 回のクエリ実行となります。観測値は取り込みの進捗状況によって一致させています。データセット完了時の最初の観測値はアクティブ取り込みの一部として残り、その後の取り込み後の観測値は除外されます。
累積実行時間チャートは、一致した行位置においてこれらの記録された所要時間を加算しています。観測値間のスムージングや補間は使用していません。その集計コンポーネントは維持された事前集計ワークロードであり、後述する生テーブルの代替案は別の比較となります。
表示されている時間はクエリ所要時間の合計です。それらのクエリが実行されている間も、取り込みは何時間にもわたって継続していました。
事前集計データに対する集計クエリ
アクティブな取り込み中、ベンチマークは 10 分ごとに、維持されている日次事前集計に対して 4 つの集計クエリ(A1〜A4)を実行しました。これらのサマリーには、これまでに取り込まれた履歴全体にわたる株式市場の動向を算出するために必要な件数、合計、最小価格、最大価格がすでに含まれています。クエリは、それらの準備された結果を日ごとまたは銘柄ごとに結合します。その結果には新しく届いた気配値を含める必要があるため、事前集計に遅延があればクエリエンジン側に処理が残ることになります。A1 と A2 は、先頭のソートカラムまたはクラスタリングカラムである銘柄コードでもフィルタリングを行うため、他の銘柄のサマリーをスキップできます。
以下のチャートは、データセットの増加に伴う 4 つの集計クエリの推移を示しています。ClickHouse Cloud は黄色、Snowflake は青色で表示されます。Show backup warehouse activity を有効にすると、5 秒のしきい値が表示され、それを超える Snowflake のレイテンシトレンド部分が紫色で強調表示されます。
ClickHouse Cloud: 1,000 億行のチャートウィンドウ全体を通じて、集計クエリのレイテンシは以下のとおりでした:
- 中央値 13 ms - Snowflake より 801 倍高速
- P99 42 ms - Snowflake より 533 倍高速
- 最大値 111 ms - Snowflake より 218 倍高速
インクリメンタル MV が挿入パスの一部として集計状態を最新に保ったため、クエリ側での照合作業は不要でした。行数を一致させたアクティブ取り込みの 209 バッチ全体を通じて、累積実行時間は 11.36 秒でした。
Snowflake: 同じチャートウィンドウ全体を通じて、集計クエリのレイテンシは以下のとおりでした:
- 中央値 10.41 s - ClickHouse Cloud より 801 倍低速
- P99 22.20 s - ClickHouse Cloud より 533 倍低速
- 最大値 24.17 s - ClickHouse Cloud より 218 倍低速
クエリは遅延している Interactive MV と Interactive Table からの新しい行を照合したため、差分が拡大しリフレッシュによって縮小するにつれて鋸歯状のパターンが生じました。同じ 209 回の一致バッチ全体を通じて、累積実行時間は 2.11 時間でした。合意された 5 秒のフォールバックプロキシに基づくと、836 回の実行のうち 477 回(57%) がしきい値を超え、フォールバックパスによるものと判定されました。
インタラクティブな集計クエリワークロード全体において、ClickHouse Cloud は Snowflake より 669 倍高速であり、クエリ時の照合を行うことなく事前集計データを最新に維持しました。
クエリのコンパイル時に再浮上した未完了のリフレッシュ処理
Snowflake が報告したフェーズごとのタイミングは、集計クエリがどこで時間を費やしたかを示しています。オレンジ色はコンパイル、青色はウェアハウスでの実行を表します。
このチャートに含まれる観測値全体において、報告されたフェーズ合計時間の 85% をコンパイルが占め、ウェアハウスでの実行は 15% でした。ウェアハウスのコンピュートを追加しても、その対象は実行部分にとどまります。これらのクエリの大半を占めるコンパイル処理は、個別に管理される Snowflake の Cloud Services レイヤーで実行されます。
オレンジ色のコンパイル領域はお金をかけても解消できません。解決できるのは細い青色の実行帯だけです。
その理由は以下の図に示すとおりです。
① 集計クエリは Interactive Warehouse を使用して Interactive MV を対象とします。ビューの更新が遅れている場合でも、クエリは前回の更新以降に届いた行を含め、最新の結果を返さなければなりません。
② クエリのコンパイル中、Snowflake のプランナーはマテリアライズドビューとそれらの新しい行をどのように組み合わせるかを決定します。そのために、前回の更新以降に作成されたすべてのベーステーブルのマイクロパーティションのメタデータを読み込みます。このコンパイルは、ウェアハウスでの実行が始まる前に、Snowflake の共有 Cloud Services レイヤー で行われます。
Snowflake はこのコンパイル処理のリソースを管理しており、ユーザーがサイズを変更することはできません。ウェアハウスのサイズを増やしても、リソースが追加されるのはその後の実行フェーズです。
更新の合間に新しいマイクロパーティションが蓄積するにつれ、各クエリがコンパイル時に処理すべきメタデータが増加します。更新が追いつくとその処理量は減少し、レイテンシも低下しますが、取り込みが続くにつれて再び上昇し始めます。
パラドックス:Snowpipe Streaming が高速化するほど、最新の MV クエリは遅くなる。
非同期更新の合間に新しいマイクロパーティションがより多く蓄積するため、すべてのクエリでリコンシリエーション(整合性調整)の処理負担が増大します。
内部の仕組み:リコンシリエーション、ウェアハウスサイズ、フォールバック(クリックして展開)
1. 2 つのクエリフェーズ
Snowflake の集計クエリはすべて、ウェアハウスとは独立してまず 共有 Cloud Services でコンパイルされ、その後選択されたウェアハウス上で実行されます。
2. Snowflake が最新の MV 結果を組み立てる仕組み
Interactive MV の更新が遅れていても、Snowflake は古い結果を返しません。コンパイル時、プランナーは前回の更新以降に Interactive Table に追加されたすべてのデータとビューのリコンシリエーションを行い、その差分に含まれる新しいベーステーブルのマイクロパーティションごとにメタデータを読み込みます。
3. レイテンシが上昇してからリセットされる理由
サーバーレスの MV 更新が非同期で実行されている間も、Snowpipe Streaming はマイクロパーティションを作成し続けます。未更新の差分は更新の合間に増大し、更新が追いつくと減少します。これにより、レイテンシ曲線に見られるような上昇とリセットのパターンが生まれます。
4. 測定結果
Snowflake の集計クエリにかかる時間のうち、コンパイルが 85% を占め、ウェアハウスでの実行は 15% でした。設定した 5 秒のフォールバック基準では、836 回の実行中 477 回(57%)がフォールバックと判定される実行パスへと移りました。
5. ウェアハウスの拡大やフォールバックでボトルネックが解消されない理由
ウェアハウスのサイズ変更は、実行時のコンピュートリソースのみに作用します。実行が Interactive Warehouse またはフォールバック先の Gen2 Small に到達する前に、リコンシリエーションはすでに共有 Cloud Services で完了しています。
6. このメカニズムを裏付ける事前の診断結果
プロファイリングを実施したあるクエリでは、5,030 ms のコンパイルフェーズのうち 4,908 ms(97.6%、パーティションあたり約 25 ms)がリモートのマイクロパーティションのメタデータ I/O に費やされていました。約 4 億〜168 億行の生データを用いた Small と X-Large の並行比較診断では、X-Large のクレジット消費率が 8 倍であるにもかかわらず、コンパイル時間の改善は見られませんでした。これらの診断はこのメカニズムを説明するものであり、前述の代表的な測定値は Run14 の結果に基づいています。
7. コストへの影響
ウェアハウスはコンパイルを待つ間もアクティブな状態を維持し課金対象となる可能性があり、1 日の Cloud Services 消費量がウェアハウス使用量の 10% を超えると Cloud Services の使用量自体も課金対象になります。そのため、取り込みが高速化すると、リコンシリエーションのレイテンシと潜在的なコストの両方が増加します。
8. フォールバックを示す色の見方
Show backup warehouse activity を有効にすると、Snowflake の平滑化されたレイテンシ傾向のうち 5 秒を超えている部分が紫色で強調表示されます。
フォールバックの回数と正規化されたコスト配分は、記録された個々のクエリ実行時間から個別に算出されます。5 秒を超えるクエリはその全期間について Gen2 Small のレートで課金され、5 秒以下のクエリは Interactive Small のレートで課金されます。各クエリはいずれか一方の価格区分に割り当てられます。
この強調表示と課金ルールは経過時間に基づいた判定方法です。どのウェアハウスが各クエリを物理的に実行したかを特定するものではありません。
この判定基準では、5 秒以下で発生したフォールバックを見落とす可能性があります。完全な価格境界と除外事項については、後述のスコアボックスに記載しています。
イベントレベルデータに対するドリルダウンクエリ
アクティブな取り込みが行われている間、ベンチマークではイベントレベルのテーブルに対して直接、2 つのドリルダウンクエリ(D1〜D2)を毎時実行しました。これらは、増加し続ける履歴全体にわたって、1 つの銘柄に対する時間ごとの価格サマリーおよびリスクと流動性のプロファイルを計算します。その結果には新しく届いた気配値データ(quotes)が含まれる必要があるため、イベントレベルテーブルでは効率的なフィルタリングを可能にする配置を維持しつつ、新しい行をクエリ可能な状態にしておく必要があります。どちらのクエリも、テーブルのソートキーまたはクラスタリングキーの先頭カラムである銘柄コード(stock symbol)でフィルタリングを行います。
以下のチャートは、イベントレベルテーブルが増加する中での 2 つのドリルダウンクエリを追跡したものです。ClickHouse Cloud は黄色、Snowflake は青色で示されています。
これらのクエリは MV をバイパスして各イベントレベルテーブルを直接読み込んだため、この経路では MV のリコンシリエーションではなく、イベントレベルのデータ配置と提供性能が切り分けて評価されます。両システムとも同じ (sym, t) の順序付け/クラスタリングを採用し、読み取り側のコンピュートとして約 16 CPU を使用しました。さらに Snowflake の Small Interactive Warehouse は約 600 GB のローカル SSD キャッシュ を提供しています。
ClickHouse Cloud: 1,000 億行のチャート測定期間を通じて、ドリルダウンのレイテンシは以下のとおりでした:
- 中央値 722.5 ms - Snowflake より 1.38 倍高速
- P99 1.15 秒 - Snowflake より 2.06 倍高速
- 最大値 1.18 秒 - Snowflake より 2.17 倍高速
行数を一致させたアクティブな取り込みの 35 バッチ 全体において、累積実行時間は 50.47 秒 でした。ソートされた MergeTree 経路のレイテンシはより緩やかに増加し、データ量が多くなっても低水準を維持しました。
Snowflake: 同じチャート測定期間を通じて、ドリルダウンのレイテンシは以下のとおりでした:
- 中央値 993.5 ms - ClickHouse Cloud より 1.38 倍低速
- P99 2.37 秒 - ClickHouse Cloud より 2.06 倍低速
- 最大値 2.56 秒 - ClickHouse Cloud より 2.17 倍低速
同じ 35 の対応バッチ全体において、累積実行時間は 74.81 秒 でした。Interactive Warehouse の約 600 GB のローカル SSD キャッシュにもかかわらず、データが蓄積するにつれてレイテンシはより急激に上昇しました。全 70 回の実行は 5 秒のフォールバックしきい値を下回ったままでした。
対応するドリルダウンワークロード全体において、ClickHouse Cloud は全体で 1.48 倍高速でした。これは Snowflake が約 600 GB のローカル SSD キャッシュを備えていたにもかかわらずです。
イベントレベルテーブルの増大によりクエリ実行の処理負担が増加
プロットされた測定期間において、Snowflake が報告したドリルダウンフェーズ時間の大半をウェアハウスでの実行が占めました。
Snowflake のフェーズ別テレメトリは、MV 経路とは異なるボトルネックを示しています。中央値では、コンパイルにかかった時間は D1 で 225 ms、D2 で 191 ms でした。一方、実行時間はそれぞれ 643 ms と 830 ms であり、プロバイダーが報告したフェーズ時間の 74〜81% を占めました。この実行処理は、拡大するイベントレベルテーブルを Interactive Warehouse が読み込み、フィルタリングするにつれて増加しました。MV のリコンシリエーションとは異なり、この処理はウェアハウス内部で実行されるため、ウェアハウスのコンピュートを増やすことで削減できます。
ドリルダウンで支配的なレイヤーは実行処理です。より大きなウェアハウスを購入することで削減できます。 独立したコンパイルレイヤーは、依然としてウェアハウスの外部に残ります。
詳細分析:キャッシュは追従できた。これはどのようにスケールするのか？(クリックして展開)
測定されたケース
Snowflake は Interactive Warehouse のキャッシュウォーミング をノンブロッキングのバックグラウンド処理として文書化しています。このワークロードに関する事前の診断実行において、クエリプロファイル ではアクティブな取り込み中のリモート読み取りがゼロまたは無視できるレベルであり、中央値で 100% のバイトがキャッシュから提供されたことが報告されています。
約 75 MB/s の取り込み速度において、クエリ対象のワーキングセットは Small ウェアハウスの約 600 GB のキャッシュ に収まり、ウォーミングによって関連データがローカルに維持されました。これらの診断結果はキャッシュの挙動を説明するものであり、上記の代表的なレイテンシ測定値は Run14 の結果に基づいています。
ここから分かること
これはキャッシュにとって好都合なケースでした。ワーキングセットがキャッシュに収まり、ウォーミングのペースも追いついていたためです。残るレイテンシの主な要因は、リモートストレージからワーキングセットを繰り返し取得することではなく、増大するイベントレベルテーブルに対するスキャンとフィルタリングの実行によるものでした。
制約 1:ワーキングセットの容量
最大規模の Interactive Warehouse である 4X-Large でさえ、44 TB のキャッシュ という制限があります。クエリのワーキングセットがキャッシュサイズを超えると、リモート読み取りが増加します。ウェアハウスを小さく設定しすぎると、レイテンシは 5 秒の上限に向かって上昇し、それを超えたクエリはフォールバックに送られます。逆に過剰に大きくすると、不要なキャッシュにコストを支払うことになります。
制約 2:ウォーミングのスループット
Snowflake のドキュメントによると、キャッシュウォーミングのスループットは X-Small ウェアハウスであっても約 300〜400 MB/s であり、ウェアハウスが大きいほどウォーミングも高速になると記載されています。この文書化された X-Small の速度は、本ベンチマークの約 75 MB/s という取り込み速度を余裕で上回っていました。
しかし、ソースのデータ転送レートがさらに高くなると、ウォーミングによってローカル化されるよりも早くクエリ対象のデータが到着する可能性があります。その場合、ワーキングセット全体は収まっていても、最新の行に対してリモート読み取りが必要になることがあります。
サイジングへの影響
Snowflake のユーザーは、クエリがアクセスするデータ量と新しいデータの到着速度の両方を考慮して Interactive Warehouse のサイズを決定する必要があります。ClickHouse のクエリは、サイズ設定やウォーミング維持が必要な独立したサービングキャッシュを介さず、ソートされた MergeTree テーブルに対して直接実行されます。
MV をバイパスすることで集計処理が生テーブルに移動
このイベントレベルの経路は、有用な対照実験にもなります:
Snowflake の集計クエリが更新の遅れている MV をバイパスし、生の Interactive Table に対して直接実行された場合はどうなるでしょうか？
ここでは、前述と同じ読み取り側のサイズ構成を使用し、Snowflake の生の Interactive Table に対する集計クエリと、ClickHouse Cloud の最新の事前集計に対するクエリを比較します。Show backup warehouse activity を有効にすると、5 秒のしきい値が表示され、Snowflake のしきい値を超えたレイテンシ傾向が紫色で強調表示されます。
ClickHouse Cloud: 上記と同じ事前集計経路および結果です。
Snowflake: Interactive MV をバイパスして生の Interactive Table にクエリを実行した結果は以下のとおりです:
| メトリクス | 生テーブルのレイテンシ | 対 Interactive MV | 対 ClickHouse Cloud |
|---|---|---|---|
| 中央値 | 2.47 秒 | 4.21 倍高速 | 190 倍低速 |
| P99 | 18.04 秒 | 1.23 倍高速 | 433 倍低速 |
| 最大値 | 20.67 秒 | 1.17 倍高速 | 186 倍低速 |
更新の遅れている Interactive MV をバイパスしたことで、クエリ時のリコンシリエーションは排除されましたが、集計処理は Snowflake の生テーブル上に残ることになりました。A1 と A2 はクラスタリングキーの先頭カラムである sym でフィルタリングを行っていますが、どちらも Interactive Table が増大するにつれてレイテンシが明確に上昇する傾向を示しています。測定期間内において、取り込みデータが増加すると、こうした選択的な経路であってもクエリ時の処理負荷が増大しました。ClickHouse Cloud の事前集計レイテンシは、同じ 1,000 億行の測定期間を通じて実質的にフラットなままでした。
A3 と A4 はフィルタリングなしの全テーブル集計です。設定した 5 秒のフォールバック基準では、836 回の実行中 220 回(26%) がしきい値を超え、フォールバック経路と判定されました(A3 の実行 103 回、A4 の実行 117 回)。同じ 209 の対応バッチ全体において、Snowflake の生テーブル経路の累積実行時間は 1.10 時間 に達しました。
更新の遅れている Interactive MV をバイパスすることで、クエリ時のリコンシリエーションが排除され Snowflake は高速化しました。しかし、集計処理が生テーブルへとシフトしました。対応するワークロード全体において、すでに最新化されている ClickHouse Cloud の事前集計経路は依然として 347 倍高速でした。
Snowflake の 2 つの集計経路全体において、最新データ経路での未完了の処理がクエリ時に再び現れることになりました:
• Interactive MV: クエリのコンパイル中に行われるリコンシリエーションが、事前集計から欠落している行を処理します。
• 生の Interactive Table: クエリ実行中のスキャンと集計が、イベントレベルの行から直接回答を計算します。
ClickHouse Cloud は取り込み中に事前集計を実行し、常に最新のサマリーをクエリ可能な状態で保持します。
これでアーキテクチャ上の最後の疑問が残ります。Snowflake は、クエリを高速に実行できる形で最新の事前集計結果を保持できるのでしょうか。
なぜ Snowflake のクエリ実行パスは鮮度とレイテンシのトレードオフを強いるのか
2 つの集計テストは、構造的な選択を浮き彫りにしています。Interactive MV にクエリを実行すると最新の結果が返されますが、Snowflake はコンパイル時に未リフレッシュの差分を調整しなければなりません。生の Interactive Table にクエリを実行すればその調整は回避できるものの、事前集計の恩恵は失われ、増大し続けるテーブルに対するスキャンと集計へと処理の負荷がシフトします。
当然考えられる構成はサポートされていない
明白な代替案は、事前集計の結果を自動リフレッシュされる Interactive Table に格納し、集計クエリを通常のテーブル読み取りに変えることです。これにより、サポートされている最小目標ラグ 1 分で、非同期にリフレッシュされた結果を提供できるようになります。
しかし、その鮮度とのトレードオフを受け入れたとしても、この直接的な構成はサポートされていません。Snowpipe Streaming の高性能パスは生データを Interactive Table に格納しますが、Snowflake はある Interactive Table を別の Interactive Table の自動リフレッシュ元として使用することをサポートしていません。
ストリームを受け付けるコンポーネントから、事前集計を高速に保つコンポーネントへと直接データを渡すことはできません。
サポートされている構成は遠回りになる
サポートされている構成では、まずストリームを標準テーブルに取り込み、その後リフレッシュ用のウェアハウスを使用して、未加工データ用と事前集計用の個別の Interactive Table を維持します。これにより、未加工データの複製がもう 1 つ増え、リフレッシュ専用のコンピュートが必要になります。また、同様に1 分の最小ターゲットラグが適用されます。
下表は適用範囲を大まかに対応づけたものであり、厳密に 3 つの構成を同時に再実行した結果ではありません。最初の 2 行は本記事の結果を再利用したもので、サポート対象の回避策の行は 1,000 億行までを対象とした前回の調査をまとめたものです。3 つのパスはいずれも読み取り側コンピュートとして約 16 CPU を使用しています。さらに、サポート対象の回避策では、前述した 128 CPU の Gen2 X-Large リフレッシュウェアハウスが別途必要になります。
取り込み中の集約クエリレイテンシと鮮度
| 鮮度の高いデータのパス | クエリレイテンシ中央値 | P99 クエリレイテンシ | 最大クエリレイテンシ | 結果の状態 / リフレッシュのオーバーヘッド |
|---|---|---|---|---|
| ClickHouse Cloud · インクリメンタル MV | 13 ms | 42 ms | 111 ms | 設計上常に最新 |
| Snowflake · Interactive MV | 10.41 s | 22.20 s | 24.17 s | クエリ実行時のリコンシリエーションにより最新 |
| Snowflake · サポート対象の回避策 (過去の調査) | 173 ms | 557 ms | 925 ms | 継続的な最新状態ではない: 最小目標ラグ 1 分、1,000 億行までに +$1,814.40 のリフレッシュウェアハウス費用 |
**中央値で見ると、サポート対象の回避策は Snowflake の Interactive MV よりも約 60 倍高速でしたが、それでも ClickHouse Cloud より約 13 倍遅い結果となりました。**また、1,000 億行の取り込みを通じて $1,814.40 のリフレッシュウェアハウスのコストが追加されます。これに対し、以下に示す ClickHouse Cloud の完全な最新データパスは、1,132 億行全体の取り込みを通じてわずか $28.69 のコストしかかかりませんでした。
Snowflake のトレードオフ: 最新の結果を取るか、一貫して高速な集約クエリを取るか。
• Interactive MV: 最新の結果は得られるものの、リコンシリエーション処理によってクエリのコンパイルが遅延します。
• Raw Interactive Table: 最新の結果は得られるものの、各クエリが増加し続ける生データをスキャンして集約する必要があります。
• サポート対象の回避策: 高速なクエリを実現できますが、非同期でリフレッシュされる事前集約データに対する実行となり、個別のリフレッシュウェアハウスと 1 分以上の目標ラグが発生します。
ClickHouse Cloud はその両方を実現しました: 取り込み時に準備処理を実行することで、最新の事前集約と高速な集約クエリの双方を提供します。
サポートされている回避策には何が必要だったのか？ (クリックして展開)
結果の保証要件
サポートされている回避策では、クエリ実行時に最新の結果へと調整するのではなく、非同期にリフレッシュされる事前集計テーブルを提供します。サポートされている目標遅延の最小値は 1 分です。
リフレッシュのキャパシティとコスト
モデル化された 1,000 億行の構成では、Gen2 X-Large のリフレッシュウェアハウスを 28 時間連続稼働させたため、Enterprise の定価で 1,814.40 ドルの追加コストが発生しました (21.6 クレジット/時間 × 28 時間 × 3 ドル/クレジット)。
より小さいウェアハウスの場合
Gen2 の Small、Medium、Large では、およそ 3 時間、8 時間、15 時間で 1 分の目標を維持できなくなりました。X-Large は最初の 24 時間こそ維持したものの、遅延は依然として増加傾向にありました。
スコープに関する最後の補足です。以下のスコアは、本記事で検証したアーキテクチャ、すなわち Snowpipe Streaming から Interactive Table への取り込みと、Interactive MV で維持される事前集計を対象としています。前述のサポートされている標準テーブルによる回避策はこの比較には含まれません。そのコストと性能については、前回の記事でベンチマークを実施しています。
最終結果: リアルタイムの 1 ドルあたりの性能
パート 1 では、CostBench のスコアリングモデル全体を定義しています。要約すると、CostBench はデータセットをクエリ実行可能な状態に維持するコストと、クエリワークロードの処理にかかる正規化されたコストを合算し、その合計コストにワークロードの累積エンドツーエンド実行時間を掛け合わせます。数値が小さいほど優れています。
Snowflake のエンドツーエンドスコアは 412 倍劣る結果に
以下の図は、3 つのスコア入力と最終的な 412 倍の結果を示しています。ソースデータ、完全な計算式、比較条件の境界、および Snowflake のフォールバックに関する前提条件については、料金の詳細を展開してご確認ください。
スコアは、ほぼ同等に揃えられた 16 CPU のクエリ配信環境に基づいています。ClickHouse Cloud は 1 つの 16 CPU 読み取りノードを使用し、Snowflake の Small クエリウェアハウスは約 16 CPU と推定されています。各システムの完全な最新データパス(fresh-data-path)のコストも個別に含まれています。
エンドツーエンドスコア: 料金、計算式、および計算境界(クリックして展開)
料金の基準
AWS us-east における Enterprise の料金は、Snowflake が 1 クレジットあたり 3 ドル、ClickHouse Cloud が 1 コンピュートユニット(CU)時間あたり 0.3903 ドルです。Snowflake のサーバーレス料金は、そのメータリング履歴から直接取得しています。
① 最新データパスのコスト
これは、1,132 億行の完全な取り込みを対象としています。
ClickHouse Cloud
2 CU × 36.75 時間 × 0.3903 ドル/CU 時間 = 28.68705 ドル。
Snowflake
Snowpipe Streaming は 4.6762 TiB を処理し、Snowflake の非圧縮 GB あたり 0.0037 クレジットのレートを使用して 17.71783 クレジットと計測されました。端数処理前のメータリング値を使用すると、表示されている 17.71783 クレジット × 3 ドル/クレジット = 53.15348 ドルとなります。
サーバーレスマテリアライズドビュー更新は 8.75553 クレジットと計測されました。8.75553 クレジット × 3 ドル/クレジット = 26.26659 ドル。
合計: 53.15348 ドル + 26.26659 ドル = 79.42007 ドル。 取り込み時のクラスタリングは Snowpipe Streaming に含まれており、取り込み用ウェアハウスは使用していません。
② 正規化されたクエリ配信コスト
CostBench は、取り込み実行中に一致させた各クエリの価格を、完全なエンドツーエンドの実行時間 × 適用される秒あたりの読み取り側レートとして計算します。一致させたスケジュールには、システムごとに 209 × 4 = 836 回の集計クエリ実行と、35 × 2 = 70 回のドリルダウン実行が含まれます。
ClickHouse Cloud
8 CU × 0.3903 ドル/CU 時間 × (集計 11.361 秒 + ドリルダウン 50.466 秒) ÷ 3,600 = 0.05362 ドル。
Snowflake
Interactive の価格が適用された時間: (集計 946.509 秒 + ドリルダウン 74.815 秒) × 1.2 クレジット/時間 × 3 ドル/クレジット ÷ 3,600 = 1.02132 ドル。
フォールバックの価格が適用された時間: 集計 6,653.660 秒 × 2.7 クレジット/時間 × 3 ドル/クレジット ÷ 3,600 = 14.97074 ドル。
合計: 1.02132 ドル + 14.97074 ドル = 15.99207 ドル。
採用された代替モデルでは、5 秒以下のジョブは Interactive Small で価格設定し、5 秒を超えるジョブはその全体の経過時間を Gen2 Small で価格設定します。836 件の集計ジョブのうち、477 件(57.1%)がこの閾値を超えました。ドリルダウンジョブで超えたものはありませんでした。コンパイル時間も含まれています。
常時稼働のフォールバックキャパシティ、最低請求額、およびフォールバック価格が適用されたジョブに対するプライマリウェアハウスの追加料金は除外されています。
③ 総クエリ実行時間
ClickHouse Cloud: 集計 11.361 秒 + ドリルダウン 50.466 秒 = 61.827 秒。
Snowflake: 集計 7,600.169 秒 + ドリルダウン 74.815 秒 = 7,674.984 秒。
計算境界
① は取り込み全体を対象としています。② と ③ は、取り込み実行中の行数を一致させた測定値のみを使用しており、取り込み完了後の測定値は除外しています。
ストレージは除外されています。データベースストレージのコストはスコアから除外されているため、412 倍という結果には、前述のストレージフットプリントの差は含まれていません。表示値は端数処理されている場合がありますが、スコアの計算には完全な精度の入力値が使用されています。
最終スコア
ClickHouse Cloud: (28.68705 ドル + 0.05362 ドル) × 61.827 = 1,776.9494。
Snowflake: (79.42007 ドル + 15.99207 ドル) × 7,674.984 = 732,286.6479。
相対的な結果: 732,286.6479 ÷ 1,776.9494 = 412.103 倍。
詳細なサマリーには、採用されたすべての入力値と正規化コストの取り決めが公開されています。
前述の 124 倍の累積実行時間の差に、3.32 倍のエンドツーエンドのコスト差が加わります。CostBench はこれら 2 つの軸を掛け合わせることで、412 倍のエンドツーエンドのスコア差を生み出しています。
Snowflake の最新データ処理パスは、すべてのスコア構成要素に影響を与えました。 Snowpipe Streaming とマテリアライズドビューの更新によって直接的なコストが増加し、調整処理(リコンシリエーション)によって総クエリ実行時間が延び、その実行時間の長さが正規化されたクエリ提供コストを押し上げました。
リアルタイムにおける 1 ドルあたりの性能差をもたらす要因
最後の比較では、両方の軸を統合しています。測定されたエンドポイントにおいて、ClickHouse Cloud は 61.8 秒の累積クエリ実行時間と 28.74 ドルのエンドツーエンドのコストを達成したのに対し、Snowflake は 2.13 時間と 95.41 ドルでした。
ClickHouse Cloud の優位性は、シンプルで統合されたアーキテクチャから始まります。取り込み、順序付け、事前集計がストレージエンジンに組み込まれています。生データとサマリーは別個のリフレッシュサービスやサイクルを介さずに連動して更新されます。クエリは、追いつくべき未完了の事前処理作業を抱えることなく、準備済みの最新データを読み取ります。
Snowflake のテスト対象となったストリーミング経路では、取り込みと事前集計が分離されています。生データテーブルは更新され続けましたが、サマリーの更新は遅れました。最新の結果を返すにはクエリ側でその差分を補う必要があり、レイテンシとコストが増加しました。
回避策を適用しても、トレードオフの形が変わるだけでした。生データに直接クエリを実行すれば鮮度は維持できますが、集計作業が繰り返されます。別途リフレッシュされたサマリーから結果を提供すれば読み取りは高速化しますが、継続的な鮮度は失われ、インフラとコストが追加されます。
こうしたアーキテクチャの違いは結果にも明確に表れました。1,000 億行にわたる継続的な取り込みの最中、ClickHouse Cloud の対話型集計クエリは P99 レイテンシ 42 ms を達成したのに対し、Snowflake の Interactive MV 経路では 22.20 秒 でした。
同じアーキテクチャにより、最新データ経路の経済性も維持されました。事前処理コストの低さとクエリ提供の高速化が合わさることで、本ベンチマークにおいて 412 倍優れたエンドツーエンドのリアルタイム 1 ドルあたり性能 がもたらされました。
ClickHouse Cloud は、継続的に更新される最新データに対して迅速な回答を提供できるよう、エンドツーエンドで専用に構築されています。その優位性は、流入する各行の準備から最新の結果の提供に至るまで、システム全体が連動して機能する点にあります。
CostBench シリーズの次回は「ClickHouse Cloud vs. BigQuery」をお届けします。
