ClickHouse Cloud がリアルタイム分析で選ばれる理由

本記事は、CostBench シリーズの最終回となります。
これまでの記事:測定手法 · Snowflake 編 · Databricks 編 · BigQuery 編 · Redshift 編

「ClickHouse に匹敵するものは他にない」 #

Tesla のシニアスタッフソフトウェアエンジニアである Alon Tal 氏は、ClickHouse をこのように表現しています。11日間の負荷テストにおいて、Tesla は毎秒 10 億行を取り込み、累計で1,000 兆行以上を蓄積しました。

Cloudflare では、クエリ側でその規模の処理が行われています。エンジニアリング担当シニアディレクターの Jamie Herre 氏は、対象が1 日分のイベントデータ(1,610 兆件のイベント)であっても丸 1 年分であっても、2 秒未満で返るクエリを実演しました。

どちらの事例でも、分析パイプライン全体における効率性が求められます。増加し続けるデータセットに対してクエリを実行し続けながら、届いたイベントを即座に分析可能な状態にしなければなりません。それらのイベントを整理し、最新のサマリーを維持すること自体にコストがかかり、各クエリに残される処理量もそれによって決まります。

CostBench は、その準備処理とクエリ実行を合わせて測定します。1,132 億行の株式市場気配値データを ClickHouse Cloud、Snowflake、Databricks、BigQuery、Redshift Serverless へストリーミングしながら、取り込みと並行して分析クエリを実行しました。そして、サマリーの鮮度、準備コスト、クエリコスト、クエリ実行時間を追跡しました。

4 つの比較すべてにおいて、ClickHouse Cloud は最も低い準備コスト、クエリコスト、および累積クエリ実行時間を達成しました。これらの優位性が組み合わさることで、412 倍から 1,996 倍優れたエンドツーエンドのコストパフォーマンスがもたらされました。

ベンチマークのコード、クエリ、構成、測定値、および結果を再現するための手順は、CostBench リポジトリで公開されています。

これまでの記事では、各プロバイダーのアーキテクチャに沿って結果を検証してきました。最終回となる本記事では、ClickHouse Cloud の内部構造に迫り、最新データが到着してから分析結果が返されるまでの流れを追います。効率的な準備処理、並列化されたクエリ実行、Cloud のスケーリングがどのように CostBench の結果を生み出し、リアルタイムアプリケーションやエージェントに何をもたらすのかを解説します。

比類のないエンドツーエンドのコストパフォーマンス #

CostBench のエンドツーエンドスコアは、① 最新データの準備コストと ② クエリ処理コストを合算し、その合計に ③ 累積クエリ実行時間を掛け合わせたものです。値が小さいほど優れており、効率的な準備処理と高速なクエリ実行の双方が結果を改善します。

ClickHouse Cloud は、Snowflake 比で 412 倍、Databricks 比で 752 倍、BigQuery(Capacity) 比で 438 倍、Redshift Serverless 比で 1,996 倍優れたエンドツーエンドのコストパフォーマンスを達成しました。

公平な比較を維持するための取り組み(クリックして展開)

同一のワークロードと準備要件。すべてのシステムが同じデータを受け取り、同じスケジュールで同じクエリを実行しました。RAW データと日次の事前集計には、一致するソートキーまたはクラスタリングキーを使用しました。

クエリコンピュート:可能な限り統一。一部のプラットフォームはコンピュートを動的に割り当てます。設定可能なサイズによって CPU 数が異なる場合や、同じコア数でも RAM 容量が異なる場合があります。有意義な一致が可能な箇所では、クエリコンピュートを揃えました。

取り込みと準備:可能な限りコストを最小化。設定可能なサービスについては、キャリブレーション中に目標レートを維持しつつ、データをクエリ可能な状態に保てる最小の検証済み構成を採用しました。プラットフォーム側で取り込みやメンテナンスのコンピュートが制御される場合は、そのネイティブな割り当てと料金を比較対象に含めました。

その支出から何が得られるかを比較。クエリコンピュートを追加すれば、より高速な応答を得られます。継続的な準備処理に投資すれば、クエリ側の負荷を減らし、実行時間とコストを削減できます。CostBench は、準備コストとクエリ処理コストの合算に対して得られたクエリ速度を自動的に重み付けするスコアを用いて、エンドツーエンドのコストパフォーマンスによって各システムを順位付けします。より高額な構成は、その高コストを正当化できるだけの高速な応答を提供しなければなりません。

