主要5大クラウドデータウェアハウスのコストパフォーマンス比較

要約

Snowflake、Databricks、ClickHouse Cloud、BigQuery、Redshiftを10億行、100億行、1000億行の規模でベンチマークし、各ベンダーの実際のコンピュート課金ルールを適用しました。

大規模な分析ワークロードにおいて、ClickHouse Cloudは他のすべてのシステムよりも桁違いに優れたコストパフォーマンスを提供します。

クラウドウェアハウスのコストパフォーマンスを比較する方法 #

データセットと一連の分析クエリがあります。それらを実行できる複数のクラウドデータウェアハウスがあります。そして質問はシンプルです：

分析ワークロードにおいて、1ドルあたり最も高いパフォーマンスを得られるのはどこか？

価格表ではこれに答えられません。

答えられないのです。異なるベンダーはコンピュートの計測方法が異なり、容量の価格設定が異なり、「コンピュートリソース」の定義が異なるため、その数値を額面通りに比較することはできません。

そこで私たちは、主要な5つのクラウドデータウェアハウスすべてで同じ本番環境由来の分析ワークロードを実行しました：

• Snowflake
• Databricks
• ClickHouse Cloud
• BigQuery
• Redshift

そして、10億、100億、1000億行という3つのスケールで実行し、データが増えるにつれてコストとパフォーマンスがどのように変化するかを確認しました。

短いバージョンが必要な場合は、ネタバレをどうぞ：コストパフォーマンスはシステム間で線形にスケールしません。

ClickHouse Cloudは他のすべてのシステムよりも桁違いに優れたコストパフォーマンスを提供します。

詳細、チャート、方法論が必要な場合は、読み進めてください。

再現可能なパイプライン：
この投稿のすべての結果は、Bench2Costを使用して生成されています。これは、オープンで完全に再現可能なベンチマークパイプラインです。 Bench2Costは各システムの実際のコンピュート課金モデルを生の実行時間に適用するため、コスト比較が正確で検証可能です。

ストレージは焦点ではありません：
Bench2Costはすべてのシステムのストレージコストも計算しますが、ストレージ価格はシンプルで、ベンダー間で類似しており、分析ワークロードのコンピュートと比較して無視できるため、ここでは強調していません。

隠れたストレージの勝利：
とはいえ、チャートからリンクされている結果JSONの生の数値を見ると、ClickHouse Cloudはストレージサイズとストレージコストの両方で他のすべてのシステムを静かに打ち負かしており、多くの場合桁違いですが、これはこの比較の範囲外です。

インタラクティブベンチマークエクスプローラー #

静的なチャートはストーリーテリングには最適ですが、完全なデータセットの表面をかすめるだけです。

そこで、私たちは新しいものを構築しました：完全にインタラクティブなベンチマークエクスプローラーをブログ内に埋め込みました。

ベンダー、ティア、クラスターサイズ、データセットスケールを自由に組み合わせることができます。ランタイム、コスト、コストパフォーマンスランキングを切り替え、この研究の背後にある完全な結果を探索できます。

これらの数値をどのように生成したかを理解したい場合は、すべて投稿の最後にある付録に文書化されています。

まず10億行から始めて、各スケールでのシステムのパフォーマンスを見ていきましょう。

(付録で説明されているように、各システムを評価するために標準的な43クエリのClickBench分析ワークロードを使用しています。)

10億行：ベースライン #

10億スケールはベースラインとしてのみ含めていますが、現代のデータプラットフォームにとってより現実的なストレスポイントは100億、1000億、それ以上です。

今日の分析ワークロードは、数百億、数千億、さらには数兆行で日常的に動作しています。 Teslaはストレステストのために1京行以上をClickHouseに取り込みました、そしてClickPy、私たちのPythonクライアントテレメトリデータセットは、すでに 2兆行 を超えています。

以下の散布図は、5つのシステムそれぞれについて、10億行のClickBench実行の合計実行時間（横軸）と合計コンピュートコスト（縦軸）を示しています。

