diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md index 09428b7e..48131aa4 100644 --- a/docs/en/introduction/Architecture.md +++ b/docs/en/introduction/Architecture.md @@ -3,8 +3,6 @@ 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 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. diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md index f570aafd..6848cbad 100644 --- a/docs/ja/introduction/Architecture.md +++ b/docs/ja/introduction/Architecture.md @@ -1,87 +1,80 @@ -```md ---- displayed_sidebar: docs ---- - 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 に接続し、瞬時に貴重なインサイトを得ることができます。 +# アーキテクチャ -## Architecture choices +StarRocksは素晴らしいアーキテクチャを持っています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは**FE**と呼ばれます。バックエンドノードは**BE**と**CN**（コンピュートノード）の2種類に分かれます。データがローカルストレージを使用する場合、BEがデプロイされ、データがオブジェクトストレージまたはHDFSに保存される場合、CNがデプロイされます。StarRocksはいかなる外部コンポーネントにも依存せず、デプロイとメンテナンスを簡素化します。ノードはダウンタイムなしで水平にスケールアウトできます。さらに、StarRocksはメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOFs）を効果的に防止します。 -StarRocks は、shared-nothing (各 BE がローカルストレージにデータの一部を保持する) と shared-data (すべてのデータがオブジェクトストレージまたは HDFS にあり、各 CN がローカルストレージにキャッシュのみを保持する) をサポートします。データの保存場所は、ニーズに基づいて決定します。 +StarRocksはMySQL通信プロトコルと互換性があり、標準SQLをサポートしています。ユーザーはMySQLクライアントを介してStarRocksに接続し、即座に価値あるインサイトを得ることができます。 -![Architecture choices](../_assets/architecture_choices.png) +## アーキテクチャの選択 +StarRocksは、Shared-nothingモード（各BEがそのローカルストレージ上にデータの一部を所有する）とShared-dataモード（すべてのデータがオブジェクトストレージまたはHDFSに保存され、各CNはそのローカルストレージ上にキャッシュのみを持つ）をサポートしています。要件に基づいてデータの保存場所を決定できます。 -### Shared-nothing +![アーキテクチャの選択](../_assets/architecture_choices.png) -ローカルストレージは、リアルタイムクエリのクエリレイテンシを向上させます。 +### Shared-nothingモード +ローカルストレージは、リアルタイムクエリに対してより良いクエリレイテンシを提供します。 -典型的な大規模並列処理 (MPP) データベースとして、StarRocks は共有なしアーキテクチャをサポートします。このアーキテクチャでは、BE はデータストレージとコンピュートの両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカルコンピュートが可能になり、データ転送やデータコピーを回避し、超高速なクエリおよびデータ分析パフォーマンスを提供します。このアーキテクチャはマルチレプリカデータストレージをサポートし、クラスタの高い同時実行性クエリ処理能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに適しています。 +典型的なMassively Parallel Processing (MPP) データベースとして、StarRocksはShared-nothingアーキテクチャをサポートしています。このアーキテクチャでは、BEはデータストレージと計算を担当します。BEノード上のローカルデータに直接アクセスすることで、ローカル計算が可能になり、データ転送やデータコピーを回避し、超高速なクエリとデータ分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、クラスターの同時実行性の高いクエリ処理能力を高め、データ信頼性を確保します。最適なクエリパフォーマンスを必要とするシナリオに理想的です。 -![shared-data-arch](../_assets/shared-nothing.png) +![ストレージと計算が一体となったアーキテクチャ](../_assets/shared-nothing.png) -#### The nodes +#### ノード -共有なしアーキテクチャにおいて、StarRocks は FE と BE の2種類のノードで構成されます。 +Shared-nothingアーキテクチャにおいて、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はLeader、Follower、Observerとして動作できます。Leaderノードがクラッシュした場合、FollowerはRaftプロトコルに基づいてLeaderを選出します。 -| **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の役割** | **メタデータ管理** | **リーダー選出** | +| ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- | +| Leader | Leader FEはメタデータを読み書きします。FollowerおよびObserver FEはメタデータのみを読み取ることができます。これらのFEはメタデータ書き込み要求をLeader FEにルーティングします。Leader FEはメタデータを更新した後、Raftプロトコルを使用してメタデータ変更をFollowerおよびObserver FEに同期します。データ書き込みは、メタデータ変更がFollower FEの半数以上に同期されて初めて成功とみなされます。 | Leader FEは、技術的にはFollower FEによって選出されたFollowerノードでもあります。リーダー選出を行うには、クラスター内のFollower FEの半数以上がアクティブである必要があります。Leader FEが失敗した場合、Follower FEは新しいラウンドのリーダー選出を開始します。 | +| Follower | Followerはメタデータのみを読み取ることができます。Leader FEからのログを同期およびリプレイしてメタデータを更新します。 | Followerはリーダー選出に参加します。これには、クラスター内のFollowerの半数以上がアクティブである必要があります。 | +| Observer | Leader FEからのログを同期およびリプレイしてメタデータを更新します。 | Observerは主にクラスターのクエリ同時実行性を向上させるために使用されます。Observerはリーダー選出に参加しないため、クラスターへのリーダー選出のプレッシャーを増加させません。 | ##### 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 +### Shared-dataモード -オブジェクトストレージと HDFS は、コスト、信頼性、および拡張性のメリットを提供します。ストレージの拡張性に加えて、ストレージとコンピュートが分離されているため、データのリバランスなしで CN ノードを追加および削除できます。 +オブジェクトストレージとHDFSは、コスト、信頼性、スケーラビリティの面で利点を提供します。ストレージのスケーラビリティに加えて、ストレージと計算の分離により、データのリバランスなしでCNノードをオンデマンドで追加および削除できます。 -共有データアーキテクチャでは、BE は「コンピュートノード (CN)」に置き換えられ、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO などの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスは共有なしアーキテクチャのそれに匹敵します。CN ノードは数秒でオンデマンドに追加または削除できます。このアーキテクチャは、ストレージコストを削減し、より優れたリソース分離、高い柔軟性と拡張性を保証します。 +Shared-dataアーキテクチャでは、BEは「コンピュートノード (CN)」に置き換えられ、データ計算タスクとホットデータのキャッシングのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIOなどの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットした場合、クエリパフォーマンスはShared-nothingアーキテクチャに匹敵します。CNノードは数秒でオンデマンドに追加または削除できます。このアーキテクチャはストレージコストを削減し、より良いリソース分離を保証し、高い弾力性とスケーラビリティを提供します。 -共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持します。FE と CN の2種類のノードのみで構成されます。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。 +Shared-dataアーキテクチャは、Shared-nothingアーキテクチャと同様に、シンプルな設計を維持しています。FEとCNの2種類のノードのみで構成されます。唯一の違いは、ユーザーがバックエンドオブジェクトストレージをプロビジョニングする必要があることです。 -![shared-data-arch](../_assets/shared-data.png) +![ストレージと計算が分離されたアーキテクチャ](../_assets/shared-data.png) -#### Nodes +#### ノード -共有データアーキテクチャにおけるコーディネーターノードは、共有なしアーキテクチャにおける FE と同じ機能を提供します。 +Shared-dataアーキテクチャにおけるコーディネーターノードは、Shared-nothingアーキテクチャにおけるFEと同じ機能を提供します。 -BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN はステートレスなコンピュートノードであり、データの保存を除く BE のすべての機能を実行します。 +BEはCN（コンピュートノード）に置き換えられ、ストレージ機能はオブジェクトストレージまたはHDFSにオフロードされます。CNは、データストレージを除くすべてのBE機能を実行するステートレスなコンピュートノードです。 -#### Storage +#### ストレージ -StarRocks 共有データクラスタは、オブジェクトストレージ (例: AWS S3、Google GCS、Azure Blob Storage、MinIO) および HDFS の2つのストレージソリューションをサポートします。 +StarRocks Shared-dataクラスターは、オブジェクトストレージ（AWS S3、Google GCS、Azure Blob Storage、MinIOなど）とHDFSの2つのストレージソリューションをサポートしています。 -共有データクラスタでは、データファイル形式は共有なしクラスタ (結合されたストレージとコンピュートを特徴とする) のものと一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術は、共有データクラスタで特別に使用されるクラウドネイティブテーブルで再利用されます。 +Shared-dataクラスターでは、データファイル形式はShared-nothingクラスター（ストレージと計算が結合されている）と一貫しています。データはセグメントファイルに整理され、Shared-dataクラスターで specifically使用されるテーブルであるCloud-nativeテーブルでは、様々なインデックス技術が再利用されます。 -#### Cache +#### キャッシュ -StarRocks 共有データクラスタは、データストレージとコンピュートを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、柔軟性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 +StarRocks Shared-dataクラスターは、データストレージと計算を分離し、独立してスケーリングできるようにすることで、コストを削減し、弾力性を向上させます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 -この影響を軽減するために、StarRocks はメモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立し、さまざまなビジネスニーズに効率的に対応します。 +この影響を軽減するため、StarRocksはメモリ、ローカルディスク、リモートストレージをカバーする多層データアクセスシステムを確立し、様々なビジネスニーズに柔軟に対応できるようにしています。 -ホットデータに対するクエリは、直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。 +ホットデータクエリはキャッシュを直接スキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータを計算ユニットの近くに保つことで、StarRocksは真に高性能な計算と費用対効果の高いストレージを実現します。さらに、データプリフェッチ戦略を通じてコールドデータアクセスが最適化され、クエリパフォーマンスの制限が効果的に排除されています。 -キャッシングはテーブル作成時に有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 +テーブル作成時にキャッシングを有効にできます。キャッシングが有効になっている場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に同時に書き込まれます。クエリ中、CNノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 -``` diff --git a/docs/zh/introduction/Architecture.md b/docs/zh/introduction/Architecture.md index 46bfabbe..cd140e16 100644 --- a/docs/zh/introduction/Architecture.md +++ b/docs/zh/introduction/Architecture.md @@ -3,22 +3,20 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # 架构 -好的 - -StarRocks 具有出色的架构。整个系统只包含两种类型的组件：“前端节点”和“后端节点”。前端节点称为 **FE**。后端节点分为两种类型：**BE** 和 **CN**（计算节点）。当数据使用本地存储时，部署 BE；当数据存储在对象存储或 HDFS 上时，部署 CN。StarRocks 不依赖任何外部组件，这简化了部署和维护。节点可以水平扩展而无需停机。此外，StarRocks 对元数据和服务数据采用副本机制，提高了数据可靠性，有效防止了单点故障 (SPOF)。 +StarRocks 拥有出色的架构。整个系统只包含两种类型的组件：“前端节点（frontends）”和“后端节点（backends）”。前端节点称为 **FE**。后端节点分为两种类型：**BE** 和 **CN**（计算节点）。当数据使用本地存储时，部署 BE；当数据存储在对象存储或 HDFS 上时，部署 CN。StarRocks 不依赖任何外部组件，这简化了部署和维护。节点可以水平扩展，无需停机。此外，StarRocks 具有元数据和服务数据的副本机制，这提高了数据可靠性，并有效防止了单点故障（SPOFs）。 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) @@ -27,56 +25,56 @@ StarRocks 支持存算一体模式（每个 BE 在其本地存储上拥有一部 在存算一体架构中，StarRocks 由两种类型的节点组成：FE 和 BE。 - FE 负责元数据管理和构建执行计划。 -- BE 执行查询计划和存储数据。BE 利用本地存储加速查询，并使用多副本机制确保数据高可用性。 +- 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 可以作为 Leader、Follower 和 Observer 运行。如果 Leader 节点崩溃，Follower 将根据 Raft 协议选举出 Leader。 -| **FE 角色** | **元数据管理** | **Leader 选举** | -| ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- | -| Leader | Leader FE 读取和写入元数据。Follower 和 Observer FE 只能读取元数据。它们将元数据写入请求路由到 Leader FE。Leader FE 更新元数据，然后使用 Raft 协议将元数据更改同步到 Follower 和 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 角色** | **元数据管理** | **Leader 选举** | +| ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Leader | Leader FE 负责读取和写入元数据。Follower 和 Observer FE 只能读取元数据。它们将元数据写入请求路由到 Leader FE。Leader FE 更新元数据后，使用 Raft 协议将元数据更改同步到 Follower 和 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 选举压力。 | ##### BE BE 负责数据存储和 SQL 执行。 -- 数据存储：BE 具有等效的数据存储能力。FE 根据预定义规则将数据分发给 BE。BE 转换摄入的数据，以所需格式写入数据，并为数据生成索引。 +- 数据存储：BE 具有同等的数据存储能力。FE 根据预定义规则将数据分发到 BE。BE 对摄入的数据进行转换，以所需格式写入数据，并为数据生成索引。 -- SQL 执行：FE 根据查询的语义将每个 SQL 查询解析为逻辑执行计划，然后将逻辑计划转换为可在 BE 上执行的物理执行计划。存储目标数据的 BE 执行查询。这消除了数据传输和复制的需要，从而实现高查询性能。 +- SQL 执行：FE 根据查询的语义将每个 SQL 查询解析为逻辑执行计划，然后将逻辑计划转换为可在 BE 上执行的物理执行计划。存储目标数据的 BE 执行查询。这消除了数据传输和复制的需要，从而实现了高查询性能。 ### 存算分离模式 -对象存储和 HDFS 在成本、可靠性和可扩展性方面具有优势。除了存储的可扩展性之外，由于存储与计算分离，CN 节点可以按需添加和删除，无需重新平衡数据。 +对象存储和 HDFS 在成本、可靠性和可扩展性方面具有优势。除了存储可扩展性外，由于存储与计算分离，CN 节点可以按需添加和删除，无需重新平衡数据。 -在存算分离架构中，BE 被“计算节点（CN）”取代，CN 仅负责数据计算任务和缓存热数据。数据存储在低成本、可靠的远程存储系统（如 Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO 等）中。当缓存命中时，查询性能与存算一体架构相当。CN 节点可以在几秒钟内按需添加或删除。这种架构降低了存储成本，确保了更好的资源隔离，并提供了高弹性和可扩展性。 +在存算分离架构中，BE 被“计算节点（CN）”取代，CN 仅负责数据计算任务和缓存热数据。数据存储在低成本、可靠的远程存储系统（例如 Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO 等）中。当缓存命中时，查询性能与存算一体架构相当。CN 节点可以在几秒钟内按需添加或删除。这种架构降低了存储成本，确保了更好的资源隔离，并提供了高弹性和可扩展性。 -存算分离架构与存算一体架构一样，保持了简单的设计。它只包含两种类型的节点：FE 和 CN。唯一的区别是用户需要提供一个后端对象存储。 +存算分离架构，如同存算一体架构一样，保持了简单的设计。它只包含两种类型的节点：FE 和 CN。唯一的区别是用户需要提供后端对象存储。 ![存算分离架构](../_assets/shared-data.png) #### 节点 -存算分离架构中的协调节点提供与存算一体架构中 FE 相同的功能。 +存算分离架构中的协调节点提供与存算一体架构中的 FE 相同的功能。 -BE 被 CN（计算节点）取代，存储功能被卸载到对象存储或 HDFS。CN 是无状态的计算节点，执行除数据存储之外的所有 BE 功能。 +BE 被 CN（计算节点）取代，存储功能则卸载到对象存储或 HDFS。CN 是无状态的计算节点，执行除数据存储之外的所有 BE 功能。 #### 存储 -StarRocks 存算分离集群支持两种存储解决方案：对象存储（如 AWS S3、Google GCS、Azure Blob Storage 或 MinIO）和 HDFS。 +StarRocks 存算分离集群支持两种存储解决方案：对象存储（例如 AWS S3、Google GCS、Azure Blob Storage 或 MinIO）和 HDFS。 -在存算分离集群中，数据文件格式与存算一体集群（具有紧密耦合的存储和计算）保持一致。数据被组织成段文件，各种索引技术在 Cloud-native tables 中得到重用，Cloud-native tables 是专门用于存算分离集群的表。 +在存算分离集群中，数据文件格式与存算一体集群（具有存储和计算耦合的特性）保持一致。数据被组织成段文件，并且各种索引技术在云原生表（Cloud-native tables，专门用于存算分离集群的表）中得到重用。 #### 缓存 -StarRocks 存算分离集群将数据存储与计算解耦，允许它们独立扩展，从而降低成本并增强弹性。然而，这种架构可能会影响查询性能。 +StarRocks 存算分离集群解耦了数据存储和计算，使其能够独立扩展，从而降低了成本并增强了弹性。然而，这种架构可能会影响查询性能。 -为了缓解这种影响，StarRocks 建立了一个涵盖内存、本地磁盘和远程存储的多层数据访问系统，以更好地满足各种业务需求。 +为了减轻这种影响，StarRocks 建立了一个涵盖内存、本地磁盘和远程存储的多层数据访问系统，以更好地满足各种业务需求。 热数据查询直接扫描缓存，然后扫描本地磁盘；而冷数据需要从对象存储加载到本地缓存以加速后续查询。通过将热数据保持在靠近计算单元的位置，StarRocks 实现了真正的高性能计算和经济高效的存储。此外，通过数据预取策略优化了冷数据访问，有效消除了查询性能限制。 -在创建表时可以启用缓存。如果启用缓存，数据将同时写入本地磁盘和后端对象存储。在查询期间，CN 节点首先从本地磁盘读取数据。如果未找到数据，则将从后端对象存储中检索数据并同时缓存到本地磁盘。 +在创建表时可以启用缓存。如果启用缓存，数据将同时写入本地磁盘和后端对象存储。查询期间，CN 节点首先从本地磁盘读取数据。如果未找到数据，则会从后端对象存储中检索，并同时缓存到本地磁盘。