測定手法の全容はパート 1 で解説しています。

以下の内訳は、データが到着する間にその優位性がどのように生まれるかを示しています。ClickHouse は、比較対象の中で最も低い準備コスト、最も低いクエリコスト、そして最も短い累積クエリ実行時間を兼ね備えています。

出典:Measurements and methodology

ClickHouse Cloud は、完全な高可用性取り込みサービス全体で、1,132 億行すべてを $28.69 で取り込み、準備しました。ここに示す概要では、ClickHouse の総クエリコストは約 $0.05、累積クエリ実行時間は 1.03 分にとどまり、その間も日次サマリーは RAW データと常に同期されていました。

本番環境における大規模なコスト削減:
Buildkite の移行事例は、この経済性が本番環境でどう活きるかを示しています。ワークロードを ClickHouse Cloud へ移行したことで、イベント取り込み量が 4 倍になったにもかかわらず、純インフラ支出は月間 5 桁ドル(数万ドル)削減されました。

この優位性がどこから生まれるのかを理解するため、受信したイベントの準備から次のクエリへの応答に至るまで、ClickHouse Cloud 内のデータの流れを追ってみましょう。

クエリ対応データへの最速・最低コストの経路 #

リアルタイム分析では、新規データを次のクエリに向けて常に準備完了の状態に保つことが不可欠です。CostBench では、クエリを実行し続けながら、気配値ストリームを取り込み、RAW 履歴を並べ替え、日次サマリーを維持する処理を測定しました。

データ準備における ClickHouse の優位性 #

ClickHouse Cloud は、RAW データが書き込まれた瞬間に日次サマリーもクエリ可能な状態になる、唯一の検証対象システムでした。遅延ゼロを示すグラフの線は、新しく書き込まれた RAW 行が常にサマリーと同期していたことを示しています。

出典:Measurements and methodology

ClickHouse は挿入中に事前集計を更新するため、RAW データとサマリーが同時に進みます。他の検証対象システムでは、RAW データの書き込み後に非同期で事前集計を更新していたため、上記のような遅延が発生しました。

RAW 履歴と日次サマリーの双方をクエリ可能な状態に保ちながらも、最も低い準備コストを実現しました。全 1,132 億行の準備にかかったコストは、ClickHouse Cloud で $28.69 であったのに対し、Snowflake では約 $79、BigQuery(Capacity)では $243、Redshift Serverless では $522、Databricks では $696 でした。

出典:Measurements and methodology

他の検証スタックでは、追加の取り込みサービスやメンテナンスサービスが必要となり、別途料金が発生することも少なくありませんでした。ClickHouse は、列指向ストレージ、並べ替え、事前集計という3 つの準備ステップすべてを同一エンジン内で処理し、その処理も取り込みサービスのコストに含まれています。

優位性を支えるエンジンの内部構造 #

ClickHouse は、受信データをメモリ上に保持している間にソートと事前集計を行うことで、準備のオーバーヘッドを低く抑えています。

受信データをメモリ上でソートおよび事前集計 #

受信データは、直接受け取ったクライアントバッチまたは非同期挿入バッファのいずれかを経由してメモリに展開されます。ClickHouse はまず、RAW テーブルのソートキー(銘柄コードと時刻)に従って RAW 気配値をソートし、インクリメンタルマテリアライズドビューを用いて日次サマリーを計算した上で、サマリーテーブルのソートキー(銘柄と日付)に従ってソートします。その後、双方がソート・圧縮された列指向のデータパートとしてディスクに書き込まれるため、初期準備のための「書き込みと再読み込み」という余分なサイクルを回避できます。RAW データとサマリーは、同一の受信データから足並みを揃えて更新されます。

他の検証パスでは、RAW データの並べ替えや、サマリーの事前集計・並べ替えを、初回の書き込み後に個別の非同期ステージとして実行します。サマリーが更新される前に新しい RAW 行が利用可能になるため、これらのパスでは両者の遅延ゼロを保証できません。 下のアニメーションは、両方のステージが取り込みに追いつかなくなる様子を示しています。

