アーキテクチャ
StarRocks はシンプルなアーキテクチャを持っています。システム全体は、フロントエンドとバックエンドの2種類のコンポーネントのみで構成されています。フロントエンドノードは FE と呼ばれます。バックエンドノードには BE と CN (Compute Nodes) の2種類があります。BEs はデータのローカルストレージが使用される場合にデプロイされ、CNs はデータがオブジェクトストレージまたは HDFS に保存される場合にデプロイされます。StarRocks は外部コンポーネントに依存せず、デプロイとメンテナンスが簡単です。ノードはサービスのダウンタイムなしに水平スケールできます。さらに、StarRocks にはメタデータとサービスデータのレプリカメカニズムがあり、データの信頼性を高め、単一障害点 (SPOF) を効率的に防ぎます。
StarRocks は MySQL プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから簡単に StarRocks に接続し、即座に貴重なインサイトを得ることができます。
アーキテクチャの選択
StarRocks は共有なし (各 BE がローカルストレージにデータの一部を持つ) と共有データ (すべてのデータがオブジェクトストレージまたは HDFS にあり、各 CN はローカルストレージにキャッシュのみを持つ) をサポートしています。ニーズに応じてデータの保存場所を決定できます。
共有なし
ローカルストレージはリアルタイムクエリのクエリレイテンシを改善します。
典型的な大規模並列処理 (MPP) データベースとして、StarRocks は共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BEs がデータストレージと計算の両方を担当します。BE モードでのローカルデータへの直接アクセスは、データ転送とデータコピーを回避し、超高速のクエリと分析パフォーマンスを提供します。このアーキテクチャはマルチレプリカデータストレージをサポートし、クラスタの高い同時実行クエリ処理能力を強化し、データの信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。
ノード
ストレージなしアーキテクチャでは、StarRocks は FEs と BEs の2種類のノードで構成されています。
- FEs はメタデータ管理と実行計画の構築を担当します。
- BEs はクエリプランを実行し、データを保存します。BEs はローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムを使用して高いデータ可用性を確保します。
FE
FEs はメタデータ管理、クライアント接続管理、クエリプランニング、クエリスケジューリングを担当します。各 FE は BDB JE (Berkeley DB Java Edition) を使用してメタデータの完全なコピーをメモリ内に保存および維持し、すべての FE 間で一貫したサービスを確保します。FEs はリーダー、フォロワー、オブザーバーとして機能できます。リーダーノードがクラッシュした場合、フォロワーが Raft プロトコルに基づいてリーダーを選出します。
| FE の役割 | メタデータ管理 | リーダー選出 |
|---|---|---|
| Leader | リーダー FE はメタデータの読み書きを行います。フォロワーとオブザーバーの FEs はメタデータを読み取ることしかできません。彼らはメタデータの書き込み要求をリーダー FE にルーティングします。リーダー FE はメタデータを更新し、その後 Raft プロトコルを使用してメタデータの変更をフォロワーとオブザーバーの FEs に同期します。データの書き込みは、メタデータの変更がフォロワー FEs の半数以上に同期された後にのみ成功と見なされます。 | リーダー FE は技術的にはフォロワーノードでもあり、フォロワー FEs から選出されます。リーダー選出を行うには、クラスタ内のフォロワー FEs の半数以上がアクティブである必要があります。リーダー FE が失敗した場合、フォロワー FEs は別のリーダー選出を開始します。 |
| Follower | フォロワーはメタデータを読み取ることしかできません。彼らはリーダー FE からログを同期して再生し、メタデータを更新します。 | フォロワーはリーダー選出に参加し、クラスタ内のフォロワーの半数以上がアクティブである必要があります。 |
| Observer | オブザーバーはリーダー FE からログを同期して再生し、メタデータを更新します。 | オブザーバーはクラスタのクエリ同時実行性を高めるために主に使用されます。オブザーバーはリーダー選出に参加せず、したがってクラスタにリーダー選出の負担をかけません。 |
BE
BEs はデータストレージと SQL 実行を担当します。
-
データストレージ: BEs は同等のデータストレージ能力を持っています。FEs は事前定義されたルールに基づいてデータを BEs に分配します。BEs は取り込まれたデータを変換し、データを必要な形式に書き込み、データのインデックスを生成します。
-
SQL 実行: FEs は各 SQL クエリをクエリのセマンティクスに基づいて論理実行計画に解析し、その後、論理計画を BEs で実行可能な物理実行計画に変換します。目的のデータを保存する BEs がクエリを実行します。これによりデータの転送やコピーが不要となり、高いクエリパフォーマンスを実現します。
共有データ
オブジェクトストレージと HDFS はコスト、信頼性、スケーラビリティの利点を提供します。ストレージのスケーラビリティに加えて、CN ノードはデータの再バランスを必要とせずに追加および削除できます。
共有データアーキテクチャでは、BEs は「コンピュートノード (CNs)」に置き換えられ、データの計算タスクとホットデータのキャッシュのみを担当します。データは Amazon S3、GCP、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスは共有なしアーキテクチャと同等です。CN ノードは数秒以内にオンデマンドで追加または削除できます。このアーキテクチャはストレージコストを削減し、リソースの分離を確保し、高い弾力性とスケーラビリティを提供します。
共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持しています。FE と CN の2種類のノードのみで構成されており、唯一の違いはバックエンドオブジェクトストレージをプロビジョニングする必要があることです。
ノード
共有データアーキテクチャの FEs は、共有なしアーキテクチャと同じ機能を提供します。
BEs は CNs (Compute Nodes) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CNs はステートレスなコンピュートノードで、データのストレージを除くすべての BE の機能を実行します。
ストレージ
StarRocks 共有データクラスタは、オブジェクトストレージ (例えば、AWS S3、Google GCS、Azure Blob Storage、または MinIO) と HDFS の2つのストレージソリューションをサポートしています。
共有データクラスタでは、データファイル形式は共有なしクラスタ (ストレージと計算が結合されたもの) と一貫しています。データはセグメントファイルに編成され、クラウドネイティブテーブルでさまざまなインデックス技術が再利用されます。これらのテーブルは、特に共有データクラスタで使用されます。
キャッシュ
StarRocks 共有データクラスタは、データストレージと計算を分離し、それぞれを独立してスケールできるようにすることで、コストを削減し、弾力性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。
その影響を軽減するために、StarRocks はメモリ、ローカルディスク、リモートストレージを含むマルチティアデータアクセスシステムを確立し、さまざまなビジネスニーズにより適切に対応します。
ホットデータに対するクエリはキャッシュを直接スキャンし、その後ローカルディスクをスキャンしますが、コールドデータはオブジェクトストレージからローカルキャッシュにロードされ、後続のクエリを高速化します。ホットデータをコンピュートユニットに近づけることで、StarRocks は真に高性能な計算とコスト効率の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。
テーブルを作成する際にキャッシングを有効にすることができます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。
実践で学ぶ
Quick Starts を試して、StarRocks を現実的なシナリオで使用する概要をつかみましょう。