StarRocksとは？MPP列指向の仕組みとテーブル設計・ClickHouse比較で採用判断を解説【2026年版】

StarRocksは、列指向ストレージとベクトル化実行を組み合わせ、多表結合を含む分析クエリを秒未満で返すことを狙ったMPPデータベースです。OLAP分析の器としては後発にあたりますが、集計済みのキューブを作らずに生データへ直接問い合わせる方向へ振り切っている点と、主キーテーブルで更新をそのまま受けられる点が既存のDWHと異なります。Linux Foundationのプロジェクトとして Apache License 2.0 で公開され、2026年8月時点の系列は4.0系。この記事では、FE・BE・CNのノード構成、4つのテーブルタイプ、プレフィックスインデックスの設計、6つのロード方式、External Catalogによるレイクハウス参照までを実装の解像度で追い、ClickHouseやApache Doris、クラウドDWHとの使い分けと見送り基準まで示します。

まとめ｜StarRocks採用の可否を分ける3条件と最初に決める構成

StarRocksが噛み合うのは、次の3つが揃った場合です。第一に、単表の集計ではなく複数テーブルの結合を含む問い合わせが分析の主体であること。第二に、参照系のデータに更新や削除が継続的に混ざること。第三に、応答時間の要件が秒未満から数秒で、同時実行数が数十以上に達すること。3つ目が緩いなら、バッチ集計を前提にしたクラウドDWHのほうが運用の手間は少なく済みます。

導入時に最初に決めるのは2点です。shared-nothingとshared-dataのどちらで組むか、そしてテーブルタイプに何を選ぶか。前者はコスト構造とスケールの単位を決め、あとから移すには再構築が要ります。後者は更新の受け方を決める項目で、主キーテーブルを選ぶかどうかでメモリ設計まで変わります。この2つを詰めずにデータを入れ始めると、性能が出ない原因の切り分けができません。

見送りが妥当なのは、対象データが数百GBに届かず、問い合わせが日次のレポート生成に限られ、運用できる人員が1人という場合です。この規模ではノードを分散させる意味が薄く、既存のDWHやPostgreSQL系の拡張で足ります。判断の分岐は第4章に条件付きで整理しました。

サブ秒応答を支えるMPP列指向エンジンとFE・BE・CNのノード構成

StarRocksの性能特性は、ストレージ形式と実行エンジン、そしてノードの役割分担の3層で決まります。ここを押さえておくと、遅いときにどこを疑うかの見当が付きます。

列指向ストレージとベクトル化実行とCBOが効く問い合わせの型

列指向のストレージでは、同じ型の値が連続して並びます。この並びが生む効果は2つ。1つは圧縮率で、辞書符号化やランレングス符号化が効きやすくなり、ディスクから読む量そのものが減ります。もう1つは走査の効率で、100列あるテーブルから3列だけを集計するとき、行指向なら全列を読み飛ばしながら進むところ、列指向では該当の3列だけを読み込みます。OLTPとOLAPの分岐がストレージ形式に現れるのはこの点です。

実行側では、1行ずつ処理する代わりに数千行をまとめてCPUのSIMD命令に載せる方式を取ります。公式ドキュメントはこれを fully vectorized engine と呼び、あわせてコストベースのオプティマイザ（CBO）を新規に設計し直したと述べています。CBOが効いてくるのは多表結合です。結合順序と結合方式の選択が実行時間を大きく左右する領域なので、統計情報に基づいて計画を組み替えられるかどうかで結果が数倍単位で変わります。

裏を返せば、単表への単純な集計だけを回す用途では、この設計の利点は限定的です。差が開くのはスタースキーマなどで結合が絡む問い合わせであり、比較検証を組むなら結合を含むクエリを必ず入れてください。

FE・BE・CNの役割分担とメタデータをメモリ上に保持する構造

FE（Frontend）はメタデータ管理、クライアント接続の受付、クエリのプランニングとスケジューリングを担います。特徴的なのはメタデータの持ち方で、各FEがBDB JE上に完全なコピーをメモリで保持します。ロールは3種類あり、リーダーがメタデータの読み書きを行い、フォロワーは読み取りとリーダー選出への参加、オブザーバーは読み取りのみで選出には加わりません。

BE（Backend）はshared-nothing構成でのデータ保存とSQL実行を兼ねます。データがローカルにあるため、実行計画を持ってきて手元のデータに当てる形になり、ノード間のデータ転送が発生しません。CN（Compute Node）はshared-data構成でBEを置き換えるノードで、状態を持たず計算とキャッシュに専念します。

運用設計で効いてくるのは、FEのメタデータがメモリ常駐である点です。テーブル数とパーティション数、タブレット数が増えるほどFEのメモリを食います。パーティションを日次で切って数年分を保持する設計にすると、ここが先に頭打ちになるため、保持期間とパーティション粒度は初期に決めておく必要があります。フォロワーは奇数構成にし、リーダー選出が成立する台数を確保してください。

