メインコンテンツまでスキップ

Architecture

アーキテクチャ

StarRocksはシンプルなアーキテクチャを持っています。システム全体は、フロントエンド（FE）とバックエンド（BE）の2つのコンポーネントのみで構成されます。StarRocksは外部のコンポーネントに依存せず、展開とメンテナンスを簡素化しています。FEとBEは水平にスケールアウトさせることができ、サービスの停止時間を最小限に抑えます。さらに、StarRocksはメタデータとサービスデータのレプリカメカニズムを持っており、データの信頼性を高め、シングルポイントの障害（SPOF）を効率的に防止します。

StarRocksはMySQLプロトコルと互換性があり、標準的なSQLをサポートしています。ユーザーはMySQLクライアントから簡単にStarRocksに接続し、即座に貴重な洞察を得ることができます。

以下の図は、StarRocksのアーキテクチャを示しています。

アーキテクチャ

FEとBE​

FEはメタデータ管理、クライアント接続管理、クエリの計画とスケジューリングを担当しています。各FEはメモリに完全なメタデータのコピーを格納および維持し、FE間の無差別なサービスを保証します。FEはリーダー、フォロワー、オブザーバーとして動作することができます。フォロワーはPaxosプロトコルに基づいてリーダーを選出します。BDB JEはBerkeley DB Java Editionの略です。

  • リーダー
    • リーダーFEはフォロワーFEから選出されます。リーダー選出には、クラスタ内のフォロワーFEの半数以上がアクティブである必要があります。リーダーFEが失敗した場合、フォロワーFEは新たなリーダー選出を開始します。
    • リーダーFEはメタデータを読み書きします。フォロワーとオブザーバーFEはメタデータを読み取ることしかできません。彼らはメタデータの書き込みリクエストをリーダーFEにルーティングします。リーダーFEはメタデータを更新し、BDE JEを使用してメタデータの変更をフォロワーおよびオブザーバーFEに同期します。データの書き込みは、メタデータの変更がフォロワーFEの半数以上に同期された後に成功したとみなされます。
  • フォロワー
    • フォロワーはメタデータを読み取ることしかできません。彼らはリーダーFEからログを同期および再生してメタデータを更新します。
    • フォロワーはリーダー選出に参加しますが、クラスタ内のフォロワーの半数以上がアクティブである必要があります。
  • オブザーバー
    • オブザーバーは、クラスタのクエリ同時性を高めるために主に使用されます。
    • オブザーバーはリーダー選出に参加せず、したがってクラスタにリーダー選択の圧力を加えることはありません。
    • オブザーバーはリーダーFEからログを同期および再生してメタデータを更新します。

BEはデータの保管とSQLの実行を担当しています。

  • データの保管：BEは同等のデータ保管能力を持っています。FEは事前に定義されたルールに基づいてデータをBEに分散します。BEは受け入れるデータを変換し、必要な形式でデータを書き込み、データのインデックスを生成します。
  • SQLの実行：SQLクエリが到着すると、FEはクエリの意味に基づいてそれを論理的な実行計画に解析し、その後、論理計画をBEで実行可能な物理計画に変換します。宛先データを保持するBEがクエリを実行します。これにより、データの転送とコピーの必要性がなくなり、クエリのパフォーマンスが向上します。

データ管理​

StarRocksはカラム指向のデータベースシステムです。データを管理するために、パーティショニングとバケット分割のメカニズムを使用しています。テーブルのデータはまず複数のパーティションに分割され、さらに複数のタブレットに分割されます。タブレットはStarRocksにおけるデータ管理の基本的な論理単位です。各タブレットは、異なるBEに格納される複数のレプリカを持つことができます。タブレットの数を指定し、StarRocksにタブレットの管理を任せることができます。

パーティションとタブレットは、テーブルのスキャンを減らし、クエリの同時性を高めます。レプリカにより、データのバックアップと復元が容易になり、データの損失を防ぎます。

以下の図では、テーブルが時間に基づいて4つのパーティションに分割されています。最初のパーティションのデータはさらに4つのタブレットに分割されます。各タブレットには3つのレプリカがあり、それぞれ異なるBEに格納されています。

アーキテクチャ

1つのテーブルが複数のタブレットに分割されているため、StarRocksは1つのSQLステートメントをすべてのタブレットに並列処理させることができます。これにより、複数の物理マシンとコアの計算能力を最大限に活用することができます。また、複数のノードにクエリの負荷をオフロードすることで、サービスの可用性を高めます。需要に応じて物理マシンを追加することで高い同時性を実現することができます。

タブレットの分布は物理ノードに影響されることはありません。BEの数が変更された場合（例：BEの追加や削除など）、稼働中のサービスは中断することなく継続されます。ノードの変更により、タブレットの自動マイグレーションがトリガされます。BEが追加される場合、一部のタブレットはより均等なデータ分布のために新しいBEに自動的にマイグレーションされます。BEが削除される場合、これらのBE上のタブレットは自動的に他のBEにマイグレーションされ、レプリカの数は変わらないようになります。自動タブレットマイグレーションにより、StarRocksクラスタの自動スケーリングを容易に実現し、手動でのデータの再分配が不要になります。

StarRocksはタブレットに対してマルチレプリカ（デフォルトで3つ）メカニズムを使用しています。レプリカにより、データの信頼性とサービスの可用性が向上します。1つのノードの障害が全体的なサービスの可用性に影響を与えることはありません。さらに、レプリカの数を増やすことで、高いクエリ同時性を実現することもできます。