これらのステージではストレージからデータを再度読み出すため、準備処理と I/O が増加します。新しく書き込まれた RAW 行がソート待ちのまま滞留し、ソート済みサマリーはさらに遅れていくことになります。

データがメモリ上にあるうちに準備を行うことで、オーバーヘッドを低く抑えられます。さらに ClickHouse は、その処理の実行を並列化することで処理を加速します。

ハードウェアの限界を引き出す設計 #

ClickHouse は、基盤となるインフラストラクチャが提供するコンピュートを最大限に活用します。 そのエンジンは、ノード、CPU コア、SIMD レーンにまたがって、データの事前準備とクエリ実行の両方を並列化します。まずはデータの準備から見ていき、続いて同じアプローチがどのようにクエリ実行へと受け継がれるかを説明します。

異なるノードは、同期を一切必要とせずに異なる挿入を同時に処理できます。ClickHouse では、同時挿入操作は互いに分離されています。各挿入は新しいデータパートを書き出し、それぞれが独自のスパースプライマリインデックスとメタデータを持ちます。そのためノードは、既存のデータを書き直したり、テーブル全体で共有されるインデックスを更新したりすることなく、データを準備できます。

各ノード内では、ClickHouse は CPU コア間でソートと事前集計を並列化します。集計にはマージ可能な部分集計状態が使用されます。各 CPU コアが独自に行のサブセットを集計でき、それらの状態を結合して正しい結果を生成できます。ClickHouse は、このモデルを 200 以上の集計関数とそのコンビネータに適用しています。取り込み時には、これらの状態が集計テーブルに書き込まれます。具体的な例は、私たちの GROUP BY の解説記事で紹介しています。

各コア内では、ClickHouse は列指向データをバッチ単位で処理し(ベクトル化実行)、SIMD 命令を使用して複数の値に対するサポートされた演算を一度に実行します。

以下のアニメーションは、取り込みノードから 1 つのノードの CPU コアへ、さらに 1 つのコアの SIMD レーンへと拡大して示しています。

ClickHouse は、継続的な挿入と並行して、複数のバックグラウンドパートマージを CPU コア全体で同時に実行します。集計テーブルでは、これらのマージにより異なるバッチの部分集計状態が結合され、挿入時に開始された事前集計が継続されます。これにより、集計処理がクエリ時からバックグラウンドマージ時へと段階的にシフトしていきます。また、各テーブルの ORDER BY 順を維持しながら、生データと集計データをより少数の大きなパートへと統合します。クエリは残りの状態を結合して最新の回答を返すため、最新の生イベントをスキャンして追いつく必要がありません。この設計は、私たちの VLDB アーキテクチャ論文で解説されています。

数字で見るエンジンの性能 #

ベンチマークの実行中、ClickHouse Cloud に組み込まれた高度なダッシュボードを通じて、取り込みサービスのスループット、リソース使用状況、データ削減率、バックグラウンドマージを監視しました。

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 がエンドツーエンドのスコアからデータベースストレージを除外している理由を理解するのにも役立ちます。ベンチマークの短い期間においては、新鮮なデータの取り込みと準備、およびクエリの処理にかかる合計コストと比べて、ストレージが占める割合はごくわずかです。ストレージコストは、保持期間が長期化するにつれて重要性を増します。

圧縮によって生の履歴データを読み取るためのバイト数が削減され、事前集計によって定期的な分析の質問に答えるために必要な行数が削減されます。

4 つの取り込みコアがどのように準備を処理するか(クリックして展開)

取り込み時の CPU 処理の内訳:

取り込み時の CPU 処理において最も大きな割合を占めるのはパースです。ソートが約 19%、事前集計が約 3% を占めます。以下のチャートでは、パース、ソート、事前集計、圧縮、およびその他の取り込み処理を個別に示しています。クライアントは非同期挿入を介して CSV エンコードされたバッチを送信し、パースによってそれらが ClickHouse の型付けされた列指向データに変換されます。「その他の取り込み処理」には、スパースプライマリインデックスとパートメタデータの構築、および設定されている場合はカラム統計とセカンダリインデックスの構築が含まれます。このチャートは取り込み処理を対象としており、バックグラウンドマージは以下で個別に示しています。

サーバー側のパースの削減:

ClickHouse は Native 形式を含む 70 以上の入力フォーマットをサポートしています。Native 形式では、クライアント側で準備された列指向ブロックにより、サーバー側のパースと変換が軽減されます。私たちの FastFormats 調査とインタラクティブダッシュボードでは、フォーマット、バッチ処理、圧縮の影響について詳しく説明しています。

バックグラウンドでの統合と継続的な事前集計:

同じ 4 つのコアにより、毎秒数百万行がマージされました。これらのマージによって、すでに順序付けされた生データのパートが統合され、バッチをまたいで集計データの集計状態の結合が継続されたため、クエリ側に残される処理が削減されました。データセットが増加しても、パーティションあたりのアクティブパートの最大数は約 100 に維持されました。

リソース使用状況:

CPU 使用率は利用可能な 4 コアのうち約 3.1 コアにとどまり、追跡されたメモリはサービスの 16 GiB 容量の範囲内に収まりました。28.69 ドルの準備コストには、両方のノードとそのバックグラウンド処理が含まれます。

出典: 測定値と測定手法

これが実環境にもたらす価値 #

CostBench において、ClickHouse は最も低い準備コストで、集計データを常に取り込み済みの生データと同期した最新の状態に維持しました。ソートされ圧縮された履歴データとコンパクトな集計データにより、後続のクエリにかかる処理が軽減されるため、アプリケーションは最新データから定期的な質問に答えつつ、個別のイベントを詳細に調査することもできます。

実環境における高速な準備:
Appcues は、Snowflake ベースの分析スタックにおける Airflow のロールアップ処理を、挿入時に件数や合計を計算するマテリアライズドビューに置き換えました。これにより Airflow インフラを全廃し、イベントが Appcues に到達してからクエリ可能になるまでの時間を 10 分以上から約 5 秒に短縮しました。

次のセクションでは、そのように準備されたデータがクエリエンジンへと送られる流れを見ていきます。

最も低いコストで最速のクエリ結果を実現 #

効率的な事前準備により、各クエリの背後にある処理負荷が軽減されます。その成果を測定するため、CostBench は負荷環境下でエンドツーエンドの経路をテストし、新しい気配値データが取り込まれ準備される間、各システム上で同じ 4 つの対話型集計クエリを 10 分ごとに、同じ 2 つの選択的なドリルダウンクエリを 1 時間ごとに実行しました。パート 1 ではクエリワークロードの全体像を解説しています。

クエリ処理における ClickHouse の優位性 #

ClickHouse Cloud は、4 つの比較すべてにおいてクエリ実行時間が最も短く、クエリコストも最も低くなりました。

出典: 測定値と測定手法

すべてのシステムでクエリ結果のキャッシュは無効化されていたため、測定されたすべてのクエリが実際に実行されました。継続的な運用環境を反映し、基盤となるデータキャッシュはウォーム状態の維持が許可されました。

集計クエリに関して、Snowflake と BigQuery は事前集計が生データに対して遅れていたため、クエリ実行時によけいな処理が発生しました。最新の回答を返すために、集計データとより新しい生データの行を結合する必要があったためです。Databricks と Redshift は最後に完了した集計データを読み取っていたため、より最近の気配値データが結果に含まれない可能性がありました。ClickHouse の事前集計は常に最新であったため、集計クエリは準備された集計データを直接読み取ることができました。

出典: 測定値と測定手法

約 1,000 億行の生データにおいて、図示された集計クエリが最新の回答を返すまでにかかった時間は、Snowflake で 16 秒、BigQuery で 4.6 秒だったのに対し、ClickHouse では約 15 ms でした。

その優位性を生み出すエンジンの内部構造 #

事前準備によって、各クエリが処理しなければならないデータ量が削減されます。事前集計により集計クエリはコンパクトな集計データを読み取れるようになり、ソート順によって適切なフィルタを持つクエリは無関係な範囲をスキップできます。データ準備と同様に、ClickHouse は残りの処理を並列化することでクエリを高速化します。

ノード間では、単一のクエリが複数ノードの CPU コアを使用できます。関与するノードは異なる行のサブセットを同時に処理し、それらの部分結果を 1 つの回答へと結合できます。

各ノード内では、ClickHouse は処理対象の行を利用可能な CPU コアに分割し、各コアが自身の受け持ち部分を同時に処理できるようにします。