(明確さのために目盛りラベルを非表示にしていますが、点の位置は完全に正確なままです。上記のインタラクティブベンチマークエクスプローラーには完全な数値軸が表示されます。)

(表示される構成は各エンジンの全範囲を表しています。詳細は付録を参照してください。)

10億行では、チャートは3つの明確な象限の動作を明らかにします。

コスト効率を直接比較するために、以下のチャートは実行時間とコストを単一のコストパフォーマンススコアに集約しています（方法論の定義）：

画像は明確になります：

• ClickHouse Cloudは最も強力な総合コストパフォーマンスを提供します。最も低い実行時間 × コスト値を持ち、他のすべてはそれと比較されます。

• BigQuery（容量モード）が次に続き、このデータセットサイズではClickHouseの約2倍悪いです。

• 他のほとんどの構成は急速に落ち込みます。実行時間 × コストが上昇するにつれて：3〜4倍悪いから、より大きなSnowflakeとDatabricksティアでは2桁の倍数まで。

真のストーリーはデータが増えたときに始まります。

10億行は現代の基準ではまだ小さく、データが100億行と1000億行にスケールするにつれて経済性は急速に変化し、ほとんどのシステムは「高速 & 低コスト」ゾーンから急激に外れ始めます。

100億行：亀裂が現れ始める #

以下の散布図は、5つのシステムそれぞれについて、100億行のClickBench実行の合計実行時間（横軸）と合計コンピュートコスト（縦軸）を示しています。

(前述のとおり、視覚的な明確さのために目盛りラベルを非表示にしていますが、点の位置は実際の基礎値を反映しています。上記のインタラクティブベンチマークエクスプローラーには完全な数値軸が含まれています。)

(表示される構成は各エンジンの全範囲を表しています。詳細は付録を参照してください。)

100億行では、最初の真の分離が現れます。実行時間が延び、コストが上昇するにつれて、システムは「高速 & 低コスト」象限から外れ始めます。

コストパフォーマンススコアを見ると、分離は明白になります：

100億行でギャップは広がります：

• ClickHouse Cloudは明確なリーダーであり続けます。大きなマージンでトップのコストパフォーマンススポットを維持しています。

• 次善のシステムはすでに大きく遅れています。ClickHouseよりも7〜13倍悪いです（Snowflake 4X-L、Databricks Large、Databricks 4X-Large）。

• BigQuery Enterpriseはさらに後退し、約14倍悪いです。

• その後、すべてが長い尾に崩壊し、数十から数百倍悪く、Redshift Serverless（128 RPU）、Snowflake L、BigQuery On-Demand、Snowflake X-Small、Databricks 2X-Smallが含まれます。

100億行では、経済性が急激に分岐します：ClickHouse Cloudは他のすべてのシステムよりも桁違いに優れたコストパフォーマンスを提供します。

1000億行：真のストレステスト #

以下の散布図は、5つのシステムそれぞれについて、1000億行のClickBench実行の合計実行時間（横軸）と合計コンピュートコスト（縦軸）を示しています。

(前述のとおり、視覚的な明確さのために目盛りラベルを非表示にしていますが、点の位置は実際の基礎値を反映しています。上記のインタラクティブベンチマークエクスプローラーには完全な数値軸が含まれています。)

(表示される構成は各エンジンの全範囲を表しています。詳細は付録を参照してください。両軸は対数スケールであるため、垂直および水平のジャンプは見た目よりもさらに大きいです。)

1000億行では、分離は劇的になります。ClickHouse Cloudは、このスケールでも「高速 & 低コスト」領域にしっかりとどまる唯一のシステムです。

他のすべてのエンジンは現在、「低速 & 高コスト」にしっかりと押し込まれており、実行時間は数分から数時間の範囲で、コストは桁違いに高くなっています。

(SnowflakeとDatabricksの最小ウェアハウスサイズはここには示されていません。1000億行では数日間実行されるため、この比較の範囲をはるかに超えています。)

そしてコストパフォーマンススコアビューは、ギャップを見逃すことを不可能にします：