shared-nothingとshared-dataで変わる費用とスケール単位

shared-nothingは、各BEがデータの一部をローカルに保持し、複製を複数ノードに置く古典的な構成です。ローカルディスクへ直接当たるため実時間の問い合わせが速く、複製が可用性と同時実行の受け皿になります。反面、容量と計算力が同じノードに縛られるので、片方だけを増やしたい場合に無駄が出ます。

shared-dataはバージョン3.0から提供された構成で、データをS3・GCS・Azureのオブジェクトストレージ、またはHDFSへ置き、CN側はローカルキャッシュを持つ計算層に徹します。ストレージ単価が下がり、計算層を独立して増減できる利点があります。代償はキャッシュの当たり方で、キャッシュを外した問い合わせはオブジェクトストレージへのレイテンシをそのまま受ける点です。

選び分けの目安は、データ量の伸び方と負荷の波です。データが年単位で増え続ける一方でピーク時間帯が限られるなら、shared-dataで計算層を伸縮させたほうが総額は下がります。データ量が横ばいで常時高い同時実行を捌くなら、shared-nothingのほうが素直な構成になります。

テーブル設計とロード方式の選択で決まるStarRocksの実測性能

StarRocksで性能が出ないという相談の多くは、エンジンではなくテーブル定義とロード方式の選択に原因があります。設計時に決める項目を順に見ていきます。

4つのテーブルタイプと主キーテーブルが実時間更新を担える条件

テーブルタイプは4種類です。重複キーテーブル（Duplicate Key）は投入したレコードをそのまま行として積み、キーが重複しても履歴を残します。集計テーブル（Aggregate）は同一キーのレコードを1行へ畳み込み、明細ではなく集計結果だけを保持する形式。更新キーテーブル（Unique Key）と主キーテーブル（Primary Key）はいずれも同一キーの旧レコードを新しいものへ置き換えます。公式ドキュメントは後者2つを「REPLACE付きの特殊な集計テーブル」と位置付けています。

実装上の分岐は、更新キーテーブルと主キーテーブルの間にあります。主キーテーブルは主キーの索引をメモリに載せ、書き込み時に既存行を差し替える方式を取るため、更新直後の読み取りが速く、変更を数秒でトランザクション系から同期させる用途に耐えます。その代わり主キー列のカーディナリティと行数がそのままメモリ消費へ跳ね返る設計です。

判断の目安は、更新の頻度と対象行の割合です。全体の数%が日に何度も書き換わり、その最新値を即座に読みたいなら主キーテーブル。更新が日次バッチでまとめて入るだけなら更新キーテーブルで足り、メモリを節約できます。追記しか発生しないログ系は重複キーテーブルが素直で、明細を捨ててよい指標系だけを集計テーブルに寄せる、という切り分けになります。

ソートキーとプレフィックスインデックスの設計で外せない3つの指針

プレフィックスインデックスは、ソートキーの先頭部分から自動生成されるスパースな索引です。仕様の上限は明確で、対象は最大3列、サイズは36バイトまで。これを超えた分は切り詰められます。文字列型（CHAR・VARCHAR・STRING）は1回だけ、しかも最後に置ける決まりです。

構築の仕組みも押さえておくと設計しやすくなります。ソートキー順に並べ替えたうえで1024行を1つの論理ブロックとし、各ブロック先頭行のソートキー値を索引エントリとして保持する構造です。索引は実データのおよそ1024分の1に収まるためメモリに載り、二分探索で条件に合わないブロックを丸ごと読み飛ばせます。

設計指針は3つに集約できます。第一に、絞り込みに頻繁に使う列を利用頻度の高い順に前へ置くこと。第二に、カーディナリティの高い列ほど絞り込みが効く一方、低カーディナリティ列を前に置くと圧縮が効くので、両者の釣り合いを見ること。第三に、効き目を体感で判断せず query profile の ShortKeyFilterRows を見ること。この値が伸びていないなら、その列順は仕事をしていません。

6つのロード方式とデータ量・同期性の対応関係と選び分けの基準

ロードの入口は6つあり、取り込み元と同期性、想定データ量で使い分けます。

形式の対応も方式ごとに違います。Stream LoadはCSVとJSON、Broker LoadはCSV・Parquet・ORC・JSON、PipeはParquetとORC、Routine LoadはCSV・JSON・Avroという具合です。Parquetで置いてある既存のファイル群をStream Loadで入れようとして詰まる、という取り違えは実際に起きます。

選び分けの基準は単純で、まず取り込み元で候補が2つ程度に絞られ、次にデータ量で決まります。Kafkaからの連続取り込みならRoutine Load、オブジェクトストレージ上の大量ファイルなら量に応じてBroker LoadかPipe、手元の検証データならStream Load。同期方式は結果がその場で返る代わりに規模の上限を持ちます。