ClickHouse は、200 以上の集計関数とそのコンビネータに対して、マージ可能な部分集計状態を使用します。各 CPU コアは独自に行のサブセットを集計でき、それらの状態が結合されて正しい結果が得られます。生データへのドリルダウンではクエリ時にこれらの状態が構築され、集計データに対するクエリでは取り込みやバックグラウンドマージの間に準備済みの状態が結合されます。私たちの GROUP BY の解説記事では、具体的な例とともにその仕組みを説明しています。

各コア内では、ClickHouse はベクトル化実行を通じて列指向データをバッチ単位で処理し、CPU キャッシュの局所性を高めます。SIMD 命令によって、複数の値に対するサポートされた演算が一度に実行されます。

以下のアニメーションは、同一データがノード間、次いで 1 つのノードの CPU コア間、最後に 1 つのコア内の SIMD レーン間へと分割されていく様子を示しています。

各コアでの集計処理は、低レベルの選択からも恩恵を受けています。ClickHouse は、グループ化キーとデータに基づいて 30 以上の専用ハッシュテーブルバリアントから最適なものを選択します。Alexey による Building for Fast の対談では、ハッシュテーブルの容量予測など、そうした選択の背後にある試行錯誤が紹介されています。

ClickHouse がクエリ処理をさらに削減する仕組み(クリックして展開)

長年にわたり、ClickHouse は I/O を徹底的に削減するために何層もの最適化を導入してきました。これらの手法が、そのスピードと効率性の基盤となっています。

準備段階で確立された生データと集計データの順序付けにより、ClickHouse のスパースプライマリインデックスは無関係な範囲をスキップできます。プロジェクションは、代替のデータ順序と独自のインデックスを提供することで、このアプローチを拡張します。

スキップ処理は実行中も継続します。PREWHERE は、追加のカラムがロードされる前にフィルタを適用します。Top-N などの一般的なクエリパターン向けの最適化により、ORDER BY … LIMIT に必要な処理がさらに削減され、結果を改善する見込みのないデータがスキップされます。遅延実体化は、結果の行が確定するまで出力カラムの読み取りを遅延させることができます。

また、ClickHouse はメタデータやデータの反復取得、カラムの伸張・デコード、同じフィルタの重複評価を回避するために、複数レベルのキャッシュを活用しています。

これらは ClickHouse のクエリ最適化のほんの一部にすぎません。統計情報がクエリプランニングを誘導し、クエリの書き換えによって実行前の冗長な計算が排除されます。その他の手法として、頻繁に使用される式の JIT(Just-In-Time)コンパイルや、追加のソートを行わずに ORDER BY を満たしたり集計を簡素化したりするための既存のデータ順序の活用などが挙げられます。私たちの VLDB 研究論文では、これらの手法とエンジン全体のアーキテクチャについてさらに詳しく説明されています。

数字で見るエンジンの性能 #

クエリ実行中の読み取りサービスについても(ClickHouse Cloud に組み込まれた高度なダッシュボードを通じて)監視し、CPU やメモリの使用量とともに処理スループットを追跡しました。

前述のとおり、ClickHouse Cloud は 4 つの比較すべてにおいて、累積クエリ実行時間が最も短く、クエリコストも最も低くなりました。 クエリコンピュートは可能な限り揃えており、差異がある場合は、追加のクエリ速度が追加のコンピュートコストに見合っているかをスコアが示しています。

ClickHouse は、16 CPU コアと 64 GiB のメモリを備えた独立した単一ノードの読み取りサービスを使用し、新しい気配値データの取り込みと準備が継続している状況でこれらの結果を達成しました。1,132 億件の気配値において、4 つのインタラクティブ集計クエリの平均応答時間は約 15 ms であり、2 つの生データドリルダウンの平均は約 1 秒でした。

全履歴を対象とする 2 つの集計 A3 と A4 は、準備されたサマリーから回答し、その実効集計スループットは毎秒約 6 兆件の気配値に達しました。このレートは、クエリ実行 1 秒あたりにサマリーが表す生の気配値履歴の件数を測定したものです。

出典: 測定結果と測定方法

次のグラフは、それらのクエリ実行を支える並列データ処理スループットを示しています。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 コア数に応じてどのようにスケールするかをテストするため、各クエリで使用可能な CPU コアを 2、4、8、16、30、59 個にして、2 つの生データドリルダウンクエリを再実行しました。1,132 億件の気配値はすべて事前にロードされ、準備済みでした。これは、上記の継続的な取り込みの測定とは別の実験です。

