共通のテスト基盤
両システムの実行には、同一のソースファイル、スキーマ、行デコードロジック、ワークロード生成コード、クライアントホスト(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 時間後にデータセットを完了しました。
同一の取り込み課題
オブザーバビリティ、エンドユーザー向けアプリケーション、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 などの外部ソースからの取り込みを管理します。したがって、適切な比較はデータの発生元によって決まります。
後者の組み合わせは、外部ソースからデータを取り込む完全な統合同士の比較となります。本ベンチマークでは、アプリケーションからテーブルへの直接パスを測定しています。
共通クライアントとレート制御
両取り込み先とも、同一の 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 行という数値は、クライアント側の配信バッチを示しています。どちらのシステムもサーバー側でさらにバッファリングを行うため、いずれの数値も最終的なストレージへの書き込みサイズを直接表すものではありません。
SNOWFLAKE LAG SERIES
この MV 遅延系列 は、アクティブな 1 分ごとの 2,072 個の behind_by サンプルを使用しています。ポーリングのタイムスタンプは、208 個のアクティブなダッシュボード観測値の間を線形補間することで、生の行数と整合させました。
報告されている平均値と最大値は、中心化された 61 サンプルの移動平均から算出されています。表示されているトレンドには、さらに中心化された 11 サンプルの移動平均と形状保持補間が適用されています。その結果得られた平均 1.372 分および最大 2.033 分が、本文中では 1.4 分および 2.0 分に丸められています。インタラクティブな読み取り値は、選択された行数における表示トレンドに従います。
CLICKHOUSE BASELINE
ClickHouse のゼロラインは、個別にポーリングされたプロバイダーのメトリクスではなく、ベンチマークセマンティクス上のベースラインです。生テーブルと インクリメンタル 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 回のクエリ実行となります。観測値は取り込みの進捗状況によって一致させています。データセット完了時の最初の観測値はアクティブ取り込みの一部として残り、その後の取り込み後の観測値は除外されます。
累積実行時間チャートは、一致した行位置においてこれらの記録された所要時間を加算しています。観測値間のスムージングや補間は使用していません。その集計コンポーネントは維持された事前集計ワークロードであり、後述する生テーブルの代替案は別の比較となります。
表示されている時間はクエリ所要時間の合計です。それらのクエリが実行されている間も、取り込みは何時間にもわたって継続していました。
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 秒以下で発生したフォールバックを見落とす可能性があります。完全な価格境界と除外事項については、後述のスコアボックスに記載しています。
測定されたケース
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 テーブルに対して直接実行されます。
結果の保証要件
サポートされている回避策では、クエリ実行時に最新の結果へと調整するのではなく、非同期にリフレッシュされる事前集計テーブルを提供します。サポートされている目標遅延の最小値は 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 時間こそ維持したものの、遅延は依然として増加傾向にありました。
料金の基準
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 倍。
詳細なサマリーには、採用されたすべての入力値と正規化コストの取り決めが公開されています。