From cd48a1b7b5e2fd0eb0f6d9a7087a129f0f9de3da Mon Sep 17 00:00:00 2001 From: DanRoscigno Date: Mon, 2 Mar 2026 12:25:10 -0500 Subject: [PATCH 1/3] trigger Signed-off-by: DanRoscigno --- docs/en/introduction/Architecture.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md index 09428b7e..b5664e53 100644 --- a/docs/en/introduction/Architecture.md +++ b/docs/en/introduction/Architecture.md @@ -3,9 +3,7 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # Architecture -OK - -StarRocks has a wonderful architecture. The entire system consists of only two types of components: "frontends" and "backends". Frontend nodes are called **FE**. Backend nodes are divided into two types: **BE** and **CN** (compute node). When data uses local storage, BEs are deployed; when data is stored on object storage or HDFS, CNs are deployed. StarRocks does not rely on any external components, which simplifies deployment and maintenance. Nodes can be scaled horizontally without downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which improves data reliability and effectively prevents single points of failure (SPOFs). +StarRocks consists of two component types: "frontends" and "backends". Frontend nodes are called **FE**. Backend nodes are divided into two types: **BE** and **CN** (compute node). When data uses local storage, BEs are deployed; when data is stored on object storage or HDFS, CNs are deployed. StarRocks does not rely on any external components, which simplifies deployment and maintenance. Nodes can be scaled horizontally without downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which improves data reliability and effectively prevents single points of failure (SPOFs). StarRocks is compatible with the MySQL communication protocol and supports standard SQL. Users can connect to StarRocks via a MySQL client to gain instant and valuable insights. From 2aafc191debe19878c56c24294e5c7891f67591b Mon Sep 17 00:00:00 2001 From: "docs-automation[bot]" Date: Mon, 2 Mar 2026 19:57:11 +0000 Subject: [PATCH 2/3] docs: automated translation via Gemini --- docs/ja/introduction/Architecture.md | 86 +++++++++++++--------------- 1 file changed, 40 insertions(+), 46 deletions(-) diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md index f570aafd..a4be6df5 100644 --- a/docs/ja/introduction/Architecture.md +++ b/docs/ja/introduction/Architecture.md @@ -1,87 +1,81 @@ -```md ---- -displayed_sidebar: docs ---- - +displayed_sidebar: ドキュメント import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' -# Architecture -foo -StarRocks は堅牢なアーキテクチャを備えています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードには **BE** と **CN** (コンピュートノード) の2種類があります。データにローカルストレージを使用する場合に BE がデプロイされ、データがオブジェクトストレージまたは HDFS に保存される場合に CN がデプロイされます。StarRocks は外部コンポーネントに依存せず、デプロイとメンテナンスを簡素化します。ノードはサービス停止なしで水平にスケールできます。さらに、StarRocks はメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を高め、単一障害点 (SPOF) を効率的に防止します。 +# アーキテクチャ -StarRocks は MySQL 通信プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから StarRocks に接続し、瞬時に貴重なインサイトを得ることができます。 +StarRocksは、「フロントエンド」と「バックエンド」の2種類のコンポーネントで構成されています。フロントエンドノードは**FE**と呼ばれます。バックエンドノードは2つのタイプに分けられます。**BE**と**CN**（コンピュートノード）です。データがローカルストレージを使用する場合、BEがデプロイされます。データがオブジェクトストレージまたはHDFSに保存される場合、CNがデプロイされます。StarRocksは外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードはダウンタイムなしで水平にスケールできます。さらに、StarRocksはメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOF）を効果的に防止します。 -## Architecture choices +StarRocksはMySQL通信プロトコルと互換性があり、標準SQLをサポートしています。ユーザーはMySQLクライアントを介してStarRocksに接続し、即座に貴重な洞察を得ることができます。 -StarRocks は、shared-nothing (各 BE がローカルストレージにデータの一部を保持する) と shared-data (すべてのデータがオブジェクトストレージまたは HDFS にあり、各 CN がローカルストレージにキャッシュのみを保持する) をサポートします。データの保存場所は、ニーズに基づいて決定します。 +## アーキテクチャの選択肢 -![Architecture choices](../_assets/architecture_choices.png) +StarRocksは、共有なしモード（各BEがローカルストレージ上のデータの一部を所有する）と、共有データモード（すべてのデータがオブジェクトストレージまたはHDFSに保存され、各CNがローカルストレージ上にキャッシュのみを持つ）をサポートしています。ニーズに基づいてデータをどこに保存するかを決定できます。 +![架构选择](../_assets/architecture_choices.png) -### Shared-nothing +### 共有なしモード -ローカルストレージは、リアルタイムクエリのクエリレイテンシを向上させます。 +ローカルストレージは、リアルタイムクエリに対してより優れたクエリレイテンシを提供します。 -典型的な大規模並列処理 (MPP) データベースとして、StarRocks は共有なしアーキテクチャをサポートします。このアーキテクチャでは、BE はデータストレージとコンピュートの両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカルコンピュートが可能になり、データ転送やデータコピーを回避し、超高速なクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャはマルチレプリカデータストレージをサポートし、クラスタの高い同時実行性クエリ処理能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。 +典型的な大規模並列処理（MPP）データベースとして、StarRocksは共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BEがデータストレージと計算を担当します。BEノード上のローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送やデータコピーを回避し、超高速なクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、高並行クエリを処理するクラスターの能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを必要とするシナリオに最適です。 -![shared-data-arch](../_assets/shared-nothing.png) +![存算一体架构](../_assets/shared-nothing.png) -#### The nodes +#### ノード -共有なしアーキテクチャにおいて、StarRocks は FE と BE の2種類のノードで構成されます。 +共有なしアーキテクチャでは、StarRocksはFEとBEの2種類のノードで構成されています。 -- FE はメタデータ管理と実行プランの構築を担当します。 -- BE はクエリプランを実行し、データを保存します。BE はローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムによって高いデータ可用性を確保します。 +- FEはメタデータ管理と実行計画の構築を担当します。 +- BEはクエリ計画を実行し、データを保存します。BEはローカルストレージを活用してクエリを高速化し、マルチレプリカメカニズムを使用してデータの高可用性を確保します。 ##### FE -FE は、メタデータ管理、クライアント接続管理、クエリプランニング、およびクエリスケジューリングを担当します。各 FE は BDB JE (Berkeley DB Java Edition) を使用して、メタデータの完全なコピーをメモリに保存および維持し、すべての FE 間で一貫したサービスを保証します。FE は Leader、Follower、および Observer として機能できます。Leader ノードがクラッシュした場合、Follower は Raft プロトコルに基づいて Leader を選出します。 +FEは、メタデータ管理、クライアント接続管理、クエリ計画、およびクエリスケジューリングを担当します。各FEはBDB JE（Berkeley DB Java Edition）を使用して、メタデータの完全なレプリカをメモリに保存および維持し、すべてのFE間でのサービスの一貫性を確保します。FEは、リーダー、フォロワー、オブザーバーとして動作できます。リーダーノードがクラッシュした場合、フォロワーはRaftプロトコルに基づいてリーダーを選出します。 -| **FE ロール** | **メタデータ管理** | **Leader 選出** | -| :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Leader | Leader FE はメタデータを読み書きします。Follower FE と Observer FE はメタデータを読み取ることしかできません。これらはメタデータ書き込みリクエストを Leader FE にルーティングします。Leader FE はメタデータを更新し、Raft プロトコルを使用してメタデータの変更を Follower FE と Observer FE に同期します。データ書き込みは、メタデータの変更が半数以上の Follower FE に同期された後にのみ成功とみなされます。 | 技術的には、Leader FE も Follower ノードであり、Follower FE から選出されます。Leader 選出を実行するには、クラスタ内の半数以上の Follower FE がアクティブである必要があります。Leader FE が失敗した場合、Follower FE は別の Leader 選出ラウンドを開始します。 | -| Follower | Follower はメタデータを読み取ることしかできません。これらは Leader FE からログを同期およびリプレイしてメタデータを更新します。 | Follower は Leader 選出に参加し、クラスタ内の半数以上の Follower がアクティブである必要があります。 | -| Observer | Leader FE からログを同期およびリプレイしてメタデータを更新します。 | Observer は主にクラスタのクエリ同時実行性を高めるために使用されます。Observer は Leader 選出に参加しないため、クラスタに Leader 選出のプレッシャーを追加することはありません。| +| **FEの役割** | **メタデータ管理** | **リーダー選出** | +| ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- | +| リーダー | リーダーFEはメタデータを読み書きします。フォロワーFEとオブザーバーFEはメタデータを読み取ることしかできません。これらはメタデータ書き込みリクエストをリーダーFEにルーティングします。リーダーFEはメタデータを更新し、Raftプロトコルを使用してメタデータの変更をフォロワーFEとオブザーバーFEに同期します。データ書き込みは、メタデータの変更がフォロワーFEの半数以上に同期された後にのみ成功と見なされます。 | リーダーFEは、技術的にはフォロワーFEによって選出されたフォロワーノードでもあります。リーダー選出を実行するには、クラスター内のフォロワーFEの半数以上がアクティブである必要があります。リーダーFEが失敗した場合、フォロワーFEは新しいリーダー選出を開始します。 | +| フォロワー | フォロワーはメタデータを読み取ることしかできません。リーダーFEからのログを同期およびリプレイしてメタデータを更新します。 | フォロワーはリーダー選出に参加し、クラスター内のフォロワーの半数以上がアクティブである必要があります。 | +| オブザーバー | リーダーFEからのログを同期およびリプレイしてメタデータを更新します。 | オブザーバーは主にクラスターのクエリ並行性を向上させるために使用されます。オブザーバーはリーダー選出に参加しないため、クラスターのリーダー選出の負荷を増加させません。 | ##### BE -BE はデータストレージと SQL 実行を担当します。 +BEはデータストレージとSQL実行を担当します。 -- データストレージ: BE は同等のデータストレージ機能を持ちます。FE は事前に定義されたルールに基づいてデータを BE に分散します。BE は取り込まれたデータを変換し、必要なフォーマットでデータを書き込み、データ用のインデックスを生成します。 +- データストレージ: BEは同等のデータストレージ能力を持っています。FEは事前定義されたルールに従ってデータをBEに分散します。BEは取り込まれたデータを変換し、必要な形式でデータを書き込み、データのインデックスを生成します。 -- SQL 実行: FE は各 SQL クエリをそのクエリのセマンティクスに従って論理実行プランに解析し、その論理プランを BE で実行できる物理実行プランに変換します。宛先データを保存する BE がクエリを実行します。これにより、データ転送やコピーの必要がなくなり、高いクエリパフォーマンスを実現します。 +- SQL実行: FEは、クエリのセマンティクスに基づいて各SQLクエリを論理実行計画に解析し、その論理計画をBEで実行できる物理実行計画に変換します。ターゲットデータを保存しているBEがクエリを実行します。これにより、データ転送やコピーの必要がなくなり、高いクエリパフォーマンスを実現します。 -### Shared-data +### 共有データモード -オブジェクトストレージと HDFS は、コスト、信頼性、および拡張性のメリットを提供します。ストレージの拡張性に加えて、ストレージとコンピュートが分離されているため、データのリバランスなしで CN ノードを追加および削除できます。 +オブジェクトストレージとHDFSは、コスト、信頼性、スケーラビリティの点で利点を提供します。ストレージのスケーラビリティに加えて、ストレージと計算の分離により、CNノードはデータの再バランスなしでオンデマンドで追加および削除できます。 -共有データアーキテクチャでは、BE は「コンピュートノード (CN)」に置き換えられ、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスは共有なしアーキテクチャのそれに匹敵します。CN ノードは数秒でオンデマンドに追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より優れたリソース分離、高い柔軟性と拡張性を保証します。 +共有データアーキテクチャでは、BEは「コンピュートノード（CN）」に置き換えられ、データ計算タスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIOなどの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュヒット時には、クエリパフォーマンスは共有なしアーキテクチャに匹敵します。CNノードは数秒でオンデマンドで追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より良いリソース分離を確保し、高い弾力性とスケーラビリティを提供します。 -共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持します。FE と CN の2種類のノードのみで構成されます。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。 +共有データアーキテクチャは、共有なしアーキテクチャと同様に、シンプルな設計を維持しています。FEとCNの2種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドのオブジェクトストレージをプロビジョニングする必要があることです。 -![shared-data-arch](../_assets/shared-data.png) +![存算分离架构](../_assets/shared-data.png) -#### Nodes +#### ノード -共有データアーキテクチャにおけるコーディネーターノードは、共有なしアーキテクチャにおける FE と同じ機能を提供します。 +共有データアーキテクチャのコーディネーターノードは、共有なしアーキテクチャのFEと同じ機能を提供します。 -BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN はステートレスなコンピュートノードであり、データの保存を除く BE のすべての機能を実行します。 +BEはCN（コンピュートノード）に置き換えられ、ストレージ機能はオブジェクトストレージまたはHDFSにオフロードされます。CNは、データストレージを除くすべてのBE機能を実行するステートレスなコンピュートノードです。 -#### Storage +#### ストレージ -StarRocks 共有データクラスタは、オブジェクトストレージ (例: AWS S3、Google GCS、Azure Blob Storage、MinIO) および HDFS の2つのストレージソリューションをサポートします。 +StarRocksの共有データクラスターは、オブジェクトストレージ（AWS S3、Google GCS、Azure Blob Storage、MinIOなど）とHDFSの2つのストレージソリューションをサポートしています。 -共有データクラスタでは、データファイル形式は共有なしクラスタ (結合されたストレージとコンピュートを特徴とする) のものと一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術は、共有データクラスタで特別に使用されるクラウドネイティブテーブルで再利用されます。 +共有データクラスターでは、データファイル形式は共有ナッシングクラスター（ストレージとコンピューティングが結合されている）と一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術が、共有データクラスターで特に使用されるCloud-nativeテーブルで再利用されます。 -#### Cache +#### キャッシュ -StarRocks 共有データクラスタは、データストレージとコンピュートを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、柔軟性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 +StarRocksの共有データクラスターは、データストレージとコンピューティングを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、弾力性を向上させます。ただし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 -この影響を軽減するために、StarRocks はメモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立し、さまざまなビジネスニーズに効率的に対応します。 +この影響を軽減するため、StarRocksはメモリ、ローカルディスク、リモートストレージをカバーする多層データアクセスシステムを確立し、さまざまなビジネスニーズにより良く対応しています。 -ホットデータに対するクエリは、直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。 +ホットデータクエリは直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータは、後続のクエリを高速化するためにオブジェクトストレージからローカルキャッシュにロードする必要があります。ホットデータをコンピューティングユニットの近くに保持することで、StarRocksは真に高性能なコンピューティングと費用対効果の高いストレージを実現します。さらに、コールドデータアクセスはデータプリフェッチ戦略によって最適化され、クエリパフォーマンスの制限を効果的に排除しています。 -キャッシングはテーブル作成時に有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 +キャッシュはテーブル作成時に有効にできます。キャッシュが有効になっている場合、データはローカルディスクとバックエンドのオブジェクトストレージの両方に同時に書き込まれます。クエリ中、CNノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドのオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 -``` From f88b88abaee4f6cbf5a28387944d24bbf90a997b Mon Sep 17 00:00:00 2001 From: "docs-automation[bot]" Date: Tue, 3 Mar 2026 00:58:01 +0000 Subject: [PATCH 3/3] docs: automated translation via Gemini --- docs/ja/introduction/Architecture.md | 32 ++++++++++++++-------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md index a4be6df5..cc83f30c 100644 --- a/docs/ja/introduction/Architecture.md +++ b/docs/ja/introduction/Architecture.md @@ -1,64 +1,64 @@ -displayed_sidebar: ドキュメント +displayed_sidebar: docs import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # アーキテクチャ -StarRocksは、「フロントエンド」と「バックエンド」の2種類のコンポーネントで構成されています。フロントエンドノードは**FE**と呼ばれます。バックエンドノードは2つのタイプに分けられます。**BE**と**CN**（コンピュートノード）です。データがローカルストレージを使用する場合、BEがデプロイされます。データがオブジェクトストレージまたはHDFSに保存される場合、CNがデプロイされます。StarRocksは外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードはダウンタイムなしで水平にスケールできます。さらに、StarRocksはメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOF）を効果的に防止します。 +StarRocksは、「フロントエンド」と「バックエンド」の2種類のコンポーネントで構成されています。フロントエンドノードは**FE**と呼ばれます。バックエンドノードは2つのタイプに分けられます。**BE**と**CN**(コンピュートノード)です。データがローカルストレージを使用する場合、BEがデプロイされ、データがオブジェクトストレージまたはHDFSに保存される場合、CNがデプロイされます。StarRocksは外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードはダウンタイムなしで水平にスケールできます。さらに、StarRocksはメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOF）を効果的に防止します。 StarRocksはMySQL通信プロトコルと互換性があり、標準SQLをサポートしています。ユーザーはMySQLクライアントを介してStarRocksに接続し、即座に貴重な洞察を得ることができます。 ## アーキテクチャの選択肢 -StarRocksは、共有なしモード（各BEがローカルストレージ上のデータの一部を所有する）と、共有データモード（すべてのデータがオブジェクトストレージまたはHDFSに保存され、各CNがローカルストレージ上にキャッシュのみを持つ）をサポートしています。ニーズに基づいてデータをどこに保存するかを決定できます。 +StarRocksは、シェアードナッシングモード（各BEがローカルストレージ上のデータの一部を所有する）と、シェアードデータモード（すべてのデータがオブジェクトストレージまたはHDFSに保存され、各CNはローカルストレージにキャッシュのみを持つ）をサポートしています。ニーズに基づいてデータをどこに保存するかを決定できます。 ![架构选择](../_assets/architecture_choices.png) -### 共有なしモード +### シェアードナッシングモード ローカルストレージは、リアルタイムクエリに対してより優れたクエリレイテンシを提供します。 -典型的な大規模並列処理（MPP）データベースとして、StarRocksは共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BEがデータストレージと計算を担当します。BEノード上のローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送やデータコピーを回避し、超高速なクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、高並行クエリを処理するクラスターの能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを必要とするシナリオに最適です。 +典型的な大規模並列処理（MPP）データベースとして、StarRocksはシェアードナッシングアーキテクチャをサポートしています。このアーキテクチャでは、BEはデータストレージと計算を担当します。BEノード上のローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送とデータコピーを回避し、超高速のクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャはマルチレプリカデータストレージをサポートし、高並行クエリを処理するクラスターの能力を強化し、データ信頼性を確保します。最適なクエリパフォーマンスを必要とするシナリオに最適です。 ![存算一体架构](../_assets/shared-nothing.png) #### ノード -共有なしアーキテクチャでは、StarRocksはFEとBEの2種類のノードで構成されています。 +シェアードナッシングアーキテクチャでは、StarRocksはFEとBEの2種類のノードで構成されています。 - FEはメタデータ管理と実行計画の構築を担当します。 - BEはクエリ計画を実行し、データを保存します。BEはローカルストレージを活用してクエリを高速化し、マルチレプリカメカニズムを使用してデータの高可用性を確保します。 ##### FE -FEは、メタデータ管理、クライアント接続管理、クエリ計画、およびクエリスケジューリングを担当します。各FEはBDB JE（Berkeley DB Java Edition）を使用して、メタデータの完全なレプリカをメモリに保存および維持し、すべてのFE間でのサービスの一貫性を確保します。FEは、リーダー、フォロワー、オブザーバーとして動作できます。リーダーノードがクラッシュした場合、フォロワーはRaftプロトコルに基づいてリーダーを選出します。 +FEは、メタデータ管理、クライアント接続管理、クエリ計画、およびクエリスケジューリングを担当します。各FEはBDB JE（Berkeley DB Java Edition）を使用して、メタデータの完全なレプリカをメモリに保存および維持し、すべてのFE間でのサービスの一貫性を確保します。FEは、Leader、Follower、Observerとして動作できます。Leaderノードがクラッシュした場合、FollowerはRaftプロトコルに基づいてLeaderを選出します。 | **FEの役割** | **メタデータ管理** | **リーダー選出** | | ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- | -| リーダー | リーダーFEはメタデータを読み書きします。フォロワーFEとオブザーバーFEはメタデータを読み取ることしかできません。これらはメタデータ書き込みリクエストをリーダーFEにルーティングします。リーダーFEはメタデータを更新し、Raftプロトコルを使用してメタデータの変更をフォロワーFEとオブザーバーFEに同期します。データ書き込みは、メタデータの変更がフォロワーFEの半数以上に同期された後にのみ成功と見なされます。 | リーダーFEは、技術的にはフォロワーFEによって選出されたフォロワーノードでもあります。リーダー選出を実行するには、クラスター内のフォロワーFEの半数以上がアクティブである必要があります。リーダーFEが失敗した場合、フォロワーFEは新しいリーダー選出を開始します。 | -| フォロワー | フォロワーはメタデータを読み取ることしかできません。リーダーFEからのログを同期およびリプレイしてメタデータを更新します。 | フォロワーはリーダー選出に参加し、クラスター内のフォロワーの半数以上がアクティブである必要があります。 | -| オブザーバー | リーダーFEからのログを同期およびリプレイしてメタデータを更新します。 | オブザーバーは主にクラスターのクエリ並行性を向上させるために使用されます。オブザーバーはリーダー選出に参加しないため、クラスターのリーダー選出の負荷を増加させません。 | +| Leader | Leader FEはメタデータを読み書きします。FollowerおよびObserver FEはメタデータを読み取ることしかできません。これらはメタデータ書き込みリクエストをLeader FEにルーティングします。Leader FEはメタデータを更新し、Raftプロトコルを使用してメタデータの変更をFollowerおよびObserver FEに同期します。データ書き込みは、メタデータの変更がFollower FEの半数以上に同期された後にのみ成功と見なされます。 | Leader FEは、技術的にはFollower FEによって選出されるFollowerノードでもあります。Leader選出を実行するには、クラスター内のFollower FEの半数以上がアクティブである必要があります。Leader FEが失敗した場合、Follower FEは新しいLeader選出を開始します。 | +| Follower | Followerはメタデータを読み取ることしかできません。これらはLeader FEからのログを同期およびリプレイしてメタデータを更新します。 | FollowerはLeader選出に参加します。これには、クラスター内のFollowerの半数以上がアクティブである必要があります。 | +| Observer | Leader FEからのログを同期およびリプレイしてメタデータを更新します。 | Observerは主にクラスターのクエリ並行性を向上させるために使用されます。ObserverはLeader選出に参加しないため、クラスターのLeader選出の負荷を増加させません。 | ##### BE BEはデータストレージとSQL実行を担当します。 -- データストレージ: BEは同等のデータストレージ能力を持っています。FEは事前定義されたルールに従ってデータをBEに分散します。BEは取り込まれたデータを変換し、必要な形式でデータを書き込み、データのインデックスを生成します。 +- データストレージ: BEは同等のデータストレージ機能を持ちます。FEは事前定義されたルールに従ってデータをBEに分散します。BEは取り込まれたデータを変換し、必要な形式でデータを書き込み、データにインデックスを生成します。 -- SQL実行: FEは、クエリのセマンティクスに基づいて各SQLクエリを論理実行計画に解析し、その論理計画をBEで実行できる物理実行計画に変換します。ターゲットデータを保存しているBEがクエリを実行します。これにより、データ転送やコピーの必要がなくなり、高いクエリパフォーマンスを実現します。 +- SQL実行: FEは、クエリのセマンティクスに基づいて各SQLクエリを論理実行計画に解析し、その論理計画をBEで実行できる物理実行計画に変換します。ターゲットデータを保存しているBEがクエリを実行します。これにより、データ転送とコピーの必要がなくなり、高いクエリパフォーマンスが実現されます。 -### 共有データモード +### シェアードデータモード オブジェクトストレージとHDFSは、コスト、信頼性、スケーラビリティの点で利点を提供します。ストレージのスケーラビリティに加えて、ストレージと計算の分離により、CNノードはデータの再バランスなしでオンデマンドで追加および削除できます。 -共有データアーキテクチャでは、BEは「コンピュートノード（CN）」に置き換えられ、データ計算タスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIOなどの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュヒット時には、クエリパフォーマンスは共有なしアーキテクチャに匹敵します。CNノードは数秒でオンデマンドで追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より良いリソース分離を確保し、高い弾力性とスケーラビリティを提供します。 +シェアードデータアーキテクチャでは、BEは「コンピュートノード（CN）」に置き換えられ、データ計算タスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIOなどの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュヒット時には、クエリパフォーマンスはシェアードナッシングアーキテクチャに匹敵します。CNノードは数秒でオンデマンドで追加または削除できます。このアーキテクチャはストレージコストを削減し、より良いリソース分離を確保し、高い弾力性とスケーラビリティを提供します。 -共有データアーキテクチャは、共有なしアーキテクチャと同様に、シンプルな設計を維持しています。FEとCNの2種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドのオブジェクトストレージをプロビジョニングする必要があることです。 +シェアードデータアーキテクチャは、シェアードナッシングアーキテクチャと同様に、シンプルな設計を維持しています。FEとCNの2種類のノードのみで構成されます。唯一の違いは、ユーザーがバックエンドのオブジェクトストレージをプロビジョニングする必要があることです。 ![存算分离架构](../_assets/shared-data.png) #### ノード -共有データアーキテクチャのコーディネーターノードは、共有なしアーキテクチャのFEと同じ機能を提供します。 +シェアードデータアーキテクチャのコーディネーターノードは、シェアードナッシングアーキテクチャのFEと同じ機能を提供します。 BEはCN（コンピュートノード）に置き換えられ、ストレージ機能はオブジェクトストレージまたはHDFSにオフロードされます。CNは、データストレージを除くすべてのBE機能を実行するステートレスなコンピュートノードです。