4.8万
最近、リアルタイム分析をめぐる議論が活発になっています。長年、この領域はしばしば「ニッチなユースケース」として軽視され、限られた一部のオペレーショナルなワークロードや顧客向けワークロードにしか関係しないと見なされてきました。しかし私たちは常に違う考えを持っていました。
顧客向け分析、オブザーバビリティ、不正検知、業務アプリケーション、そしてAIエージェント。これらはすべて、新鮮なデータと低レイテンシのクエリに依存しています。
ClickHouseと私たちの顧客が長年にわたって定義してきたこのカテゴリーを、ようやく他社も認識し始めたようです。これは、オープンソースプロジェクトから始まり、現在では4,000社を超える顧客とARR 2億5,000万ドル超へと成長したClickHouseの歩みを物語っています。
今こそ、私たちが重要だと信じている2つの原則 ― オープン性と、リアルタイム分析データベースとは何かという明確な定義 ― を改めて見つめ直す良い機会ではないでしょうか。
リアルタイムをうたうなら、本物のベンチマークを
データ業界はこれまで、オープンなベンチマークから多くの恩恵を受けてきました。ClickBench、CostBench、PostgresBench、TPCベンチマーク、あるいはコミュニティ主導のテストなど、パフォーマンスに関する主張を第三者が独立して検証できるとき、顧客は最も恩恵を受けます。
有用なベンチマークとは、何を測定しているのかが透明であり、誰でも再現可能で、結果が得られた条件が明確であることです。そうでなければ、意味のある測定値とマーケティング上の主張とを区別することが難しくなります。
私たちは、ベンチマークはオープンで、透明性があり、再現可能であるべきだと考えています。ClickHouseのすべてのベンチマーク ― ClickBench、PostgresBench、JSONBench、そして最近発表したCostBench ― は公開されており、再現可能です。専用のベンチマークページで方法論、データセット、クエリ、結果を確認し、ご自身で再現していただけます。
これはリアルタイム分析において特に重要です。なぜなら、ベンチマーク結果は実際に何を測定しているかによって大きく変わるからです。制御された条件下で同程度のレイテンシを示す2つのシステムが、本番環境では全く異なる挙動を見せることもあります。
静的なデータセットに対してサブ秒のクエリを示すベンチマークは有用ですが、それは、新しいデータが継続的に到着している場合、ワーキングセットがメモリを超える場合、あるいは数百・数千の同時クエリがリソースを奪い合う場合に、システムがどう振る舞うかを必ずしも示してはくれません。
リアルタイム分析への注目が高まるにつれ、業界全体が、オープンで再現可能であり、何を測定しているかを明確にしたベンチマークへとさらに向かっていくことを期待しています。
リアルタイム分析データベースを本当に成り立たせるものは何か?
このワークロード向けのシステムを構築してきた私たちの経験から学んだのは、本番環境での成否を決める多くの特性こそが、ベンチマークから最も省略されやすい要素だということです。鮮度、継続的なインジェスト、同時実行性、変換レイテンシ、そして大規模でも維持される効率性 ― これらはステージ上の1枚のチャートにきれいに収まることはほとんどありませんが、本番環境に到達したシステムが成功するか失敗するかを左右することが多いのです。
だからこそ、リアルタイム分析をどうベンチマークすべきかだけでなく、リアルタイム分析データベースに実際に何ができるべきかを問う価値があります。ちょうど最近、私たちはこの問いを深く掘り下げました。要約すると、リアルタイム分析能力をうたうあらゆるプラットフォームは、次のシンプルな問いに答えられる必要があります。
インジェストはクエリ性能を損なわずにスケールするか?
継続的な書き込みが、クエリレイテンシまで引きずり下ろしてはなりません。実際にはこれは、読み取りパスから分離されたリソース上で動作可能なインジェストパスと、書き込み側が増えてもテールレイテンシを抑えられる同時実行モデルを意味します。たとえばClickHouseは、楽観的並行制御ではなくKeeperを介したコンセンサスベースの調整を使用しています。これにより書き込みごとにわずかな調整コストが発生しますが、リアルタイムワークロードに見られる高いインサート同時実行性のもとでもテールレイテンシを予測可能に保ちます。
データは書き込まれてから1〜2秒以内にクエリ可能か?
実世界のスケールにおける現実的な目標は、ミリ秒から数秒程度の遅延であり、その間にカタログやマニフェストの更新を挟まないことです。
変換はスケジュール実行ではなく、インクリメンタルに更新されるか?
マテリアライズドビュー、ロールアップ、事前集計(ClickHouseではAggregatingMergeTreeを使用)は、一定間隔ではなく、各インサートとともに更新されるべきです。これにより即座に反映され、データ可用性に遅延が生じることを防ぎます。
書き込み時処理と読み取り時処理のどちらに寄せるかを選べるか?
ワークロードごとに望ましいトレードオフは異なります。あるケースでは、書き込み時にインデックスや集計を構築し、最新のクエリが即座に高速化されることを望みます。別のケースでは、インジェストのスループットを最大化し、バックグラウンド処理に追いつかせたいと考えます。リアルタイムプラットフォームは、その選択を強制せずに提供すべきです。そして、インデックスのメンテナンスがインジェストをブロックしてはなりません。新しいデータは、インデックスが完全に構築されているかどうかに関わらず、コミットされた瞬間にクエリ可能であるべきです。
単一のエンジンですべてのワークロードを扱えるか?
テキスト検索、ベクトル類似性検索、JSON、構造化分析。これらは同じストレージとクエリエンジンの上に存在すべきであり、それぞれが独自の鮮度の下限を持つ4つの疎結合システムに分散すべきではありません。
性能はキャッシュされたベンチマークではなく、ホットなデータで示されているか?
どのプラットフォームに対しても問うべき現実的な質問は、昨日のテーブルに対する繰り返しクエリがどれだけ速いかではなく、1秒前に到着したデータに対するクエリがどれだけ速いかです。前者の数字こそが、本番環境の姿です。
リソース効率は規模が大きくなっても維持されるか?
リアルタイムシステムは、インジェスト量、クエリ同時実行性、保持期間が拡大しても効率を保つ必要があります。重要なのは、性能がワークロードに対して線形にスケールするのか、それともトラフィックが増えるにつれてレイテンシとコンピュートコストが不釣り合いに悪化し始めるのかという点です。
これらの要件に共通するのは、リアルタイム分析は単にオンにできる機能ではないということです。それは、インジェスト、ストレージ、変換、クエリにわたるシステム全体で一貫して下されなければならない設計上の意思決定の集合です。プラットフォームは、このワークロードのために設計されているか、あるいは懸命に近似しようとしているかのどちらかなのです。
リアルタイム分析の本格化
問うてみる価値がある問いの一つは、なぜリアルタイム分析が突如として注目の的となったのかということです。複数のトレンドが寄与していますが、私たちはエージェント型ワークロードの台頭が大きな要因だと考えています。エージェントは人間とは異なる方法でデータを消費します。より多くのクエリを発行し、継続的に動作し、意思決定のために新鮮なコンテキストに依存します。組織がエージェントを多数展開するにつれ、低レイテンシ、高い同時実行性、新鮮なデータの組み合わせは、贅沢品ではなく前提条件になりつつあります。
このカテゴリーが進化し続ける中で、私たちは2つのことが標準となることを期待しています。第一に、顧客が現実的な条件下でパフォーマンスに関する主張を独立して評価できる、オープンで再現可能なベンチマーク。第二に、単一のレイテンシ数値を超えて、リアルタイム分析が実際に求めるものについての共通理解です。
イエローカラーの会社として、私たちは長年にわたりリアルタイム分析をリードしてきており、それを基盤的なワークロードであると信じています。
他の色の会社もようやくそれを認識し始めたのを見るのは、嬉しいことです。