1000億行では、コストパフォーマンスのスプレッドが大幅に増加します：

• ClickHouse Cloudは明確なリーダーであり続けます（最高の総合コストパフォーマンス）。

• 次善のシステム、 Databricks（4X-Large） は、23倍悪いまで落ちます。

• Snowflake（4X-L）は32倍悪いで続きます。

• BigQuery Enterprise、Redshift Serverless（128 RPU）、Databricks（Large）、Snowflake（L）は数百倍悪い範囲に入ります。

• BigQuery On-Demandはチャートの底に崩壊し、1,350倍悪いです。

私たちが1000億行で止めたのは、ClickHouse Cloudが限界に達したからではなく、達していませんでした、同じベンチマークを1兆行以上に押し上げることが、他のほとんどのシステムにとって法外に高価であるか、または数日間の実行イベントになるからです。

1000億では、いくつかのウェアハウスはすでに単一のClickBench実行で $100〜$1,700のコンピュート請求を発生させており、より小さなティアは数日間実行されます。

最高のコストパフォーマンスを提供するのは誰ですか？ #

私たちはシンプルな質問から始めました。今、データでそれに答えることができます：

分析ワークロードにおいて、1ドルあたり最も高いパフォーマンスを得られるのはどこか？

より大きなスケール — 100億、そして1000億行 — に押し上げると、トレンドは明白になります：すべての主要なクラウドデータウェアハウスが「低速 & 高コスト」に向かって漂います。

1つを除いて。

1000億行のストレステストを含むすべてのスケールで、ClickHouse Cloudは「高速 & 低コスト」にとどまる唯一のシステムです。他のすべてのシステムは遅く、高価、またはその両方になります。

大規模な分析ワークロードにおいて、ClickHouse Cloudは他のすべてのシステムよりも桁違いに優れたコストパフォーマンスを提供します。

そして、ここにキッカーがあります：SnowflakeとDatabricksはすでに、提供する最大のウェアハウスサイズで、ハードリミットに達していました。

ClickHouse Cloudにはそのような上限はありません。

私たちが20コンピュートノードで止めたのは、ClickHouse Cloudが限界に達したからではなく、結論がすでに決定的だったからです。

ベンチマークをどのように実行したかを正確に確認したい場合は、完全な方法論が以下の付録に含まれています。

付録：ベンチマーク方法論 #

このセクションは、5つのシステムすべてでベンチマークを実行し、価格を正規化した方法の完全な詳細を提供します。

ベンチマークセットアップ #

この分析はClickBenchに基づいており、本番環境由来の匿名化されたデータセットと43の現実的な分析クエリ（クリックストリーム、ログ、ダッシュボードなど）を使用しており、合成データではありません。

しかし、標準データセットは約1億行で、現在の基準では小さいです。今日のデータセットは頻繁に数十億、数兆、さらには数京で動作します。Teslaは負荷テストのために1京行以上をClickHouseに取り込みました、そしてClickPy、私たちのPythonクライアントテレメトリデータセットは、すでに2兆行を超えています。

データが増えるにつれてコストとパフォーマンスがどのように進化するかを理解するために、ClickBenchを10億、100億、1000億行に拡張し、3つのスケールすべてで完全な43クエリベンチマークを再実行しました。

結果を公正で再現可能に保つために、標準的なClickBenchルールに従いました：チューニングなし、エンジン固有の最適化なし、最小/最大コンピュート設定の変更なし。これにより、すべての結果が、ハンドチューニングやワークロード固有のトリック（例：マテリアライズドビューで集計を事前計算）なしで、各システムが箱から出してどのように動作するかを反映することを保証します。

互換性のない課金モデルを持つシステム間で結果を比較可能にするために、コンパニオン投稿のBench2Costフレームワークを使用しました。これは、生のクエリごとの実行時間を取得し、各ベンダーの実際のコンピュート価格モデルを適用し、すべてのシステム上のすべてのクエリの実行時間とコンピュートコスト、さらにストレージコストとシステムメタデータを含む統一されたデータセットを生成します。

比較する構成 #