59 コアにおいて、スループットはホットキャッシュで約 15.56 GB/s、コールドキャッシュで 9.85 GB/s に達しました。ホットでは通常のデータキャッシュとクエリ条件キャッシュを有効にし、コールドではデータキャッシュをバイパスしてクエリ条件キャッシュを無効にしています。どちらの場合も、クエリ結果のキャッシュは無効のままです。高速化は完全に線形ではありません。部分的な結果の統合には、そのマージ処理が並列化されている場合でもオーバーヘッドが生じ、一部のクエリステージは完全には並列化できないためです。

出典: 測定結果と測定方法

NVIDIA Vera 上での並列実行:
同じ並列実行モデルにより、より大規模なマシンも自動的に活用されます。176 CPU コアを搭載したデュアルソケットの NVIDIA Vera システムにおいて、ClickHouse エンジンはこれまで私たちが測定した中で最速の ClickBench 結果を記録しました。Vera のパフォーマンス解説記事では、CPU 負荷の高い集計処理が 1 コアの場合と比べて 176 コアで約 164 倍高速に実行されたことを示しています。これは、完全に線形なスケーリングによる 176 倍の高速化に近い数値です。部分的な結果の統合にはオーバーヘッドが伴い、一部のクエリステージは完全には並列化できないためです。

別のフィルタリングテストでは約 900 GB/s を処理し、それ以上のスケーリングはメモリ帯域幅によって制限されました。この解説記事では、SIMD が各コア内のサポート対象オペレーションをどのように高速化するかについても解説しています。

実際の環境で何をもたらすか #

CostBench では、単一の 16 コアのクエリノード上で、新しいデータが届き続ける中でも CPU に余裕を残しながら、ミリ秒単位の集計応答とおよそ 1 秒のドリルダウンが実証されました。また、ClickHouse は 4 つの比較の中で最も低いクエリコストと最も短い累積実行時間を記録し、増え続ける履歴データに対する頻繁な分析クエリの実用性を証明しました。

実際の環境での高速なクエリ速度と低コスト:
Mintlify は、ClickHouse Cloud のインクリメンタルなマテリアライズドビューを使用して、エンドユーザー向けドキュメントの分析機能を提供しています。PostHog ベースの構成から移行した後、ダッシュボードのロード時間は数十秒から 1 秒未満へと短縮され、エンジニアリングマネージャーの Nicholas Khami 氏は同じワークロードのコストが約 60% 削減されたと見積もっています。これは優れたカスタマーエクスペリエンスにつながり、Net Promoter Score が 30% 向上するなど、高い満足度が示されています。

大規模環境で複利的に高まるメリット #

ClickHouse エンジンは、新しく到着したデータのバッチを効率的に準備することで各クエリの処理量を減らし、残りの処理も効率的に実行します。

効率的なデータ準備と高速なクエリ実行の双方がエンドツーエンドの 1 ドルあたりの性能を向上させるため、それらのメリットは相乗的に高まります。

データ準備とクエリ実行の相互強化 #

以前のクエリ側の比較は事前に準備されたデータから開始し、ClickHouse が 23 倍〜101 倍の 1 ドルあたりの性能上の優位性を持つことを測定しました。CostBench では、より広範な継続的取り込みパスをテストし、データ準備とクエリ提供を同時に実行した状態で 412 倍〜1,996 倍の優位性を測定しました。

出典: 測定結果と測定方法

取り込みとクエリのコンピュートを独立してスケーリング #

ClickHouse Cloud は、この高効率なエンジンに伸縮性とワークロードの分離をもたらします。SharedMergeTree によりテーブルストレージとコンピュートが分離され、Shared Catalog がデータベースのメタデータを一元化し、分散キャッシュによってコンピュートが変更されてもホットデータを再利用できます。この基盤により、キャパシティが変化しても、ステートレスなコンピュートノードが保存データを再分散することなく同じテーブルにアクセスできます。

コンピュート・コンピュート分離により、取り込み、ダッシュボード、調査処理を、それぞれ独自の CPU コアとメモリを備えた独立した規模のサービスで実行できます。CostBench では、取り込みサービスとクエリサービスにこの分離を使用しました。

