diff --git a/docs/en/introduction/Architecture.md b/docs/en/introduction/Architecture.md index 09428b7e..173aca67 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). +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..70949a94 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 に接続し、瞬時に貴重なインサイトを得ることができます。 +システム全体は、「フロントエンド」と「バックエンド」の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共有データクラスターは、2つのストレージソリューションをサポートしています。オブジェクトストレージ (AWS S3、Google GCS、Azure Blob Storage、MinIOなど) とHDFSです。 -共有データクラスタでは、データファイル形式は共有なしクラスタ (結合されたストレージとコンピュートを特徴とする) のものと一貫しています。データはセグメントファイルに整理され、さまざまなインデックス技術は、共有データクラスタで特別に使用されるクラウドネイティブテーブルで再利用されます。 +共有データクラスターでは、データファイル形式は共有型クラスター（ストレージとコンピューティングが結合されている）と一貫しています。データはセグメントファイルに編成され、共有データクラスターで特に使用されるテーブルであるクラウドネイティブテーブルでは、さまざまなインデックス技術が再利用されます。 -#### Cache +#### キャッシュ -StarRocks 共有データクラスタは、データストレージとコンピュートを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、柔軟性を高めます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 +StarRocksの共有データクラスターは、データストレージとコンピューティングを分離し、それぞれを独立してスケーリングできるようにすることで、コストを削減し、弾力性を向上させます。しかし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。 -この影響を軽減するために、StarRocks はメモリ、ローカルディスク、およびリモートストレージを含む多層データアクセスシステムを確立し、さまざまなビジネスニーズに効率的に対応します。 +影響を軽減するため、StarRocksはメモリ、ローカルディスク、リモートストレージをカバーする多層データアクセスシステムを構築し、さまざまなビジネスニーズにより良く対応しています。 -ホットデータに対するクエリは、直接キャッシュをスキャンし、次にローカルディスクをスキャンします。一方、コールドデータはオブジェクトストレージからローカルキャッシュにロードして、その後のクエリを高速化する必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスはデータプリフェッチ戦略で最適化され、クエリのパフォーマンス制限を効果的に排除します。 +ホットデータクエリはキャッシュを直接スキャンし、その後ローカルディスクをスキャンします。一方、コールドデータは後続のクエリを高速化するために、オブジェクトストレージからローカルキャッシュにロードされる必要があります。ホットデータをコンピューティングユニットの近くに保持することで、StarRocksは真に高性能なコンピューティングと費用対効果の高いストレージを実現します。さらに、コールドデータアクセスはデータプリフェッチ戦略を通じて最適化されており、クエリパフォーマンスの制限を効果的に排除しています。 -キャッシングはテーブル作成時に有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 +テーブル作成時にキャッシングを有効にできます。キャッシングが有効な場合、データはローカルディスクとバックエンドオブジェクトストレージの両方に同時に書き込まれます。クエリ中、CNノードはまずローカルディスクからデータを読み取ります。データが見つからない場合、バックエンドオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。 -```