External Catalogと実体化ビューでレイクハウス側へ広げる構成

StarRocksを内部テーブルだけで使うのは半分の使い方です。外部のテーブル形式を直接読む機能と、結果を先に作り置きする機能が組み合わさって初めて構成の幅が出ます。

External CatalogでIceberg・Hudi・Hiveを参照する実装

External Catalogは、外部のメタストアを丸ごとカタログとして登録し、内部テーブルと同じSQLで参照できるようにする仕組みです。Hive・Apache Iceberg・Apache Hudi・Delta Lake・JDBC接続先などが対象になります。データを取り込まずに読めるため、レイクに置いたままの履歴データと、内部テーブルに入れた直近データを1つのクエリで結合する、という構成が組めます。

4.0系ではIceberg側の作り込みが進み、隠しパーティションの扱い、メタデータ解析の高速化、compaction API、そしてネイティブな書き込みが入りました。読むだけでなく書き戻せるようになった意味は小さくありません。集計結果をIcebergテーブルへ書き出し、他のエンジンから同じテーブルを読む、という分担が成立します。

非同期マテリアライズドビューとクエリ書き換えを効かせる前提条件

マテリアライズドビューは、集計や結合の結果を事前に作り置きしておく仕組みです。StarRocksの非同期マテリアライズドビューは定期的またはベーステーブルの変更を契機に更新され、外部カタログのテーブルを元にすることもできます。レイク上のParquetを毎回スキャンする代わりに、内部へ結果を落としておく使い方が可能です。

実務で効いてくるのはクエリの自動書き換えです。利用者が書いた元のSQLを、条件が合致すればビュー参照へ置き換えて実行します。前提はビューの定義がクエリの条件を包含していることで、期間の粒度や絞り込み列がずれていると書き換えは発動しません。想定どおり効いているかは実行計画で確認し、置き換わらないなら定義側の粒度を見直します。

ClickHouse・Doris・クラウドDWHとの使い分けを判断軸で切る

ここが選定でいちばん迷う部分です。カタログスペックの比較ではなく、どの問い合わせ形状と更新パターンに当たるかで切り分けます。

4つの選択肢を分ける判断軸と適合するワークロード像を並べた比較表

StarRocksとApache Dorisは出自を共有します。StarRocksの前身はApache Dorisをもとに開発されたDorisDBで、ライセンス上の事情から改称した経緯があります。設計思想が近いぶん、差が出るのはオプティマイザの作り込みと開発の重心。多表結合やアドホックな問い合わせが主体ならStarRocks、定型の多次元レポートを定時に回す用途ならDorisという整理が実態に近いところです。

ClickHouseとの差は問い合わせ形状に現れます。ClickHouseの列指向エンジンは単表への大量集計で強く、非正規化した幅広テーブルを前提に組む設計が定石。対してStarRocksは正規化されたスキーマのまま結合させる方向に振れており、ETLで事前結合する工数を削れるかどうかが分かれ目になります。トランザクション系と分析系を1つに寄せたいなら、TiDBのようなHTAP型の分散SQLが別の解になります。

StarRocksを採る条件と見送りが妥当になる場面の切り分け

採用へ倒してよいのは、次の条件が重なる場合です。分析クエリに3表以上の結合が常時含まれ、事前結合のETLがすでに運用の負担になっている。参照データに更新と削除が日常的に混ざり、その最新値を数秒以内に反映したい。同時実行が数十を超え、BIツールから直接叩かれる。この3つが揃うとき、StarRocksの設計はそのまま利点として効きます。

逆に見送りが妥当なのは3つの場面です。第一に、データ量が数百GBに届かず単一のPostgreSQLやDWHで応答要件を満たせている場合。分散させる運用コストが便益を上回ります。第二に、追記だけの時系列ログを単表で集計する用途。この形状ならClickHouse系のほうが素直で、運用の情報量も日本語で揃います。第三に、SQLを書く人が社内におらず、GUIでの操作を前提にしている場合。MySQLプロトコル互換とはいえ、性能を出すにはテーブル設計とソートキーの判断が要り、そこを担う人がいない構成は持ちません。

判断を保留にしてよい条件もはっきりしています。いま結合が2表までで済んでいるなら、無理に移す理由はありません。結合が3表を超えて事前集計のジョブが増え始めた時点が、検証を始める合図です。

検証から本番投入までの工程とStarRocks運用でつまずく箇所

StarRocksは入れれば速くなる部類の製品ではなく、設計判断が性能に直結します。検証の順番と、実際に詰まりやすい箇所を挙げます。

PoCで先に測る5つの工程と決裁の順番を入れ替えてはならない理由