CostBench の構成にとどまらず、On-Demand Compute を利用すると、対象となるクエリは既存のサービスを通じて一時的なステートレスワーカーをリクエストできます。これらのワーカーは、サービスのサイズを恒久的に増やすことなく、一時的な追加クエリキャパシティを提供します。

また、データ共有アーキテクチャは、クエリ処理を分散させる複数の手法をサポートしています。

• パラレルレプリカ: ノード間で読み取りと集計を分散します。

• インデックスシャーディング: ノード間でインデックス解析を分散します。

• マルチステージ実行: 大規模な結合や高カーディナリティの集計をノード間で動的に分散します。

取り込みノード、読み取りノード、一時的なステートレスクエリワーカーのすべてが、同じ ClickHouse エンジンを実行します。

単一のエンジンが分析パス全体を統合(クリックして展開)

データ準備(挿入時変換を含む)、並列化されたクエリ処理、および上記の分散実行メカニズムが、エンジンに組み込まれています。

ClickHouse Cloud は、共通の SQL 関数、データ型、実行機構を維持しながら、ワークロードごとにコンピュートを独立してスケールできます。開発者にとっては、分析パス全体を理解しデバッグするための一貫した構成要素が提供されることになります。共有エンジンコードの改善は、それを利用するすべての役割にメリットをもたらします。

以下のアニメーションは、共有データとキャッシュの上で、取り込みとクエリのコンピュートが独立して拡大・縮小する様子を示しています。クエリ側の破線のワーカーボックスは、On-Demand Compute の一時的なステートレスワーカーを表しています。

単一の並列クエリはノード間でどのようにスケールするか？(クリックして展開)

下のグラフは、フルロードされた英国の不動産価格データセットに対する別の実験を示しています。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 ドルあたりの性能スコアに含めています。

出典: 測定結果と測定方法

実際の環境での柔軟なスケーリング:
HighLevel は、9 万以上の代理店と 300 万の中小企業にサービスを提供するマーケティングプラットフォーム全体で、その柔軟性を活用しています。リードの活動履歴、ワークフローのログ、通知、収益分析に ClickHouse Cloud を利用しています。ストレージとコンピュートを分離しているため、需要の増加に応じてクエリキャパシティを追加できます。スタッフエンジニアの Pragnesh Bhavsar 氏は次のように説明しています。「トラフィックが増加したら、レプリカを追加するだけで対応できます」

リアルタイムアプリケーションで実現すること #

効率的なデータ準備と並列クエリ実行により、アプリケーションは最新の取り込みデータに基づいた回答をミリ秒単位で取得し、その回答を利用して次の行動を決定できます。それらの回答はアプリケーションの応答制限時間内に届く必要があり、履歴データが増大する中で繰り返し要求されても経済的でなければなりません。

CostBench の株式市場の気配値データセットが、その具体例となります。取引を承認する前にリスクを確認する取引アプリケーションを想定してみましょう。直近の市場の動きによって判断が変わる可能性があるため、分析クエリには最新の取り込み気配値が必要です。そのクエリの許容時間が 100 ms だとします。気配値の履歴が増えても、この制限時間は変わりません。

以下のアニメーションは、CostBench で測定されたサマリーの鮮度と集計クエリのレイテンシを統合したものです。新しい気配値データが届き続ける中で、応答時間をこの想定制限時間と比較しています。例として示されている集計クエリにおいて、1,000 億件の気配値データに対して、最新データに基づく回答と 100 ms の許容時間内での応答を両立できたのは ClickHouse だけでした。

出典: 測定結果と測定方法

1,000 億行の時点で、ClickHouse Cloud は約 15 ms でクエリを返し、日次サマリーは取り込まれた生データと一致した最新状態に保たれていました。高い鮮度と低レイテンシが揃うことで、アプリケーションが次の判断を下すために必要な分析の根拠が得られます。

そうした判断によってユーザーやワークフロー全体でクエリが繰り返し実行される場合、その経済性が重要になります。最新のサマリーによって繰り返される質問への回答コストが低く抑えられる一方、整列された生データの履歴によって詳細な調査が可能になります。準備コストとクエリコストの低さにより、アプリケーションの成長に伴ってもその両方を実用的な状態に維持できます。

