test

docs/en/introduction/Architecture.md

@@ -5,7 +5,7 @@ import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx'
 
 # Architecture
 
-StarRocks has a simple architecture. The entire system consists of only two types of components; frontends and backends. The frontend nodes are called **FE**s. There are two types of backend nodes, **BE**s, and **CN**s (Compute Nodes). BEs are deployed when local storage for data is used, and CNs are deployed when data is stored on object storage or HDFS. StarRocks does not rely on any external components, simplifying deployment and maintenance. Nodes can be horizontally scaled without service downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which increases data reliability and efficiently prevents single points of failure (SPOFs).
+StarRocks has a robust architecture. The entire system consists of only two types of components; frontends and backends. The frontend nodes are called **FE**s. There are two types of backend nodes, **BE**s, and **CN**s (Compute Nodes). BEs are deployed when local storage for data is used, and CNs are deployed when data is stored on object storage or HDFS. StarRocks does not rely on any external components, simplifying deployment and maintenance. Nodes can be horizontally scaled without service downtime. In addition, StarRocks has a replica mechanism for metadata and service data, which increases data reliability and efficiently prevents single points of failure (SPOFs).
 
 StarRocks is compatible with MySQL protocols and supports standard SQL. Users can easily connect to StarRocks from MySQL clients to gain instant and valuable insights.
 

docs/en/quick_start/routine-load.md

@@ -10,8 +10,6 @@ description: Kafka routine load with shared-data storage
 import Clients from '../_assets/quick-start/_clientsCompose.mdx'
 import SQL from '../_assets/quick-start/_SQL.mdx'
 
-## About Routine Load
-
 Routine load is a method using Apache Kafka, or in this lab, Redpanda, to continuously stream data into StarRocks. The data is streamed into a Kafka topic, and a Routine Load job consumes the data into StarRocks. More details on Routine Load are provided at the end of the lab.
 
 ## About shared-data

docs/en/sql-reference/sql-functions/dict-functions/dict_mapping.md

@@ -6,7 +6,7 @@ displayed_sidebar: docs
 
 Returns the value mapped to the specified key in a dictionary table.
 
-This function is mainly used to simplify the application of a global dictionary table. During data loading into a target table, StarRocks automatically obtains the value mapped to the specified key from the dictionary table by using the input parameters in this function, and then loads the value into the target table.
+`dict_mapping` simplifies the application of a global dictionary table. During data loading into a target table, StarRocks automatically obtains the value mapped to the specified key from the dictionary table by using the input parameters in this function, and then loads the value into the target table.
 
 Since v3.2.5, StarRocks supports this function. Also, note that currently StarRocks's shared-data mode does not support this function.
 

docs/ja/introduction/Architecture.md

