From 636720c4f2f97f56a3c8cb695e371c6dfa58625a Mon Sep 17 00:00:00 2001 From: Dan Roscigno Date: Thu, 12 Feb 2026 22:14:18 -0500 Subject: [PATCH 1/3] Update description of StarRocks architecture --- docs/en/introduction/Architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md index e111ac9a..09428b7e 100644 --- a/docs/en/introduction/Architecture.md +++ b/docs/en/introduction/Architecture.md @@ -5,7 +5,7 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' OK -StarRocks has a powerful 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 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. From 8d9e32eea18377e71ebd72bb95e69b6d7b0937cb Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 13 Feb 2026 03:15:44 +0000 Subject: [PATCH 2/3] chore: add automated translations Generated by markdown-translator Triggered by: @DanRoscigno --- docs/zh/introduction/Architecture.md | 54 +++++++++++++--------------- 1 file changed, 25 insertions(+), 29 deletions(-) diff --git a/docs/zh/introduction/Architecture.md b/docs/zh/introduction/Architecture.md index 34b93c3d..9ed9e28a 100644 --- a/docs/zh/introduction/Architecture.md +++ b/docs/zh/introduction/Architecture.md @@ -1,84 +1,80 @@ -```md displayed_sidebar: docs import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' # 架构 +StarRocks 架构出色。整个系统仅包含两类组件：“前端节点”和“后端节点”。前端节点称为 FE。后端节点分为 BE 和 CN (计算节点) 两种。当数据使用本地存储时，部署 BE；当数据存储在对象存储或 HDFS 上时，部署 CN。StarRocks 不依赖任何外部组件，从而简化了部署和维护。节点可以进行不停机水平扩展。此外，StarRocks 为元数据和服务数据提供了副本机制，提高了数据可靠性，并有效防止了单点故障 (SPOFs)。 -StarRocks 具有强大的架构。整个系统仅由两种类型的组件组成："前端" 和 "后端"。前端节点被称为 **FE**。后端节点分为两种类型：**BE** 和 **CN**（计算节点）。当数据使用本地存储时，部署 BE；当数据存储在对象存储或 HDFS 上时，部署 CN。StarRocks 不依赖任何外部组件，从而简化了部署和维护。节点可以水平扩展而无需停机。此外，StarRocks 具有元数据和服务数据的副本机制，这提高了数据可靠性并有效防止了单点故障 (SPOFs)。 - -StarRocks 兼容 MySQL 通信协议并支持标准 SQL。用户可以通过 MySQL 客户端连接到 StarRocks，以获取即时且有价值的洞察。 +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。 +在存算一体架构中，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 选举** | +| **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 选举压力。| +| 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。 -在存算分离集群中，数据文件格式与存算一体集群（具有存储和计算耦合的特点）保持一致。数据被组织成 Segment 文件，并且各种索引技术在存算分离表中得到复用，这些表是专门在存算分离集群中使用的表。 +在存算分离集群中，数据文件格式与存算一体集群 (其特点是存储与计算耦合) 保持一致。数据被组织成 Segment 文件，各种索引技术在存算分离表 (专门用于存算分离集群的表) 中得到复用。 #### 缓存 -StarRocks 存算分离集群解耦了数据存储和计算，使得两者可以独立扩展，从而降低了成本并增强了弹性。然而，这种架构可能会影响查询性能。 +StarRocks 存算分离集群解耦了数据存储和计算，使其能够独立扩展，从而降低成本并增强弹性。然而，这种架构可能会影响查询性能。 -为了减轻影响，StarRocks 建立了涵盖内存、本地磁盘和远端存储的多层数据访问系统，以更好地满足各种业务需求。 +为了缓解这种影响，StarRocks 建立了一个多层数据访问系统，涵盖内存、本地磁盘和远端存储，以更好地满足各种业务需求。 -热数据查询直接扫描缓存，然后扫描本地磁盘；而冷数据需要从对象存储加载到本地缓存中，以加速后续查询。通过将热数据保持在靠近计算单元的位置，StarRocks 实现了真正的高性能计算和经济高效的存储。此外，冷数据的访问已通过数据预取策略进行了优化，有效消除了查询的性能限制。 +热数据查询直接扫描缓存，然后扫描本地磁盘；而冷数据需要从对象存储加载到本地缓存中，以加速后续查询。通过将热数据保持在计算单元附近，StarRocks 实现了真正的高性能计算和经济高效的存储。此外，通过数据预取策略优化了冷数据访问，有效消除了查询性能限制。 -在创建表时可以启用缓存。如果启用缓存，数据将同时写入本地磁盘和后端对象存储。查询期间，CN 节点首先从本地磁盘读取数据。如果未找到数据，它将从后端对象存储中检索，并同时缓存到本地磁盘。 +在创建表时可以启用缓存。如果启用缓存，数据将同时写入本地磁盘和后端对象存储。在查询期间，CN 节点首先从本地磁盘读取数据。如果未找到数据，则会从后端对象存储中检索数据并同时缓存到本地磁盘。 -``` From 150a21c779156d8aafd441af2e5a38e054c9049c Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 13 Feb 2026 03:17:29 +0000 Subject: [PATCH 3/3] chore: add automated translations Generated by markdown-translator Triggered by: @DanRoscigno --- docs/ja/introduction/Architecture.md | 83 +++++++++++++--------------- 1 file changed, 39 insertions(+), 44 deletions(-) diff --git a/docs/ja/introduction/Architecture.md b/docs/ja/introduction/Architecture.md index 1b857e9b..5d15b964 100644 --- a/docs/ja/introduction/Architecture.md +++ b/docs/ja/introduction/Architecture.md @@ -1,87 +1,82 @@ -```md ---- displayed_sidebar: docs ---- - import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx' -# Architecture - -StarRocks は堅牢なアーキテクチャを備えています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードには **BE** と **CN** (コンピュートノード) の2種類があります。データにローカルストレージを使用する場合に BE がデプロイされ、データがオブジェクトストレージまたは HDFS に保存される場合に CN がデプロイされます。StarRocks は外部コンポーネントに依存せず、デプロイとメンテナンスを簡素化します。ノードはサービス停止なしで水平にスケールできます。さらに、StarRocks はメタデータとサービスデータのレプリカメカニズムを備えており、データ信頼性を高め、単一障害点 (SPOF) を効率的に防止します。 +# アーキテクチャ -StarRocks は MySQL 通信プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから StarRocks に接続し、瞬時に貴重なインサイトを得ることができます。 +OK -## Architecture choices +StarRocks は優れたアーキテクチャを備えています。システム全体は「フロントエンド」と「バックエンド」の2種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードは **BE** と **CN** (コンピュートノード) の2種類に分けられます。データがローカルストレージを使用する場合、BE がデプロイされます。データがオブジェクトストレージまたは HDFS に保存される場合、CN がデプロイされます。StarRocks は外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードはダウンタイムなしで水平にスケールできます。さらに、StarRocks はメタデータとサービスデータの レプリカ メカニズムを備えており、データ信頼性を向上させ、単一障害点（SPOF）を効果的に防止します。 -StarRocks は、shared-nothing (各 BE がローカルストレージにデータの一部を保持する) と shared-data (すべてのデータがオブジェクトストレージまたは HDFS にあり、各 CN がローカルストレージにキャッシュのみを保持する) をサポートします。データの保存場所は、ニーズに基づいて決定します。 +StarRocks は MySQL 通信プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアント経由で StarRocks に接続し、即座に価値あるインサイトを得ることができます。 -![Architecture choices](../_assets/architecture_choices.png) +## アーキテクチャの選択肢 +StarRocks は、共有なしモード （各 BE がローカルストレージ上にデータの一部を所有する）と 共有データモード （すべてのデータが オブジェクトストレージ または HDFS に保存され、各 CN はローカルストレージ上にキャッシュのみを持つ）をサポートしています。必要に応じて、データの保存場所を決定できます。 -### Shared-nothing +![アーキテクチャの選択肢](../_assets/architecture_choices.png) -ローカルストレージは、リアルタイムクエリのクエリレイテンシを向上させます。 +### 共有なしモード +ローカルストレージは、リアルタイムクエリに対してより優れたクエリレイテンシーを提供します。 -典型的な大規模並列処理 (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 は 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 | 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 選出の負荷を増加させません。 | ##### BE 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つのストレージソリューションをサポートしています。 -共有データクラスタでは、データファイル形式は共有なしクラスタ (結合されたストレージとコンピュートを特徴とする) のものと一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術は、共有データクラスタで特別に使用されるクラウドネイティブテーブルで再利用されます。 +共有データクラスタ では、データファイル形式は 共有なしクラスタ （ストレージとコンピュートが結合されている）と一貫しています。データは セグメントファイル に整理され、様々なインデックス技術は、共有データクラスタ で特別に使用される クラウドネイティブテーブル で再利用されます。 -#### Cache +#### キャッシュ -StarRocks 共有データクラスタは、データストレージとコンピュートを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、柔軟性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 +StarRocks 共有データクラスタ は、データストレージとコンピュートを分離し、独立してスケーリングできるようにすることで、コストを削減し、柔軟性を向上させます。しかし、このアーキテクチャは クエリパフォーマンス に影響を与える可能性があります。 -この影響を軽減するために、StarRocks はメモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立し、さまざまなビジネスニーズに効率的に対応します。 +この影響を軽減するために、StarRocks はメモリ、ローカルディスク、および リモートストレージ をカバーする多層データアクセスシステムを確立し、さまざまなビジネスニーズにさらに対応できるようにしました。 -ホットデータに対するクエリは、直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。 +ホットデータクエリはキャッシュを直接スキャンし、次に ローカルディスク をスキャンします。一方、コールドデータは オブジェクトストレージ からローカルキャッシュに ロード され、後続のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータアクセスはデータプリフェッチ戦略を通じて最適化され、 クエリパフォーマンス の制限を効果的に排除しています。 -キャッシングはテーブル作成時に有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 +テーブルを作成する際にキャッシュを有効にできます。キャッシュが有効になっている場合、データは ローカルディスク とバックエンド オブジェクトストレージ の両方に同時に書き込まれます。クエリ中、CN ノードは最初に ローカルディスク からデータを読み取ります。データが見つからない場合、バックエンド オブジェクトストレージ から取得され、同時に ローカルディスク にキャッシュされます。 -```