インタラクティブベンチマークエクスプローラーではすべてのティアとクラスターサイズを比較できますが、この投稿では、比較をシンプルで一貫性のあるものにしています：

• SnowflakeとDatabricks：それぞれ3つのウェアハウスサイズ、最小、中規模サイズ、最大のEnterpriseティアサイズを含め、完全な実用的なスペクトルをカバーします。（Snowflake固有の詳細、Gen 2ウェアハウス、QAS、新しいウェアハウスサイズについては、以下のメモを参照してください。）

• ClickHouse Cloud：ClickHouse Cloudには固定されたウェアハウス形状がないため、「小/中/大」ティアは存在しません。代わりに、データセットサイズごとに1つの固定されたClickHouse Cloud Enterpriseティア構成を使用します。

• BigQuery：BigQueryはチャートに2回表示されます。これは、クラスターサイズの概念を持たない完全なサーバーレスシステムですが、2つの課金モデルを提供しているためです。ワークロードを1回実行し（2000スロットのベース容量で）、その後、同じ実行時間をEnterprise（使用されたスロット容量ベース）価格とオンデマンド（スキャンされたTiBあたり）価格の両方を使用して価格設定します。

• Redshift Serverless：Redshift Serverlessは1回表示されます。これは同様にウェアハウスサイズやティアを持たないためです。デフォルトの128 RPUベース構成を使用します。

すべての価格は、該当する場合、同じクラウドプロバイダーとリージョン（AWS us-east）で取得されます。BigQueryは例外で、GCP us-eastを使用します。

ベンダーが複数の価格ティアを提供する場合（例：Enterprise対Standard/Basic）、一貫性のためにEnterpriseティアを使用しますが、相対的なコストパフォーマンスの違いはティア間で広く同じままです。インタラクティブベンチマークエクスプローラーで代替ティアを探索することで、これを確認できます。

これにより、10億、100億、1000億行にわたって公正で、解釈可能で、一貫した比較が維持されます。

Snowflake Gen2、QAS、新しいウェアハウスサイズ、Interactiveウェアハウスに関する注記 #

このベンチマークでは、Snowflakeの標準Gen 1ウェアハウスを使用しました。これは今日ほとんどのリージョンでデフォルトの構成のままです。

Gen 2ウェアハウスは、同じTシャツサイズで25〜35%多くのクレジット/時間を消費し、その可用性はクラウド/リージョンによって異なるため、Gen 1に焦点を当てることで、環境間で一貫した比較を維持します。

また、SnowflakeのQuery Acceleration Service（QAS）を有効にしませんでした。
QASはウェアハウスの上にサーバーレスバーストコンピュートを追加し、スパイキーまたはスキャンヘビーなクエリフラグメントを加速できますが、追加の課金ディメンションを導入するため、クリーンなベースライン比較を維持するために、この研究では除外しています。

Snowflakeは4X-Largeよりも大きいウェアハウスサイズも導入しました - 具体的には5X-Largeと6X-Largeです。これらは2024年初頭に開始され、その後クラウド全体に拡大しましたが、4X-Largeは最も広く使用される上位ティアのままであるため、ここでは最大サイズとして選択しました。

SnowflakeのInteractiveウェアハウス（プレビュー）は、低レイテンシ、高同時実行ワークロードに最適化されています。これらは標準ウェアハウスよりも1時間あたりの価格が低いです（例：XSで0.6対1クレジット/時間）が、SELECTクエリに5秒のタイムアウトを強制し、1時間の最小課金期間を持ち、各再開は完全な最小料金をトリガーします。

Snowflakeは多くの相互作用するパフォーマンス変数を提供します — Gen 1対Gen 2、QAS、5XL/6XLティア、Interactiveウェアハウス。最初のベンチマークでこれらを混合することを意図的に避け、比較をクリーンに保ちました。Snowflake固有のフォローアップ記事で、これらの構成を深く探索します。

ホット対コールドランタイムに関する注記 #

