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

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

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

同時実行性の欠如

スケーリングの難しさ
StarRocks vs. ClickHouse
2.2x
2.3x
#1
Denormalized Tables(非正規化テーブル)からの解放
JOINリレーションはモダンな分析の基盤ですが、その一方でクエリパフォーマンスにおける課題ともなります。
ClickHouse はこの課題を回避するために、単一テーブルでのクエリ性能に注力してきました。その結果、ClickHouse ユーザーはデータ投入前に正規化されたテーブルを単一のフラットなテーブル、すなわち 非正規化テーブル(denormalized tables) に変換する必要があります。このステップは分析の柔軟性を損なうだけでなく、データ処理パイプラインの複雑化も招きます。
StarRocks は、分散JOINアルゴリズムのネイティブサポートとコストベースオプティマイザにより、単一テーブル・複数テーブルJOINの両方においてクラス最高のクエリパフォーマンスを実現します。StarRocks を使えば、ユーザーは正規化されたテーブルをそのまま保持し、リアルタイムでJOIN処理を行うことができ、データ投入パイプラインを簡素化し、データの鮮度を高め、ETLコストの削減にもつながります。
さらに移行すべき優れた理由

Mutable Data を受け入れる
Mutable Data はビジネス活動において一般的に発生する副産物です。これは、基盤となるデータパイプラインの不具合によって生じることもあれば、単に通常のビジネスロジックの一部であることもあります。
ClickHouse は他の多くの分析用データベースと同様に、UPDATE
や DELETE
操作をネイティブにはサポートしていません。その代わりに、ALTER TABLE
を非同期で実行する MUTATION
操作を提供しています。しかし、ClickHouse の非同期 MUTATION
操作は、頻繁なデータ取り込みが発生する場合にクエリレイテンシの劣化や不安定性を引き起こす可能性があり、データに変更が発生するリアルタイム分析には適していません。
StarRocks の Primary Key テーブル は、可変データ(Mutable Data)を伴う分析処理にネイティブで対応するよう設計されています。プライマリキーインデックスを用いることで、データの変更は取り込み時に処理され、ユーザーには一切妥協のないクエリパフォーマンスを提供します。

分析基盤をシームレスにスケール
ClickHouse のパフォーマンスは、集計クエリを実行している間に限って維持されます。しかし、クエリが複雑になったり、高い同時実行性が求められるシナリオになると、パフォーマンスは大きく低下します。
StarRocks にはこうした制約がありません。超高速な実行エンジンと、組み込みのコストベースオプティマイザなどの高度な機能群により、StarRocks はクエリ結果のキャッシュや保存済み結果の再利用によって処理を高速化します。これにより、あらゆるシナリオでの同時実行性のスケーリングに最適です。
StarRocks の マテリアライズドビュー(Materialized View / MV) は、インクリメンタル更新(同期型MVのみ対応) や クエリの自動書き換え に対応しており、シームレスに機能します。
StarRocks の Query Cache は、実行済みクエリの中間計算結果を保存することができます。意味的に(部分的に)等価な新しいクエリは、保存されたキャッシュ結果を再利用することが可能です。
ClickHouse と StarRocks の比較
項目
|
|
|
アーキテクチャ |
![]() |
![]() |
SQL 構文サポート |
![]() |
|
リアルタイム更新 |
![]() 非同期更新、リアルタイムではない |
|
同時実行性のサポート |
![]() |
|
サードパーティ依存 |
![]() |
|
Cost based optimizer |
![]() |
|
分散 JOIN |
![]() |
|
データレイククエリサポート |
![]() |
|
フェデレーテッドクエリ対応 |
![]() |
|
注目の導入事例

エンジニアに相談する
当社のソリューションアーキテクトや経験豊富なエンジニアが、皆様のご質問にお答えし、ニーズや分析シナリオに合わせたパーソナライズされたデモのご提案も可能です。お気軽にご相談ください。