同一のワークロードと準備要件。すべてのシステムが同じデータを受け取り、同じスケジュールで同じクエリを実行しました。RAW データと日次の事前集計には、一致するソートキーまたはクラスタリングキーを使用しました。
クエリコンピュート:可能な限り統一。一部のプラットフォームはコンピュートを動的に割り当てます。設定可能なサイズによって CPU 数が異なる場合や、同じコア数でも RAM 容量が異なる場合があります。有意義な一致が可能な箇所では、クエリコンピュートを揃えました。
取り込みと準備:可能な限りコストを最小化。設定可能なサービスについては、キャリブレーション中に目標レートを維持しつつ、データをクエリ可能な状態に保てる最小の検証済み構成を採用しました。プラットフォーム側で取り込みやメンテナンスのコンピュートが制御される場合は、そのネイティブな割り当てと料金を比較対象に含めました。
その支出から何が得られるかを比較。クエリコンピュートを追加すれば、より高速な応答を得られます。継続的な準備処理に投資すれば、クエリ側の負荷を減らし、実行時間とコストを削減できます。CostBench は、準備コストとクエリ処理コストの合算に対して得られたクエリ速度を自動的に重み付けするスコアを用いて、エンドツーエンドのコストパフォーマンスによって各システムを順位付けします。より高額な構成は、その高コストを正当化できるだけの高速な応答を提供しなければなりません。
出典:Measurements and methodology
ClickHouse Cloud は、完全な高可用性取り込みサービス全体で、**1,132 億行**すべてを **$28.69** で取り込み、準備しました。ここに示す概要では、ClickHouse の総クエリコストは約 **$0.05**、累積クエリ実行時間は **1.03 分**にとどまり、その間も日次サマリーは RAW データと常に同期されていました。 > **本番環境における大規模なコスト削減:**出典:Measurements and methodology
ClickHouse は**挿入中**に事前集計を更新するため、RAW データとサマリーが同時に進みます。他の検証対象システムでは、RAW データの書き込み後に**非同期**で事前集計を更新していたため、上記のような遅延が発生しました。 RAW 履歴と日次サマリーの双方をクエリ可能な状態に保ちながらも、**最も低い準備コスト**を実現しました。全 **1,132 億行**の準備にかかったコストは、[ClickHouse Cloud](https://clickhouse.com/cloud) で **$28.69** であったのに対し、Snowflake では約 $79、BigQuery(Capacity)では $243、Redshift Serverless では $522、Databricks では $696 でした。出典:Measurements and methodology
他の検証スタックでは、追加の取り込みサービスやメンテナンスサービスが必要となり、別途料金が発生することも少なくありませんでした。ClickHouse は、**列指向ストレージ、並べ替え、事前集計という[3 つの準備ステップ](https://clickhouse.com/ja/blog/costbench-real-time-performance-per-dollar-jp)すべてを同一エンジン内で処理**し、その処理も**取り込みサービスのコストに含まれています**。 ### 優位性を支えるエンジンの内部構造 ClickHouse は、受信データを**メモリ上に保持している間に**ソートと事前集計を行うことで、**準備のオーバーヘッドを低く抑えています**。 #### 受信データをメモリ上でソートおよび事前集計 受信データは、直接受け取ったクライアントバッチまたは非同期挿入バッファのいずれかを経由してメモリに展開されます。ClickHouse はまず、RAW テーブルのソートキー(銘柄コードと時刻)に従って RAW 気配値をソートし、[インクリメンタルマテリアライズドビュー](https://clickhouse.com/docs/ja/concepts/features/materialized-views/incremental-materialized-view)を用いて日次サマリーを計算した上で、サマリーテーブルのソートキー(銘柄と日付)に従ってソートします。その後、双方がソート・圧縮された列指向の[データパート](https://clickhouse.com/docs/ja/concepts/core-concepts/parts)としてディスクに書き込まれるため、**初期準備のための「書き込みと再読み込み」という余分なサイクルを回避できます**。RAW データとサマリーは、同一の受信データから**足並みを揃えて更新**されます。 他の検証パスでは、RAW データの並べ替えや、サマリーの事前集計・並べ替えを、初回の書き込み後に個別の非同期ステージとして実行します。**サマリーが更新される前に新しい RAW 行が利用可能になるため、これらのパスでは両者の遅延ゼロを保証できません。** 下のアニメーションは、両方のステージが取り込みに追いつかなくなる様子を示しています。 これらのステージではストレージからデータを再度読み出すため、準備処理と I/O が増加します。新しく書き込まれた RAW 行がソート待ちのまま滞留し、ソート済みサマリーはさらに遅れていくことになります。 --- ## ClickHouse Cloud を試す 手元のデータで効率的なデータ準備と並列クエリ実行のパフォーマンスを体感してください。実際のリアルタイムワークロードで ClickHouse Cloud をお試しいただけます。 [ClickHouse Cloud を試す](https://console.clickhouse.cloud/signUp?loc=blog-cta-2808-clickhouse-cloud-clickhouse-cloud&utm_blogctaid=2808) --- データがメモリ上にあるうちに準備を行うことで、オーバーヘッドを低く抑えられます。さらに ClickHouse は、その処理の実行を並列化することで処理を加速します。 #### ハードウェアの限界を引き出す設計 **ClickHouse は、基盤となるインフラストラクチャが提供するコンピュートを最大限に活用します。** そのエンジンは、ノード、CPU コア、SIMD レーンにまたがって、データの事前準備とクエリ実行の両方を並列化します。まずはデータの準備から見ていき、続いて同じアプローチがどのようにクエリ実行へと受け継がれるかを説明します。 **異なるノード**は、同期を一切必要とせずに異なる挿入を同時に処理できます。ClickHouse では、同時挿入操作は互いに[分離](https://clickhouse.com/docs/ja/get-started/about/why-clickhouse-is-so-fast#storage-layer-concurrent-inserts-are-isolated-from-each-other)されています。各挿入は新しいデータパートを書き出し、それぞれが独自の[スパースプライマリインデックス](https://clickhouse.com/docs/ja/concepts/core-concepts/primary-indexes)とメタデータを持ちます。そのためノードは、既存のデータを書き直したり、テーブル全体で共有されるインデックスを更新したりすることなく、データを準備できます。 **各ノード内**では、ClickHouse は CPU コア間でソートと事前集計を並列化します。集計には[マージ可能な部分集計状態](https://clickhouse.com/blog/clickhouse_vs_elasticsearch_mechanics_of_count_aggregations#incremental-aggregation)が使用されます。各 CPU コアが独自に行のサブセットを集計でき、それらの状態を結合して正しい結果を生成できます。ClickHouse は、このモデルを [200 以上の集計関数](https://sql.clickhouse.com/?query=U0VMRUNUICogCkZST00gc3lzdGVtLmZ1bmN0aW9ucwpXSEVSRSBpc19hZ2dyZWdhdGUKQU5EIGVtcHR5KGFsaWFzX3RvKQpPUkRFUiBCWSBuYW1l&chart=eyJ0eXBlIjoibGluZSIsImNvbmZpZyI6eyJ4YXhpcyI6InllYXIiLCJ5YXhpcyI6Ijk5dGhfYXZnX3RlbXAiLCJzZXJpZXMiOiJjb3VudHJ5IiwidGl0bGUiOiJUZW1wZXJhdHVyZSBieSBjb3VudHJ5IGFuZCB5ZWFyIn19)とその[コンビネータ](https://clickhouse.com/docs/ja/reference/functions/aggregate-functions/combinators)に適用しています。取り込み時には、これらの状態が集計テーブルに書き込まれます。具体的な例は、私たちの [GROUP BY の解説記事](https://clickhouse.com/ja/blog/clickhouse-parallel-replicas-jp)で紹介しています。 **各コア内**では、ClickHouse は列指向データをバッチ単位で処理し([ベクトル化実行](https://clickhouse.com/blog/cpu-dispatch-in-clickhouse))、SIMD 命令を使用して複数の値に対するサポートされた演算を一度に実行します。 以下のアニメーションは、取り込みノードから 1 つのノードの CPU コアへ、さらに 1 つのコアの SIMD レーンへと拡大して示しています。 ClickHouse は、継続的な挿入と並行して、複数の[バックグラウンドパートマージ](https://clickhouse.com/docs/ja/concepts/core-concepts/merges)を CPU コア全体で[同時](https://clickhouse.com/blog/supercharge-your-clickhouse-data-loads-part1#more-parts-more-background-part-merges)に実行します。集計テーブルでは、これらのマージにより異なるバッチの部分集計状態が結合され、挿入時に開始された事前集計が継続されます。これにより、集計処理がクエリ時からバックグラウンドマージ時へと段階的に[シフト](https://clickhouse.com/blog/clickhouse_vs_elasticsearch_mechanics_of_count_aggregations#incremental-aggregation)していきます。また、各テーブルの ORDER BY 順を維持しながら、生データと集計データをより少数の大きなパートへと統合します。クエリは残りの状態を結合して最新の回答を返すため、最新の生イベントをスキャンして追いつく必要がありません。この設計は、私たちの [VLDB アーキテクチャ論文](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf)で解説されています。 ### 数字で見るエンジンの性能 ベンチマークの実行中、[ClickHouse Cloud に組み込まれた高度なダッシュボード](https://clickhouse.com/docs/ja/products/cloud/features/monitoring/advanced-dashboard)を通じて、取り込みサービスのスループット、リソース使用状況、データ削減率、バックグラウンドマージを監視しました。 CostBench は、分析クエリを実行しながら、**毎秒 100 万行の取り込み**を目標として、すべてのシステムに **1,132 億行の株式気配値**をストリーミングしました。**生データが届くと同時に日次集計データもクエリ可能な状態になったテスト対象システムは、ClickHouse Cloud だけでした。** その高可用性取り込みサービスは、それぞれ 2 個の CPU コアと 8 GiB のメモリを備えた 2 つのノード(合計 4 コア、16 GiB)で構成されていました。クエリが独立した読み取りサービスで実行されている間、これらのコアは受信バッチをクエリ可能な状態にし、残りの CPU 容量を集計の継続的な事前集計を含む並列バックグラウンドマージに使用しました。後述の測定値は、4 コアの最大取り込み容量ではなく、そのワークロードを表したものです。**準備コスト 28.69 ドルはテストしたすべてのシステムの中で最も低く**、両方の取り込みノードとそのバックグラウンド処理のコストを網羅しています。 以下のアニメーションに示すように、**並列化された取り込みとバックグラウンドマージ**により、4 個の利用可能な CPU コアのうち**約 3.2 コア**を使用しながら、**毎秒約 430 MB** の非圧縮データを処理しました(**使用コアあたり毎秒約 135 MB**)。この処理は、CPU コアや取り込みノードを追加することでスケールできます。後ほど、ClickHouse Cloud が取り込みコンピュートをクエリコンピュートから独立してスケールさせる仕組みを説明します。出典: 測定値と測定手法
取り込み中、同じ 4 つのコアにより **テストされたすべてのシステムの中で最も優れた生データ圧縮率** も達成され、7.08 TB の生データが 491.2 GB に縮小されました(14.4 倍)。出典: 測定値と測定手法
以下の比較が示すように、**約 1,132 億件の気配値データ**において、ClickHouse Cloud はテストした 5 つのシステムすべての中で**最小の生データサイズ**を記録しました。出典: 測定値と測定手法
取り込みの終了時点で、ClickHouse は生の気配値履歴と比べて行数が約 6 万分の 1 の日次集計データを維持していました。以下のチャートは、テストした 5 つのシステムすべてにおける日次集計データの保存サイズを比較したものです。
出典: 測定値と測定手法
月額ストレージの試算には、ベンチマーク対象リージョンで公開されている定価を使用し、該当する場合は Enterprise プランを採用しています。
ストレージ料金: ClickHouse · Snowflake · BigQuery · Databricks (S3) · Redshift
生データと日次集計データを合わせた月額の推定ストレージ料金は、ClickHouse Cloud が 12.43 ドル、Snowflake が 14.61 ドル、Databricks が 15.16 ドル、BigQuery が 20.06 ドル、Redshift Serverless が 90.44 ドルです。これらの月額料金は、CostBench がエンドツーエンドのスコアからデータベースストレージを除外している理由を理解するのにも役立ちます。ベンチマークの短い期間においては、新鮮なデータの取り込みと準備、およびクエリの処理にかかる合計コストと比べて、ストレージが占める割合はごくわずかです。ストレージコストは、保持期間が長期化するにつれて重要性を増します。
取り込み時の CPU 処理の内訳:
取り込み時の CPU 処理において最も大きな割合を占めるのはパースです。ソートが約 19%、事前集計が約 3% を占めます。以下のチャートでは、パース、ソート、事前集計、圧縮、およびその他の取り込み処理を個別に示しています。クライアントは非同期挿入を介して CSV エンコードされたバッチを送信し、パースによってそれらが ClickHouse の型付けされた列指向データに変換されます。「その他の取り込み処理」には、スパースプライマリインデックスとパートメタデータの構築、および設定されている場合はカラム統計とセカンダリインデックスの構築が含まれます。このチャートは取り込み処理を対象としており、バックグラウンドマージは以下で個別に示しています。
サーバー側のパースの削減:
ClickHouse は Native 形式を含む 70 以上の入力フォーマットをサポートしています。Native 形式では、クライアント側で準備された列指向ブロックにより、サーバー側のパースと変換が軽減されます。私たちの FastFormats 調査とインタラクティブダッシュボードでは、フォーマット、バッチ処理、圧縮の影響について詳しく説明しています。
バックグラウンドでの統合と継続的な事前集計:
同じ 4 つのコアにより、毎秒数百万行がマージされました。これらのマージによって、すでに順序付けされた生データのパートが統合され、バッチをまたいで集計データの集計状態の結合が継続されたため、クエリ側に残される処理が削減されました。データセットが増加しても、パーティションあたりのアクティブパートの最大数は約 100 に維持されました。
リソース使用状況:
CPU 使用率は利用可能な 4 コアのうち約 3.1 コアにとどまり、追跡されたメモリはサービスの 16 GiB 容量の範囲内に収まりました。28.69 ドルの準備コストには、両方のノードとそのバックグラウンド処理が含まれます。
出典: 測定値と測定手法
出典: 測定値と測定手法
すべてのシステムで[クエリ結果のキャッシュは無効化](https://clickhouse.com/ja/blog/costbench-real-time-performance-per-dollar-jp)されていたため、測定されたすべてのクエリが実際に実行されました。継続的な運用環境を反映し、基盤となるデータキャッシュはウォーム状態の維持が許可されました。 集計クエリに関して、Snowflake と BigQuery は**事前集計が生データに対して遅れていた**ため、**クエリ実行時によけいな処理が発生**しました。最新の回答を返すために、集計データとより新しい生データの行を結合する必要があったためです。Databricks と Redshift は最後に完了した集計データを読み取っていたため、より最近の気配値データが結果に含まれない可能性がありました。ClickHouse の事前集計は常に最新であったため、集計クエリは**準備された集計データを直接読み取る**ことができました。出典: 測定値と測定手法
**約 1,000 億行の生データ**において、図示された集計クエリが最新の回答を返すまでにかかった時間は、Snowflake で **16 秒**、BigQuery で **4.6 秒**だったのに対し、ClickHouse では約 **15 ms** でした。 ### その優位性を生み出すエンジンの内部構造 事前準備によって、各クエリが処理しなければならないデータ量が削減されます。事前集計により集計クエリはコンパクトな集計データを読み取れるようになり、ソート順によって適切なフィルタを持つクエリは無関係な範囲をスキップできます。データ準備と同様に、ClickHouse は**残りの処理を並列化する**ことでクエリを高速化します。 **ノード間**では、単一のクエリが複数ノードの CPU コアを使用できます。関与するノードは異なる行のサブセットを同時に処理し、それらの部分結果を 1 つの回答へと結合できます。 **各ノード内**では、ClickHouse は処理対象の行を[利用可能な CPU コア](https://clickhouse.com/docs/ja/concepts/core-concepts/academic-overview#4-2-multi-core-parallelization)に分割し、各コアが自身の受け持ち部分を同時に処理できるようにします。 ClickHouse は、[200 以上の集計関数](https://sql.clickhouse.com/?query=U0VMRUNUICogCkZST00gc3lzdGVtLmZ1bmN0aW9ucwpXSEVSRSBpc19hZ2dyZWdhdGUKQU5EIGVtcHR5KGFsaWFzX3RvKQpPUkRFUiBCWSBuYW1l&chart=eyJ0eXBlIjoibGluZSIsImNvbmZpZyI6eyJ4YXhpcyI6InllYXIiLCJ5YXhpcyI6Ijk5dGhfYXZnX3RlbXAiLCJzZXJpZXMiOiJjb3VudHJ5IiwidGl0bGUiOiJUZW1wZXJhdHVyZSBieSBjb3VudHJ5IGFuZCB5ZWFyIn19)とその[コンビネータ](https://clickhouse.com/docs/ja/reference/functions/aggregate-functions/combinators)に対して、マージ可能な[部分集計状態](https://clickhouse.com/ja/blog/clickhouse-parallel-replicas-jp)を使用します。**各 CPU コアは独自に行のサブセットを集計でき**、それらの状態が結合されて正しい結果が得られます。生データへのドリルダウンではクエリ時にこれらの状態が構築され、集計データに対するクエリでは取り込みやバックグラウンドマージの間に準備済みの状態が結合されます。私たちの [GROUP BY の解説記事](https://clickhouse.com/ja/blog/clickhouse-parallel-replicas-jp)では、具体的な例とともにその仕組みを説明しています。 **各コア内**では、ClickHouse は[ベクトル化実行](https://clickhouse.com/blog/cpu-dispatch-in-clickhouse)を通じて列指向データをバッチ単位で処理し、CPU キャッシュの局所性を高めます。SIMD 命令によって、複数の値に対するサポートされた演算が一度に実行されます。 以下のアニメーションは、同一データがノード間、次いで 1 つのノードの CPU コア間、最後に 1 つのコア内の SIMD レーン間へと分割されていく様子を示しています。 各コアでの集計処理は、低レベルの選択からも恩恵を受けています。ClickHouse は、グループ化キーとデータに基づいて [30 以上の専用ハッシュテーブルバリアント](https://clickhouse.com/docs/ja/get-started/about/why-clickhouse-is-so-fast#meticulous-attention-to-detail)から最適なものを選択します。Alexey による [Building for Fast の対談](https://www.youtube.com/watch?v=CAS2otEoerM&t=1168s)では、ハッシュテーブルの容量予測など、そうした選択の背後にある試行錯誤が紹介されています。長年にわたり、ClickHouse は I/O を徹底的に削減するために何層もの最適化を導入してきました。これらの手法が、そのスピードと効率性の基盤となっています。
準備段階で確立された生データと集計データの順序付けにより、ClickHouse のスパースプライマリインデックスは無関係な範囲をスキップできます。プロジェクションは、代替のデータ順序と独自のインデックスを提供することで、このアプローチを拡張します。
スキップ処理は実行中も継続します。PREWHERE は、追加のカラムがロードされる前にフィルタを適用します。Top-N などの一般的なクエリパターン向けの最適化により、ORDER BY … LIMIT に必要な処理がさらに削減され、結果を改善する見込みのないデータがスキップされます。遅延実体化は、結果の行が確定するまで出力カラムの読み取りを遅延させることができます。
また、ClickHouse はメタデータやデータの反復取得、カラムの伸張・デコード、同じフィルタの重複評価を回避するために、複数レベルのキャッシュを活用しています。
これらは ClickHouse のクエリ最適化のほんの一部にすぎません。統計情報がクエリプランニングを誘導し、クエリの書き換えによって実行前の冗長な計算が排除されます。その他の手法として、頻繁に使用される式の JIT(Just-In-Time)コンパイルや、追加のソートを行わずに ORDER BY を満たしたり集計を簡素化したりするための既存のデータ順序の活用などが挙げられます。私たちの VLDB 研究論文では、これらの手法とエンジン全体のアーキテクチャについてさらに詳しく説明されています。
出典: 測定結果と測定方法
次のグラフは、それらのクエリ実行を支える**並列データ処理スループット**を示しています。**1,132 億件の気配値のエンドポイント**において、ClickHouse はドリルダウンで約 **3.25 GB/s**、インタラクティブ集計で **2.05 GB/s** の非圧縮データを処理しました。出典: 測定結果と測定方法
**使用された CPU コアあたり**の処理レートは、ドリルダウンで約 **374 MB/s**、インタラクティブ集計で **307 MB/s** でした。表示されているエンドポイントでのクエリ実行中の平均 CPU使用率は約 **53%** であり、**47% のヘッドルーム**が残されていました。クエリごとの平均ピークメモリは、ドリルダウンで約 **19.8 MiB**、インタラクティブ集計で **13.2 MiB** でした。この並列実行モデルが CPU コア数に応じてどのようにスケールするかをテストするため、各クエリで使用可能な CPU コアを 2、4、8、16、30、59 個にして、2 つの生データドリルダウンクエリを再実行しました。1,132 億件の気配値はすべて事前にロードされ、準備済みでした。これは、上記の継続的な取り込みの測定とは別の実験です。
59 コアにおいて、スループットはホットキャッシュで約 15.56 GB/s、コールドキャッシュで 9.85 GB/s に達しました。ホットでは通常のデータキャッシュとクエリ条件キャッシュを有効にし、コールドではデータキャッシュをバイパスしてクエリ条件キャッシュを無効にしています。どちらの場合も、クエリ結果のキャッシュは無効のままです。高速化は完全に線形ではありません。部分的な結果の統合には、そのマージ処理が並列化されている場合でもオーバーヘッドが生じ、一部のクエリステージは完全には並列化できないためです。
出典: 測定結果と測定方法
出典: 測定結果と測定方法
### 取り込みとクエリのコンピュートを独立してスケーリング ClickHouse Cloud は、この高効率なエンジンに伸縮性とワークロードの分離をもたらします。[SharedMergeTree](https://clickhouse.com/blog/clickhouse-cloud-boosts-performance-with-sharedmergetree-and-lightweight-updates) によりテーブルストレージとコンピュートが分離され、[Shared Catalog](https://clickhouse.com/ja/blog/clickhouse-cloud-stateless-compute-jp) がデータベースのメタデータを一元化し、[分散キャッシュ](https://clickhouse.com/ja/blog/building-a-distributed-cache-for-s3-jp)によってコンピュートが変更されてもホットデータを再利用できます。この基盤により、キャパシティが変化しても、**ステートレスなコンピュートノードが保存データを再分散することなく同じテーブルにアクセス**できます。 [コンピュート・コンピュート分離](https://clickhouse.com/ja/blog/introducing-warehouses-compute-compute-separation-in-clickhouse-cloud-jp)により、取り込み、ダッシュボード、調査処理を、それぞれ独自の CPU コアとメモリを備えた**独立した規模のサービス**で実行できます。CostBench では、取り込みサービスとクエリサービスにこの分離を使用しました。 CostBench の構成にとどまらず、[On-Demand Compute](https://clickhouse.com/ja/blog/on-demand-compute-jp) を利用すると、対象となるクエリは既存のサービスを通じて**一時的なステートレスワーカー**をリクエストできます。これらのワーカーは、サービスのサイズを恒久的に増やすことなく、一時的な追加クエリキャパシティを提供します。 また、データ共有アーキテクチャは、クエリ処理を分散させる複数の手法をサポートしています。 - [パラレルレプリカ](https://clickhouse.com/ja/blog/clickhouse-parallel-replicas-jp): ノード間で読み取りと集計を分散します。 - [インデックスシャーディング](https://clickhouse.com/ja/blog/index-sharding-clickhouse-cloud-petabyte-scale-indexing-jp): ノード間でインデックス解析を分散します。 - [マルチステージ実行](https://clickhouse.com/ja/blog/multi-stage-distributed-query-execution-clickhouse-cloud-jp): 大規模な結合や高カーディナリティの集計をノード間で動的に分散します。 取り込みノード、読み取りノード、一時的なステートレスクエリワーカーのすべてが、同じ [ClickHouse エンジン](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf)を実行します。データ準備(挿入時変換を含む)、並列化されたクエリ処理、および上記の分散実行メカニズムが、エンジンに組み込まれています。
ClickHouse Cloud は、共通の SQL 関数、データ型、実行機構を維持しながら、ワークロードごとにコンピュートを独立してスケールできます。開発者にとっては、分析パス全体を理解しデバッグするための一貫した構成要素が提供されることになります。共有エンジンコードの改善は、それを利用するすべての役割にメリットをもたらします。
下のグラフは、フルロードされた英国の不動産価格データセットに対する別の実験を示しています。1 つのクエリが、事前集計を行わず、保存データの再分散もなしに、それぞれ 89 CPU コアを持つ 1〜100 ノードを使用して、1 兆行の生データを郡、町、地区ごとにグループ化し、件数、合計、平均を計算します。
データ処理スループットは、1 ノードでの 6.49 GB/s から 100 ノードでの 519.18 GB/s へと向上しました。プロットされた各ポイントは、その構成での 10 回の実行における最速値です。
同じ記事では、1,000 億行の生データを対象に町ごとの価格を合計するという、よりシンプルな集計も実演しています。0.414 秒で完了し、毎秒 2,418 億行、すなわち 1.45 TB/s を処理しました。以下の録画でクエリの実際の動作を確認できます。
これらの生データ実験は、ロード済みデータに対する分散実行の実力を示すものです。CostBench は異なるワークロードを測定しています。新しい気配値データの継続的な準備とクエリの提供を同時に行い、両方のステージを 1 ドルあたりの性能スコアに含めています。
出典: 測定結果と測定方法
出典: 測定結果と測定方法
1,000 億行の時点で、ClickHouse Cloud は**約 15 ms** でクエリを返し、日次サマリーは取り込まれた生データと一致した最新状態に保たれていました。高い鮮度と低レイテンシが揃うことで、アプリケーションが次の判断を下すために必要な分析の根拠が得られます。 そうした判断によってユーザーやワークフロー全体でクエリが繰り返し実行される場合、その経済性が重要になります。最新のサマリーによって繰り返される質問への回答コストが低く抑えられる一方、整列された生データの履歴によって詳細な調査が可能になります。準備コストとクエリコストの低さにより、アプリケーションの成長に伴ってもその両方を実用的な状態に維持できます。 > **実際の環境でのリアルタイムな意思決定:**