ClickBenchに沿って、ホットランタイムを報告します。これは3回の実行のうちの最良のものとして定義され、すべての場所でクエリ結果キャッシュを無効にしました。コールドスタートベンチマークは含まれていません：クラウドウェアハウスは非常に異なるデータキャッシング動作を公開し、ほとんどはOS レベルのページキャッシュのリセットやオンデマンドでのコンピュートの再起動を許可しません。コールド条件は標準化できないため、公正で再現可能な結果のいずれも生成しません。

ネイティブストレージ形式に関する注記 #

このベンチマークの各システムは、そのクエリエンジンのネイティブストレージ形式を使用して評価されます。たとえば、ClickHouse CloudのMergeTree、DatabricksのDelta Lake、Snowflakeの独自のマイクロパーティション形式、BigQueryのCapacitorカラムナーストレージです。これにより、各エンジンが設計および最適化された条件下で測定されることを保証します。

補足として、SnowflakeやClickHouse Cloudを含むいくつかのシステムは、Delta Lake、Apache Iceberg、またはApache Hudiなどのオープンテーブル形式を直接クエリすることもできます。ただし、この研究は厳密にネイティブパフォーマンスとコストに焦点を当てています。オープンテーブル形式でこれらのエンジンを比較する別のベンチマークが計画されています。お楽しみに。

メータリング粒度に関する注記 #

5つのシステムすべてで比較を一貫して保つために、1つの簡略化を行います：

すべてのシステムが完璧な秒単位の粒度でコンピュートを課金しているかのように扱います。

実際には、コンパニオン投稿で詳述されているように：

• Snowflake、Databricks、ClickHouse Cloudは、アイドルタイムアウト後にのみ課金を停止し、それぞれがウェアハウス/サービスが実行されているときに1分間の最小料金を持っています。

• BigQueryとRedshift Serverlessは使用を秒単位で計測しますが、それでも最小料金ウィンドウを適用します（例：BigQueryのスロット消費の1分間最小、Redshift ServerlessのRPU使用の1分間最小）。

範囲と機能の違いに関する注記 #

この分析は1つの質問を見ています：

データがスケールするにつれて、分析ワークロードを実行するのにいくらかかるか？

比較をクリーンに保つために、意図的に43クエリベンチマークのコンピュートコストのみに焦点を当てています。より広範なプラットフォーム機能（ガバナンス、エコシステム統合、ワークロード管理、レイクハウス機能、MLツールなど）を比較しようとしません。これらは間接的にベンダーがコンピュートの価格をどのように設定するかに影響を与える可能性がありますが。

「総合コストパフォーマンスランキング」の測定方法 #

完全に異なる課金モデルを持つシステムを比較するために、1つのシンプルでスケール独立なメトリックを使用します：

コストパフォーマンススコア = 実行時間 × コスト

(小さい方が良い)

このメトリックは、コストパフォーマンスランキングの背後にある直感を捉えています：

• 高速なシステムはより良いスコアを獲得します
• 低コストのシステムはより良いスコアを獲得します
• 低速または高コストのシステムはすぐに膨張します
• コストとランタイムは複合します。非効率性は互いに掛け算されます

これは私たちが気にする質問に直接答えます：

このシステムがワークロードを完了するのにどれくらい高価か？

すべての結果を正規化して、最良のシステムがベースライン（1×）になり、他のすべてのシステムはN×悪いとして表示され、ランキングを一目で比較しやすくします。

散布図チャートの読み方 #

上記のセクションで使用している「合計実行時間対合計コンピュートコスト」散布図の読み方に関する2つの簡単なメモ：

• 両軸は対数スケールを使用しています。 システム間の違いは、より大きなデータ量で桁違いに及ぶため、対数-対数ビューはすべてを読みやすく保ちます。

• プロットを一目で解釈しやすくするために、4つの象限を重ねました（「高速 & 低コスト」、「高速 & 高コスト」など）。これらの象限は純粋に視覚的です。これらは中央値または統計的カットポイントに基づいていません。読者を方向付けるシンプルな方法です。

興味深いのは、データセットが増えるにつれてシステムが象限間をどのように移動するかです。