なぜユーザーは ClickHouse から StarRocks へ移行しているのか

過去10年間、ClickHouse は高速な分析用データベースのリーダーとして広く認識されてきました。しかし、時代は変わりつつあります。ますます多くのユーザーが、特に現代の分析シナリオにおいて ClickHouse の限界を認識し始めています。これらの限界には以下のようなものがあります:
no-table

JOINされたテーブル
の非対応

ClickHouse は複数のテーブルをJOINする処理が苦手で、上流での非正規化を必要とします。これにより、分析の柔軟性が失われ、管理も複雑になります。
no-change

データ更新へ
の対応が限定的

ClickHouse は、データストリーム内に更新レコードが存在しない場合に限り、リアルタイム分析に対応できます。データ更新の頻度が増すにつれて、ClickHouse のパフォーマンスは不安定になり、大幅に低下します。
no-concurrency

同時実行性の欠如

ClickHouse は同時セッション数が限られている場合には高いパフォーマンスを発揮します。しかし、クエリが複雑になったり高い同時実行性が求められたりする場面では、必要とされる高度な処理能力が不足しており、十分なパフォーマンスを発揮できません。
no-scale

スケーリングの難しさ

ClickHouse は単一サーバーでのクエリ性能には優れていますが、クラスタをスケーリングする際にはデータの手動リバランスが必要となり、運用者にとって大きな負担となります。

StarRocks vs. ClickHouse

2.2x

ワイドテーブルシナリオにおける優れたパフォーマンスを標準で提供

2.3x

低カーディナリティシナリオにおける優れたパフォーマンス

#1

クラス最高のマルチテーブルJOINパフォーマンス

Denormalized Tables(非正規化テーブル)からの解放

JOINリレーションはモダンな分析の基盤ですが、その一方でクエリパフォーマンスにおける課題ともなります。

 

ClickHouse はこの課題を回避するために、単一テーブルでのクエリ性能に注力してきました。その結果、ClickHouse ユーザーはデータ投入前に正規化されたテーブルを単一のフラットなテーブル、すなわち 非正規化テーブル(denormalized tables) に変換する必要があります。このステップは分析の柔軟性を損なうだけでなく、データ処理パイプラインの複雑化も招きます。


StarRocks は、分散JOINアルゴリズムのネイティブサポートとコストベースオプティマイザにより、単一テーブル・複数テーブルJOINの両方においてクラス最高のクエリパフォーマンスを実現します。StarRocks を使えば、ユーザーは正規化されたテーブルをそのまま保持し、リアルタイムでJOIN処理を行うことができ、データ投入パイプラインを簡素化し、データの鮮度を高め、ETLコストの削減にもつながります。

さらに移行すべき優れた理由

ますます多くの ClickHouse ユーザーが StarRocks へ移行しています。StarRocks によって、これらの元 ClickHouse ユーザーは大幅なクエリパフォーマンスの向上に加え、以下のような追加のメリットも享受しています:
management

Mutable Data を受け入れる

Mutable Data はビジネス活動において一般的に発生する副産物です。これは、基盤となるデータパイプラインの不具合によって生じることもあれば、単に通常のビジネスロジックの一部であることもあります。

 

ClickHouse は他の多くの分析用データベースと同様に、UPDATEDELETE 操作をネイティブにはサポートしていません。その代わりに、ALTER TABLE を非同期で実行する MUTATION 操作を提供しています。しかし、ClickHouse の非同期 MUTATION 操作は、頻繁なデータ取り込みが発生する場合にクエリレイテンシの劣化や不安定性を引き起こす可能性があり、データに変更が発生するリアルタイム分析には適していません。

 

StarRocks の Primary Key テーブル は、可変データ(Mutable Data)を伴う分析処理にネイティブで対応するよう設計されています。プライマリキーインデックスを用いることで、データの変更は取り込み時に処理され、ユーザーには一切妥協のないクエリパフォーマンスを提供します。

scale

分析基盤をシームレスにスケール

ClickHouse のパフォーマンスは、集計クエリを実行している間に限って維持されます。しかし、クエリが複雑になったり、高い同時実行性が求められるシナリオになると、パフォーマンスは大きく低下します。


StarRocks にはこうした制約がありません。超高速な実行エンジンと、組み込みのコストベースオプティマイザなどの高度な機能群により、StarRocks はクエリ結果のキャッシュや保存済み結果の再利用によって処理を高速化します。これにより、あらゆるシナリオでの同時実行性のスケーリングに最適です。


StarRocks の マテリアライズドビュー(Materialized View / MV) は、インクリメンタル更新(同期型MVのみ対応) や クエリの自動書き換え に対応しており、シームレスに機能します。


StarRocks の Query Cache は、実行済みクエリの中間計算結果を保存することができます。意味的に(部分的に)等価な新しいクエリは、保存されたキャッシュ結果を再利用することが可能です。

ClickHouse と StarRocks の比較

モダンなエンタープライズ分析ニーズに対応するために設計された StarRocks は、機能性とパフォーマンスの両面で優れています。ClickHouse はそのすべてを提供することはできません。
項目

ClickHouseClickHouse

 starrocksStarRocks

アーキテクチャ

yesレガシーな scatter-gather アーキテクチャ yesモダンな MPP アーキテクチャ

SQL 構文サポート

yes一部の SQL 構文のみ対応

yes完全な SQL 構文に対応

リアルタイム更新

no

非同期更新、リアルタイムではない

yes同期されたリアルタイム更新に対応

同時実行性のサポート

yes
同時ユーザー数に制限あり

yes10,000 QPS 以上の高い同時実行性

サードパーティ依存

yes
ZooKeeper に依存した運用が必要

yesサードパーティへの依存なし

Cost based optimizer

 
no
非対応
 

yes組み込みの Cost Based Optimizer

分散 JOIN

no
非対応

yes分散 JOIN に対応

データレイククエリサポート

no
限定的なデータレイククエリ対応

yesHive、Hudi、Iceberg、Delta に対応

フェデレーテッドクエリ対応

no
非対応

yesHive、MySQL、Elasticsearch、JDBC ソースとのフェデレーテッドクエリに対応