1. 本番相当のスキーマとデータ量で、結合を含む代表クエリを3〜5本選ぶ
2. 更新の頻度と対象行の割合を測り、テーブルタイプを先に確定する
3. データ量の伸びとピークの波から、shared-nothingとshared-dataを決める
4. 絞り込み列の利用頻度とカーディナリティからソートキーを組み、ShortKeyFilterRowsで検証する
5. 取り込み元と量からロード方式を選び、同時実行数を上げた状態で応答時間を測る

順番を入れ替えないでください。ノード構成を先に固めてからテーブルタイプを選ぶと、主キーテーブルのメモリ要件が後から効いてきてノードの再見積もりになります。同様に、ソートキーを決める前に同時実行の測定へ進むと、遅い原因が設計なのか台数なのか切り分けられません。データ基盤の構成そのものから相談したい場合は、データ分析基盤構築・MLOps構築支援で要件整理から実装まで対応しています。

主キーテーブルのメモリとCompactionで詰まる運用上の箇所

詰まる箇所の筆頭は主キーテーブルのメモリです。主キーの索引を常駐させる設計上、行数と主キー列の幅がそのまま消費量になります。数十億行のテーブルに長い文字列の複合主キーを置くと、BEのメモリが先に尽きます。回避策は主キーを数値型の代理キーへ寄せることと、パーティションを切って常駐範囲を絞ることの2つです。

次に多いのがCompactionの遅延です。小さなファイルを高頻度で投入すると、背後で走る統合処理が追いつかず、読み取り時に走査するファイル数が増えて応答が悪化します。Routine Loadのバッチ間隔を詰めすぎた構成でよく起きる現象なので、取り込み間隔とファイルサイズは監視項目に入れてください。

よくある質問

StarRocksの検討で実際に問い合わせの多い論点を5つ挙げます。

StarRocksとApache Dorisはどういう関係ですか？

StarRocksの前身は、Apache Dorisをもとに開発されたDorisDBです。ライセンス上の事情から改称し、その後2023年2月にApache License 2.0へ移行してLinux Foundationへ寄贈されました。現在は別々のプロジェクトとして開発が進んでおり、SQLの方言やテーブルモデルに共通点は残るものの、オプティマイザやレイクハウス連携の作り込みは分岐しています。移行を前提にした互換性は期待しないほうが安全です。

MySQLのクライアントからそのまま接続できますか？

接続できます。StarRocksはMySQLプロトコル互換で標準SQLに対応するため、mysqlコマンドや既存のJDBCドライバ、TableauやPower BIといったBIツールからそのまま繋がります。ただし互換なのは接続と構文の大枠までで、ストレージエンジンもトランザクションの粒度も別物です。分析クエリの接続口として捉えてください。

更新の多いデータをそのまま入れても問題ありませんか？

主キーテーブルを選べば受けられます。書き込み時に既存行を差し替える方式なので、更新直後の読み取りが速く、トランザクション系からの同期にも耐えます。注意点はメモリで、主キー索引を常駐させるぶん行数と主キーの幅が消費量へ直結する設計です。数十億行規模なら代理キーへの置き換えとパーティション設計を先に済ませてから投入してください。

shared-nothingから shared-dataへ後から移せますか？

クラスタの構成そのものが変わるため、設定変更だけでの切り替えはできません。実務上は新しくshared-dataのクラスタを立て、データを移送し、参照先を切り替える手順になります。移送の工数はデータ量に比例するため、初期の選択を先送りにするほど費用は膨らむ一方です。データ量の伸びとピークの波を検証段階で見積もり、第1章の基準で決めておいてください。

バージョンはどれを選べばよいですか？

2026年8月時点の系列は4.0系で、公式リリースノートに載る最新は4.0.13（2026年7月16日）。4.0.0は2025年10月の公開で、JSONを第一級のデータ型として扱う変更やIcebergのネイティブ書き込み、ASOF JOIN、Decimal256などが入りました。新規に組むなら4.0系の最新パッチを起点にするのが素直です。パッチ側にはCVE修正も含まれるため、稼働後も定期的な追随を運用に組み込んでください。

関連記事

• ClickHouseとは？列指向DBの仕組み・MergeTreeの実装からBigQueryとの使い分けまで実装者向けに解説：単表集計に強い列指向エンジンとの比較検討にあたる記事です。
• Apache Hudiとは？レコード単位の更新と増分取り込みを支える仕組みを実装視点で解説【2026年版】：External Catalogで参照する側のテーブル形式を扱っています。
• TiDBとは？MySQL互換の分散SQLの仕組みとHTAP・採用判断を解説：分析と更新を1つに寄せるHTAP型の選択肢を整理した記事です。
• OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説：処理系の分類そのものから確認したい場合の入口になります。
• OLAP（オーラップ）分析とは何か？定義と基本的な概念をわかりやすく解説：OLAPの概念と用語を先に押さえたい読者向けの記事です。