@@ -0,0 +1,74 @@
+---
+displayed_sidebar: docs
+---
+import QSOverview from '../_assets/commonMarkdown/quickstart-overview-tip.mdx'
+
+# アーキテクチャ
+
+StarRocks は、堅牢なアーキテクチャを備えています。システム全体は、フロントエンドとバックエンドの 2 種類のコンポーネントのみで構成されています。フロントエンドノードは **FE** と呼ばれます。バックエンドノードには、**BE** と **CN** (コンピュートノード) の 2 種類があります。BE はデータのローカルストレージが使用される場合にデプロイされ、CN はデータがオブジェクトストレージまたは HDFS に保存される場合にデプロイされます。StarRocks は外部コンポーネントに依存しないため、デプロイとメンテナンスが簡素化されます。ノードは、サービスを停止することなく水平方向に拡張できます。さらに、StarRocks にはメタデータとサービスデータのレプリカメカニズムがあり、データの信頼性を高め、シングルポイント障害 (SPOF) を効率的に防止します。
+
+StarRocks は MySQL プロトコルと互換性があり、標準 SQL をサポートしています。ユーザーは MySQL クライアントから StarRocks に簡単に接続して、即座に価値のある洞察を得ることができます。
+## アーキテクチャの選択
+
+StarRocks は、共有なし（各 BE はローカルストレージ上のデータの一部を持つ）と共有データ（すべてのデータはオブジェクトストレージまたは HDFS 上にあり、各 CN はローカルストレージ上にキャッシュのみを持つ）をサポートしています。必要に応じて、データの保存場所を決定できます。
+
+![アーキテクチャの選択](../_assets/architecture_choices.png)
+### 共有なし
+
+ローカルストレージは、リアルタイムクエリのクエリレイテンシを改善します。
+
+一般的な超並列処理（MPP）データベースとして、StarRocks は共有なしアーキテクチャをサポートしています。このアーキテクチャでは、BE はデータストレージと計算の両方を担当します。BE モードでローカルデータに直接アクセスすることで、ローカルでの計算が可能になり、データ転送やデータコピーを回避し、超高速なクエリと分析パフォーマンスを提供します。このアーキテクチャは、マルチレプリカデータストレージをサポートし、クラスタの高い同時実行性クエリを処理する能力を高め、データの信頼性を確保します。最適なクエリパフォーマンスを追求するシナリオに最適です。
+
+![shared-data-arch](../_assets/shared nothing.png)
+#### ノード
+
+共有なしアーキテクチャにおいて、StarRocks は FE と BE という2種類のノードで構成されています。
+
+- FE は、メタデータ管理と実行クエリプランの構築を担当します。
+- BE は、クエリプランを実行し、データを保存します。BE は、ローカルストレージを利用してクエリを高速化し、マルチレプリカメカニズムによって高いデータ可用性を確保します。
+##### FE
+
+FE は、メタデータ管理、クライアント接続管理、クエリプラン、およびクエリスケジューリングを担当します。各 FE は、BDB JE (Berkeley DB Java Edition) を使用して、メモリ内のメタデータの完全なコピーを保存および管理し、すべての FE で一貫したサービスを保証します。FE は、leader、follower、および observer として機能できます。leader ノードがクラッシュした場合、follower は Raft プロトコルに基づいて leader を選出します。
+
+| **FE Role** | **Metadata management**                                                                                                                                                                                                                                                                                                                                                                                                | **Leader election**                |
+| ----------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------------------------------- |
+| 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   | Observer は Leader FE からログを同期および再生して、メタデータを更新します。                                                                                                                                                                                                                                                                                                                                           | Observer は主に、クラスタのクエリの同時実行性を高めるために使用されます。Observer は Leader 選出に参加しないため、クラスタに Leader 選出の負荷を追加することはありません。|
+##### BE
+
+BEは、データストレージとSQL実行を担当します。
+
+- データストレージ：BEは同等のデータストレージ機能を持ちます。FEは、事前定義されたルールに基づいてデータをBEに分散します。BEは取り込まれたデータを変換し、必要な形式でデータを書き込み、データのインデックスを生成します。
+
+- SQL実行：FEは、各SQLクエリをクエリのセマンティクスに従って論理実行プランに解析し、次にその論理プランをBEで実行可能な物理実行プランに変換します。宛先データを格納するBEがクエリを実行します。これにより、データ伝送とコピーの必要がなくなり、高いクエリパフォーマンスを実現します。
+### 共有データ
+
+オブジェクトストレージとHDFSは、コスト、信頼性、および拡張性の利点を提供します。ストレージの拡張性に加えて、ストレージとコンピュートが分離されているため、データをリバランスすることなくCNノードを追加および削除できます。
+
+共有データアーキテクチャでは、BEは「コンピュートノード（CN）」に置き換えられます。コンピュートノードは、データコンピュートタスクとホットデータのキャッシュのみを担当します。データは、Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIOなどの低コストで信頼性の高いリモートストレージシステムに保存されます。キャッシュがヒットすると、クエリパフォーマンスは共有なしアーキテクチャのクエリパフォーマンスに匹敵します。CNノードは、必要に応じて数秒以内に追加または削除できます。このアーキテクチャにより、ストレージコストが削減され、より優れたリソース分離、高い弾力性と拡張性が確保されます。
+
+共有データアーキテクチャは、共有なしアーキテクチャと同様にシンプルなアーキテクチャを維持します。FEとCNの2種類のノードのみで構成されています。唯一の違いは、ユーザーがバックエンドのオブジェクトストレージをプロビジョニングする必要があることです。
+
+![shared-data-arch](../_assets/shared-data.png)
+#### ノード
+
+共有データアーキテクチャにおけるコーディネーターノードは、共有なしアーキテクチャにおける FE と同じ機能を提供します。
+
+BE は CN (コンピュートノード) に置き換えられ、ストレージ機能はオブジェクトストレージまたは HDFS にオフロードされます。CN はステートレスなコンピュートノードであり、データのストレージを除く BE のすべての機能を実行します。
+#### ストレージ
+
+StarRocks の共有データクラスタは、オブジェクトストレージ（例えば、AWS S3、Google GCS、Azure Blob Storage、または MinIO）と HDFS の2つのストレージソリューションをサポートしています。
+
+共有データクラスタでは、データファイル形式は、（ストレージとコンピュートが結合された）共有なしクラスタと一貫性を保ちます。データはセグメントファイルに編成され、様々なインデックス技術がクラウドネイティブテーブルで再利用されます。クラウドネイティブテーブルは、共有データクラスタで特に使用されるテーブルです。
+#### キャッシュ
+
+StarRocks の共有データクラスタは、データストレージとコンピュートを分離し、それぞれが独立して拡張できるようにすることで、コストを削減し、弾力性を高めます。ただし、このアーキテクチャはクエリパフォーマンスに影響を与える可能性があります。
+
+その影響を軽減するために、StarRocks は、さまざまなビジネスニーズにより良く対応するために、メモリ、ローカルディスク、およびリモートストレージを包含する多層データアクセスシステムを確立します。
+
+ホットデータに対するクエリは、キャッシュを直接スキャンしてからローカルディスクをスキャンしますが、コールドデータは、後続のクエリを高速化するために、オブジェクトストレージからローカルキャッシュにロードする必要があります。ホットデータをコンピュートユニットの近くに保持することで、StarRocks は真に高性能なコンピュートと費用対効果の高いストレージを実現します。さらに、コールドデータへのアクセスは、データプリフェッチ戦略で最適化されており、クエリのパフォーマンス制限を効果的に排除します。
+
+キャッシングは、テーブルの作成時に有効にできます。キャッシングが有効になっている場合、データはローカルディスクとバックエンドのオブジェクトストレージの両方に書き込まれます。クエリ中、CN ノードは最初にローカルディスクからデータを読み取ります。データが見つからない場合は、バックエンドのオブジェクトストレージから取得され、同時にローカルディスクにキャッシュされます。
+
+<QSOverview />