実際の環境でのリアルタイムな意思決定:
Buildkite では、次の CI ビルドをどのように実行するかを決定するために分析クエリが役立てられています。同プラットフォームは年間 1 兆件のテスト実行結果を取り込み、インテリジェントなテスト分割、不安定なテスト(flaky test)の検出、テスト履歴のインタラクティブな分析に ClickHouse Cloud を使用しています。頻出する質問のためにマテリアライズドビューが統計情報を維持しつつ、詳細な調査のために生データも利用可能なまま保持されます。それらのクエリはクリティカルパス上に位置しており、迅速に回答を得ることで数千台のマシンがテストを早期に完了できるようになり、次のビルドを高速化しています。

エージェント型分析の時代に向けた設計 #

エージェントが人に代わってデータベースに問い合わせを行うケースが増加しており、1 つひとつの回答が、エージェントが次に何を調査すべきかを決定づける材料となります。

データベース研究者であり、ClickHouse Labs の VP を務める Andy Pavlo は、「データベースに届くクエリの量と数が、10 倍から 100 倍に増加する可能性がある」と予想しています。

この増加は、分析パス全体に負荷をかけます。エージェントが追加の質問を行い、同時に調査を実行している間も、到着するイベントをクエリ可能な状態にし続けなければなりません。

セキュリティチームが進行中のインシデントを調査するのを支援するエージェントを考えてみましょう。エージェントは最近のアクティビティを過去のパターンと比較し、影響を受けたアカウントを特定して、個々のイベントを精査します。調査中に状況が変化する可能性があるため、追加の各クエリは新たに取り込まれた証跡にアクセスできる必要があります。

ClickHouse の継続的なデータ準備によってサマリーが取り込み生データと同期した最新状態に保たれる一方、整列された生データ履歴が詳細な調査を支えます。エージェントは、新たな証跡が到着するのに応じてサマリーと個別のイベントの間を行き来できます。

1 つひとつの回答が次の質問を左右するため、データベースのレイテンシが調査ループに直結します。典型的な ClickHouse ワークロードでは、各クエリの所要時間はモデルの一般的な Time to First Token よりも短くなります。つまり、エージェントはデータベースの処理を実質的に待つ必要がありません。

また、データベースコストには、結論に至るまでに必要なすべてのクエリが含まれます。これらのコストは追加の質問や並行した調査の全体で蓄積されるため、エージェントの利用が増加するにつれて、効率的なクエリ実行の価値は一段と高まります。

1 日あたり 1 ペタバイト以上の取り込み量であっても、エージェントには最新の証跡と、高速で低コストな追加クエリが不可欠です。ClickHouse の継続的なデータ準備は各回答の背後にある処理量を削減し、ClickHouse Cloud により、イベント量と調査需要の増加に合わせて取り込みとクエリのキャパシティを独立してスケールさせることができます。ClickHouse はこれを正しく実現しています。

実際の環境でのエージェント調査:
Artemis は ClickHouse Cloud を使用して、受信するセキュリティログを継続的に検査しつつ、調査エージェントが過去データと照合して不審なアクティビティを探索できるようにしています。マテリアライズドビューを通じて頻繁にクエリされるフィールドを抽出することで、ある調査検索の所要時間を 12 秒から 200 ミリ秒へと短縮しました。また、検知ルールを共有スキャンに統合することで、100 以上のルールの本番バッチ処理を 1 秒未満で実行できるようにしました。データを効率的に準備し、重複するクエリ処理を削減することで、タイムリーな調査と継続的な検知の両方が支えられています。

大規模環境で費用対効果を発揮するリアルタイム分析 #

到着するデータをクエリ可能な状態に保ち、効率的に回答し、需要に応じてスケールすることは、分析パス全体にわたって密接に関連した要件です。効率的なデータ準備とクエリ実行が組み合わさることで、CostBench において ClickHouse Cloud は比類なきエンドツーエンドの 1 ドルあたりの性能を達成し、4 つの比較全体で 412 倍〜1,996 倍優れていました。リアルタイムアプリケーションやエージェントにとって、リクエストが増加するにつれて、その効率性の価値はますます大きくなります。

「ClickHouse に対抗できるものは他に存在しない」
— Alon Tal 氏(Tesla 社 シニアスタッフソフトウェアエンジニア)

ご自身のワークロードで ClickHouse Cloud を試す。