[Doc] Update Japanese translation file (#57829)
Signed-off-by: DanRoscigno <dan@roscigno.com>
This commit is contained in:
Dan Roscigno
GitHub
parent
dce1260579
commit
dcfbdf588e
|
|
@ -6,17 +6,17 @@ displayed_sidebar: docs
|
|||
|
||||
クエリパフォーマンスを最適化する方法は、よくある質問です。遅いクエリはユーザーエクスペリエンスやクラスターパフォーマンスに悪影響を与えます。クエリパフォーマンスを分析し、最適化することが重要です。
|
||||
|
||||
クエリ情報は `fe/log/fe.audit.log` で確認できます。各クエリには `QueryID` が対応しており、それを使用してクエリの `QueryPlan` と `Profile` を検索できます。`QueryPlan` は、FE が SQL 文を解析して生成した実行プランです。`Profile` は BE の実行結果で、各ステップで消費された時間や処理されたデータ量などの情報を含みます。
|
||||
`fe/log/fe.audit.log` でクエリ情報を確認できます。各クエリには `QueryID` が対応しており、これを使用してクエリの `QueryPlan` と `Profile` を検索できます。`QueryPlan` は、FE が SQL ステートメントを解析して生成する実行プランです。`Profile` は BE の実行結果で、各ステップにかかる時間や各ステップで処理されるデータ量などの情報を含みます。
|
||||
|
||||
## プラン分析
|
||||
|
||||
StarRocks では、SQL 文のライフサイクルはクエリ解析、クエリ計画、クエリ実行の3つのフェーズに分けられます。分析ワークロードの必要な QPS は高くないため、クエリ解析は一般的にボトルネックにはなりません。
|
||||
StarRocks では、SQL ステートメントのライフサイクルはクエリ解析、クエリプランニング、クエリ実行の3つのフェーズに分けられます。分析ワークロードに必要な QPS は高くないため、クエリ解析は一般的にボトルネックにはなりません。
|
||||
|
||||
StarRocks のクエリパフォーマンスは、クエリ計画とクエリ実行によって決まります。クエリ計画はオペレーター (Join/Order/Aggregate) を調整し、クエリ実行は具体的な操作を実行します。
|
||||
StarRocks におけるクエリパフォーマンスは、クエリプランニングとクエリ実行によって決まります。クエリプランニングはオペレーター (Join/Order/Aggregate) を調整する役割を担い、クエリ実行は具体的な操作を実行する役割を担います。
|
||||
|
||||
クエリプランは、DBA にクエリ情報をマクロ的にアクセスするための手段を提供します。クエリプランはクエリパフォーマンスの鍵であり、DBA が参照するための良いリソースです。以下のコードスニペットは、`TPCDS query96` を例にしてクエリプランの表示方法を示しています。
|
||||
クエリプランは、DBA にクエリ情報をマクロ的に把握するための手段を提供します。クエリプランはクエリパフォーマンスの鍵であり、DBA が参照するための良いリソースです。以下のコードスニペットは、`TPCDS query96` を例にとり、クエリプランの確認方法を示しています。
|
||||
|
||||
クエリのプランを表示するには、[EXPLAIN](../sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md) ステートメントを使用します。
|
||||
[EXPLAIN](../sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md) ステートメントを使用して、クエリのプランを確認します。
|
||||
|
||||
~~~SQL
|
||||
EXPLAIN select count(*)
|
||||
|
|
@ -179,34 +179,34 @@ order by count(*) limit 100;
|
|||
|avgRowSize|スキャンされたデータ行の平均サイズ|
|
||||
|cardinality|スキャンされたテーブルのデータ行の総数|
|
||||
|colocate|テーブルがコロケートモードかどうか|
|
||||
|numNodes|スキャンされるノードの数|
|
||||
|numNodes|スキャンするノードの数|
|
||||
|rollup|マテリアライズドビュー|
|
||||
|preaggregation|事前集計|
|
||||
|predicates|述語、クエリフィルター|
|
||||
|predicates|クエリフィルター|
|
||||
|
||||
クエリ 96 のクエリプランは、0 から 4 までの5つのフラグメントに分かれています。クエリプランは、下から上に一つずつ読むことができます。
|
||||
クエリ 96 のクエリプランは、0 から 4 までの番号が付けられた 5 つのフラグメントに分かれています。クエリプランは、下から上に一つずつ読んでいくことができます。
|
||||
|
||||
フラグメント 4 は `time_dim` テーブルをスキャンし、関連するクエリ条件（例えば、`time_dim.t_hour = 8 and time_dim.t_minute >= 30`）を事前に実行します。このステップは述語プッシュダウンとも呼ばれます。StarRocks は集計テーブルに対して `PREAGGREGATION` を有効にするかどうかを決定します。前の図では、`time_dim` の事前集計は無効になっています。この場合、`time_dim` のすべてのディメンション列が読み取られ、テーブルに多くのディメンション列がある場合、パフォーマンスに悪影響を与える可能性があります。`time_dim` テーブルがデータ分割に `range partition` を選択した場合、クエリプランでいくつかのパーティションがヒットし、関連のないパーティションは自動的にフィルタリングされます。マテリアライズドビューがある場合、StarRocks はクエリに基づいてマテリアライズドビューを自動的に選択します。マテリアライズドビューがない場合、クエリは自動的にベーステーブルにヒットします（例えば、前の図の `rollup: time_dim`）。
|
||||
フラグメント 4 は、`time_dim` テーブルをスキャンし、関連するクエリ条件 (例えば、`time_dim.t_hour = 8 and time_dim.t_minute >= 30`) を事前に実行する役割を担っています。このステップは、述語プッシュダウンとも呼ばれます。StarRocks は、集計テーブルに対して `PREAGGREGATION` を有効にするかどうかを決定します。前の図では、`time_dim` の事前集計は無効になっています。この場合、`time_dim` のすべてのディメンション列が読み取られ、テーブルに多くのディメンション列がある場合、パフォーマンスに悪影響を及ぼす可能性があります。`time_dim` テーブルがデータ分割のために `range partition` を選択している場合、クエリプランでいくつかのパーティションがヒットし、無関係なパーティションは自動的にフィルタリングされます。マテリアライズドビューがある場合、StarRocks はクエリに基づいて自動的にマテリアライズドビューを選択します。マテリアライズドビューがない場合、クエリは自動的にベーステーブルにヒットします (例えば、前の図の `rollup: time_dim`)。
|
||||
|
||||
スキャンが完了すると、フラグメント 4 は終了します。データは、前の図で示されているように EXCHANGE ID : 09 によって他のフラグメントに渡され、受信ノードラベル 9 に送られます。
|
||||
スキャンが完了すると、フラグメント 4 は終了します。データは、前の図で示されているように EXCHANGE ID : 09 によって、受信ノードラベル 9 に渡されます。
|
||||
|
||||
クエリ 96 のクエリプランでは、フラグメント 2、3、および 4 は同様の機能を持っていますが、異なるテーブルをスキャンする役割を担っています。具体的には、クエリ内の `Order/Aggregation/Join` 操作はフラグメント 1 で実行されます。
|
||||
クエリ 96 のクエリプランでは、フラグメント 2、3、4 は似た機能を持っていますが、異なるテーブルをスキャンする役割を担っています。具体的には、クエリ内の `Order/Aggregation/Join` 操作はフラグメント 1 で実行されます。
|
||||
|
||||
フラグメント 1 は `BROADCAST` メソッドを使用して `Order/Aggregation/Join` 操作を実行します。これは、小さなテーブルを大きなテーブルにブロードキャストすることを意味します。両方のテーブルが大きい場合は、`SHUFFLE` メソッドを使用することをお勧めします。現在、StarRocks は `HASH JOIN` のみをサポートしています。`colocate` フィールドは、結合された2つのテーブルが同じ方法でパーティション化およびバケット化されていることを示し、データを移動せずにローカルでジョイン操作を実行できることを示します。ジョイン操作が完了すると、上位レベルの `aggregation`、`order by`、および `top-n` 操作が実行されます。
|
||||
フラグメント 1 は、`BROADCAST` メソッドを使用して `Order/Aggregation/Join` 操作を実行します。つまり、小さなテーブルを大きなテーブルにブロードキャストします。両方のテーブルが大きい場合は、`SHUFFLE` メソッドを使用することをお勧めします。現在、StarRocks は `HASH JOIN` のみをサポートしています。`colocate` フィールドは、結合された 2 つのテーブルが同じ方法でパーティション分割およびバケット化されていることを示し、データを移動せずにローカルでジョイン操作を実行できることを示します。ジョイン操作が完了すると、上位レベルの `aggregation`、`order by`、および `top-n` 操作が実行されます。
|
||||
|
||||
特定の式を削除することで（オペレーターのみを保持）、クエリプランはよりマクロ的なビューで表示できます。以下の図に示されています。
|
||||
特定の式を削除し (オペレーターのみを保持)、クエリプランをよりマクロ的な視点で提示することができます。以下の図に示されています。
|
||||
|
||||
|
||||
|
||||
## クエリヒント
|
||||
|
||||
クエリヒントは、クエリオプティマイザにクエリの実行方法を明示的に提案する指示またはコメントです。現在、StarRocks は3種類のヒントをサポートしています：システム変数ヒント (`SET_VAR`)、ユーザー定義変数ヒント (`SET_USER_VARIABLE`)、および Join ヒントです。ヒントは単一のクエリ内でのみ有効です。
|
||||
クエリヒントは、クエリオプティマイザにクエリの実行方法を明示的に提案する指示またはコメントです。現在、StarRocks は 3 種類のヒントをサポートしています: システム変数ヒント (`SET_VAR`)、ユーザー定義変数ヒント (`SET_USER_VARIABLE`)、および Join ヒントです。ヒントは単一のクエリ内でのみ効果を発揮します。
|
||||
|
||||
### システム変数ヒント
|
||||
|
||||
`SET_VAR` ヒントを使用して、SELECT および SUBMIT TASK ステートメントで1つ以上の[システム変数](../sql-reference/System_variable.md)を設定し、その後ステートメントを実行できます。また、CREATE MATERIALIZED VIEW AS SELECT や CREATE VIEW AS SELECT などの他のステートメントに含まれる SELECT 句でも `SET_VAR` ヒントを使用できます。注意すべき点は、`SET_VAR` ヒントが CTE の SELECT 句で使用された場合、ステートメントが正常に実行されても `SET_VAR` ヒントは有効にならないことです。
|
||||
`SET_VAR` ヒントを使用して、SELECT および SUBMIT TASK ステートメントで 1 つ以上の [システム変数](../sql-reference/System_variable.md) を設定し、ステートメントを実行できます。また、CREATE MATERIALIZED VIEW AS SELECT および CREATE VIEW AS SELECT などの他のステートメントに含まれる SELECT 句でも `SET_VAR` ヒントを使用できます。CTE の SELECT 句で `SET_VAR` ヒントを使用した場合、ステートメントが正常に実行されても `SET_VAR` ヒントは効果を発揮しないことに注意してください。
|
||||
|
||||
[システム変数の一般的な使用法](../sql-reference/System_variable.md)と比較して、`SET_VAR` ヒントはステートメントレベルで有効であり、セッション全体には影響しません。
|
||||
[システム変数の一般的な使用法](../sql-reference/System_variable.md) と比較して、`SET_VAR` ヒントはステートメントレベルで効果を発揮し、セッション全体には影響を与えません。
|
||||
|
||||
#### 構文
|
||||
|
||||
|
|
@ -242,9 +242,9 @@ AS SELECT /*+ SET_VAR(query_timeout=500) */ * from dual;
|
|||
|
||||
### ユーザー定義変数ヒント
|
||||
|
||||
`SET_USER_VARIABLE` ヒントを使用して、SELECT ステートメントまたは INSERT ステートメントで1つ以上の[ユーザー定義変数](../sql-reference/user_defined_variables.md)を設定できます。他のステートメントが SELECT 句を含む場合、その SELECT 句でも `SET_USER_VARIABLE` ヒントを使用できます。他のステートメントは SELECT ステートメントおよび INSERT ステートメントである必要がありますが、CREATE MATERIALIZED VIEW AS SELECT ステートメントおよび CREATE VIEW AS SELECT ステートメントでは使用できません。注意すべき点は、`SET_USER_VARIABLE` ヒントが CTE の SELECT 句で使用された場合、ステートメントが正常に実行されても `SET_USER_VARIABLE` ヒントは有効にならないことです。v3.2.4 以降、StarRocks はユーザー定義変数ヒントをサポートしています。
|
||||
`SET_USER_VARIABLE` ヒントを使用して、SELECT ステートメントまたは INSERT ステートメントで 1 つ以上の [ユーザー定義変数](../sql-reference/user_defined_variables.md) を設定できます。他のステートメントに SELECT 句が含まれている場合、その SELECT 句でも `SET_USER_VARIABLE` ヒントを使用できます。他のステートメントは SELECT ステートメントおよび INSERT ステートメントであることができますが、CREATE MATERIALIZED VIEW AS SELECT ステートメントおよび CREATE VIEW AS SELECT ステートメントでは使用できません。CTE の SELECT 句で `SET_USER_VARIABLE` ヒントを使用した場合、ステートメントが正常に実行されても `SET_USER_VARIABLE` ヒントは効果を発揮しないことに注意してください。v3.2.4 以降、StarRocks はユーザー定義変数ヒントをサポートしています。
|
||||
|
||||
[ユーザー定義変数の一般的な使用法](../sql-reference/user_defined_variables.md)と比較して、`SET_USER_VARIABLE` ヒントはステートメントレベルで有効であり、セッション全体には影響しません。
|
||||
[ユーザー定義変数の一般的な使用法](../sql-reference/user_defined_variables.md) と比較して、`SET_USER_VARIABLE` ヒントはステートメントレベルで効果を発揮し、セッション全体には影響を与えません。
|
||||
|
||||
#### 構文
|
||||
|
||||
|
|
@ -255,7 +255,7 @@ INSERT /*+ SET_USER_VARIABLE(@var_name = expr [, @var_name = expr]) */ ...
|
|||
|
||||
#### 例
|
||||
|
||||
次の SELECT ステートメントは、スカラーサブクエリ `select max(age) from users` および `select min(name) from users` を参照しているため、`SET_USER_VARIABLE` ヒントを使用してこれらの2つのスカラーサブクエリをユーザー定義変数として設定し、その後クエリを実行できます。
|
||||
以下の SELECT ステートメントは、スカラーサブクエリ `select max(age) from users` と `select min(name) from users` を参照しています。そのため、`SET_USER_VARIABLE` ヒントを使用して、これらの 2 つのスカラーサブクエリをユーザー定義変数として設定し、クエリを実行できます。
|
||||
|
||||
~~~SQL
|
||||
SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select min(name) from users)) */ * FROM sales_orders where sales_orders.age = @a and sales_orders.name = @b;
|
||||
|
|
@ -263,7 +263,7 @@ SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select mi
|
|||
|
||||
### Join ヒント
|
||||
|
||||
複数テーブルの Join クエリにおいて、オプティマイザは通常、最適な Join 実行方法を選択します。特別な場合には、Join ヒントを使用してオプティマイザに Join 実行方法を明示的に提案したり、Join Reorder を無効にすることができます。現在、Join ヒントは Shuffle Join、Broadcast Join、Bucket Shuffle Join、または Colocate Join を Join 実行方法として提案することをサポートしています。Join ヒントが使用されると、オプティマイザは Join Reorder を実行しません。そのため、より小さなテーブルを右側のテーブルとして選択する必要があります。さらに、[Colocate Join](../using_starrocks/Colocate_join.md) または Bucket Shuffle Join を Join 実行方法として提案する場合、結合されるテーブルのデータ分布がこれらの Join 実行方法の要件を満たしていることを確認する必要があります。そうでない場合、提案された Join 実行方法は効果を発揮しません。
|
||||
複数テーブルのジョインクエリにおいて、オプティマイザは通常、最適なジョイン実行方法を選択します。特別な場合には、ジョインヒントを使用して、オプティマイザにジョイン実行方法を明示的に提案したり、ジョインリオーダーを無効にすることができます。現在、ジョインヒントは、Shuffle Join、Broadcast Join、Bucket Shuffle Join、または Colocate Join をジョイン実行方法として提案することをサポートしています。ジョインヒントが使用されると、オプティマイザはジョインリオーダーを実行しません。そのため、小さいテーブルを右側のテーブルとして選択する必要があります。さらに、ジョイン実行方法として [Colocate Join](../using_starrocks/Colocate_join.md) または Bucket Shuffle Join を提案する場合、結合されたテーブルのデータ分布がこれらのジョイン実行方法の要件を満たしていることを確認してください。そうでない場合、提案されたジョイン実行方法は効果を発揮しません。
|
||||
|
||||
#### 構文
|
||||
|
||||
|
|
@ -273,13 +273,13 @@ SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select mi
|
|||
|
||||
> **注意**
|
||||
>
|
||||
> Join ヒントは大文字小文字を区別しません。
|
||||
> ジョインヒントは大文字小文字を区別しません。
|
||||
|
||||
#### 例
|
||||
|
||||
- Shuffle Join
|
||||
|
||||
Join 操作が実行される前に、テーブル A と B の同じバケッティングキー値を持つデータ行を同じマシンにシャッフルする必要がある場合、Join 実行方法を Shuffle Join としてヒントを与えることができます。
|
||||
ジョイン操作が実行される前に、テーブル A と B から同じバケッティングキー値を持つデータ行を同じマシンにシャッフルする必要がある場合、ジョイン実行方法を Shuffle Join としてヒントを与えることができます。
|
||||
|
||||
~~~SQL
|
||||
select k1 from t1 join [SHUFFLE] t2 on t1.k1 = t2.k2 group by t2.k2;
|
||||
|
|
@ -287,7 +287,7 @@ SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select mi
|
|||
|
||||
- Broadcast Join
|
||||
|
||||
テーブル A が大きなテーブルで、テーブル B が小さなテーブルの場合、Join 実行方法を Broadcast Join としてヒントを与えることができます。テーブル B のデータは、テーブル A のデータが存在するマシンに完全にブロードキャストされ、その後 Join 操作が実行されます。Shuffle Join と比較して、Broadcast Join はテーブル A のデータのシャッフルコストを節約します。
|
||||
テーブル A が大きなテーブルで、テーブル B が小さなテーブルの場合、ジョイン実行方法を Broadcast Join としてヒントを与えることができます。テーブル B のデータは、テーブル A のデータが存在するマシンに完全にブロードキャストされ、その後ジョイン操作が実行されます。Shuffle Join と比較して、Broadcast Join はテーブル A のデータをシャッフルするコストを節約します。
|
||||
|
||||
~~~SQL
|
||||
select k1 from t1 join [BROADCAST] t2 on t1.k1 = t2.k2 group by t2.k2;
|
||||
|
|
@ -295,7 +295,7 @@ SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select mi
|
|||
|
||||
- Bucket Shuffle Join
|
||||
|
||||
Join クエリの Join 等値結合式にテーブル A のバケッティングキーが含まれている場合、特にテーブル A と B の両方が大きなテーブルである場合、Join 実行方法を Bucket Shuffle Join としてヒントを与えることができます。テーブル B のデータは、テーブル A のデータ分布に従って、テーブル A のデータが存在するマシンにシャッフルされ、その後 Join 操作が実行されます。Broadcast Join と比較して、Bucket Shuffle Join はデータ転送を大幅に削減します。Bucket Shuffle Join に参加するテーブルは、非パーティション化されているか、コロケートされている必要があります。
|
||||
ジョインクエリのジョイン等値結合式にテーブル A のバケッティングキーが含まれている場合、特にテーブル A と B の両方が大きなテーブルである場合、ジョイン実行方法を Bucket Shuffle Join としてヒントを与えることができます。テーブル B のデータは、テーブル A のデータ分布に従って、テーブル A のデータが存在するマシンにシャッフルされ、その後ジョイン操作が実行されます。Broadcast Join と比較して、Bucket Shuffle Join はデータ転送を大幅に削減します。なぜなら、テーブル B のデータはグローバルに一度だけシャッフルされるからです。Bucket Shuffle Join に参加するテーブルは、非パーティション化されているか、コロケートされている必要があります。
|
||||
|
||||
~~~SQL
|
||||
select k1 from t1 join [BUCKET] t2 on t1.k1 = t2.k2 group by t2.k2;
|
||||
|
|
@ -303,15 +303,15 @@ SELECT /*+ SET_USER_VARIABLE (@a = (select max(age) from users), @b = (select mi
|
|||
|
||||
- Colocate Join
|
||||
|
||||
テーブル A と B がテーブル作成時に指定された同じ Colocation Group に属している場合、テーブル A と B の同じバケッティングキー値を持つデータ行は同じ BE ノードに分散されます。Join クエリの Join 等値結合式にテーブル A と B のバケッティングキーが含まれている場合、Join 実行方法を Colocate Join としてヒントを与えることができます。同じキー値を持つデータはローカルで直接結合され、ノード間のデータ転送にかかる時間を削減し、クエリパフォーマンスを向上させます。
|
||||
テーブル A と B がテーブル作成時に指定された同じ Colocation Group に属している場合、テーブル A と B から同じバケッティングキー値を持つデータ行は同じ BE ノードに分散されます。ジョインクエリのジョイン等値結合式にテーブル A と B のバケッティングキーが含まれている場合、ジョイン実行方法を Colocate Join としてヒントを与えることができます。同じキー値を持つデータはローカルで直接結合され、ノード間のデータ転送にかかる時間を削減し、クエリパフォーマンスを向上させます。
|
||||
|
||||
~~~SQL
|
||||
select k1 from t1 join [COLOCATE] t2 on t1.k1 = t2.k2 group by t2.k2;
|
||||
~~~
|
||||
|
||||
#### Join 実行方法の表示
|
||||
#### ジョイン実行方法の確認
|
||||
|
||||
`EXPLAIN` コマンドを使用して、実際の Join 実行方法を確認します。返された結果が Join ヒントと一致する場合、Join ヒントが有効であることを意味します。
|
||||
`EXPLAIN` コマンドを使用して、実際のジョイン実行方法を確認します。返された結果がジョインヒントと一致する場合、ジョインヒントが有効であることを意味します。
|
||||
|
||||
~~~SQL
|
||||
EXPLAIN select k1 from t1 join [COLOCATE] t2 on t1.k1 = t2.k2 group by t2.k2;
|
||||
|
|
@ -321,23 +321,23 @@ EXPLAIN select k1 from t1 join [COLOCATE] t2 on t1.k1 = t2.k2 group by t2.k2;
|
|||
|
||||
## SQL フィンガープリント
|
||||
|
||||
SQL フィンガープリントは、遅いクエリを最適化し、システムリソースの利用を改善するために使用されます。StarRocks は、遅いクエリログ (`fe.audit.log.slow_query`) 内の SQL 文を正規化し、SQL 文を異なるタイプに分類し、各 SQL タイプの MD5 ハッシュ値を計算して遅いクエリを識別します。MD5 ハッシュ値はフィールド `Digest` によって指定されます。
|
||||
SQL フィンガープリントは、遅いクエリを最適化し、システムリソースの利用を向上させるために使用されます。StarRocks は、遅いクエリログ (`fe.audit.log.slow_query`) で SQL フィンガープリント機能を使用して SQL ステートメントを正規化し、SQL ステートメントを異なるタイプに分類し、各 SQL タイプの MD5 ハッシュ値を計算して遅いクエリを識別します。MD5 ハッシュ値は、フィールド `Digest` によって指定されます。
|
||||
|
||||
~~~SQL
|
||||
2021-12-27 15:13:39,108 [slow_query] |Client=172.26.xx.xxx:54956|User=root|Db=default_cluster:test|State=EOF|Time=2469|ScanBytes=0|ScanRows=0|ReturnRows=6|StmtId=3|QueryId=824d8dc0-66e4-11ec-9fdc-00163e04d4c2|IsQuery=true|feIp=172.26.92.195|Stmt=select count(*) from test_basic group by id_bigint|Digest=51390da6b57461f571f0712d527320f4
|
||||
~~~
|
||||
|
||||
SQL 文の正規化は、ステートメントテキストをより正規化された形式に変換し、重要なステートメント構造のみを保持します。
|
||||
SQL ステートメントの正規化は、ステートメントテキストをより正規化された形式に変換し、重要なステートメント構造のみを保持します。
|
||||
|
||||
- データベース名やテーブル名などのオブジェクト識別子を保持します。
|
||||
|
||||
- 定数を疑問符（?）に変換します。
|
||||
- 定数を疑問符 (?) に変換します。
|
||||
|
||||
- コメントを削除し、スペースをフォーマットします。
|
||||
|
||||
例えば、以下の2つの SQL 文は、正規化後に同じタイプに属します。
|
||||
例えば、以下の 2 つの SQL ステートメントは、正規化後に同じタイプに属します。
|
||||
|
||||
- 正規化前の SQL 文
|
||||
- 正規化前の SQL ステートメント
|
||||
|
||||
~~~SQL
|
||||
SELECT * FROM orders WHERE customer_id=10 AND quantity>20
|
||||
|
|
@ -347,7 +347,7 @@ SELECT * FROM orders WHERE customer_id=10 AND quantity>20
|
|||
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100
|
||||
~~~
|
||||
|
||||
- 正規化後の SQL 文
|
||||
- 正規化後の SQL ステートメント
|
||||
|
||||
~~~SQL
|
||||
SELECT * FROM orders WHERE customer_id=? AND quantity>?
|
||||
|
|
|
|||
|
|
@ -4,69 +4,69 @@ displayed_sidebar: docs
|
|||
|
||||
# Features
|
||||
|
||||
StarRocks は、スケールに応じたデータに対して高速でリアルタイムな分析体験を提供する豊富な機能を備えています。
|
||||
StarRocks は、スケールされたデータに対して超高速でリアルタイムな分析体験を提供する豊富な機能セットを備えています。
|
||||
|
||||
## MPP フレームワーク
|
||||
|
||||
StarRocks は、マッシブリー・パラレル・プロセッシング (MPP) フレームワークを採用しています。1 つのクエリリクエストは、複数の物理的な計算ユニットに分割され、複数のマシンで並行して実行されます。各マシンには専用の CPU とメモリリソースがあります。MPP フレームワークは、すべての CPU コアとマシンのリソースをフルに活用します。クラスターをスケールアウトすることで、単一クエリのパフォーマンスを継続的に向上させることができます。
|
||||
StarRocks は、マッシブリー・パラレル・プロセッシング (MPP) フレームワークを採用しています。1 つのクエリリクエストは、複数の物理的な計算ユニットに分割され、複数のマシンで並行して実行されます。各マシンには専用の CPU とメモリリソースがあります。MPP フレームワークは、すべての CPU コアとマシンのリソースを完全に活用します。クラスターをスケールアウトすることで、単一クエリのパフォーマンスを継続的に向上させることができます。
|
||||
|
||||
|
||||
|
||||
上の図では、StarRocks は SQL ステートメントをそのセマンティクスに基づいて複数の論理実行ユニット（クエリフラグメント）に解析します。各フラグメントは、計算の複雑さに基づいて、1 つまたは複数の物理実行ユニット（フラグメントインスタンス）によって実装されます。物理実行ユニットは、StarRocks における最小のスケジューリングユニットです。これらはバックエンド (BEs) にスケジュールされて実行されます。1 つの論理実行ユニットは、Scan、Project、Agg オペレーターなど、1 つ以上のオペレーターを含むことができます。各物理実行ユニットはデータの一部のみを処理し、その結果がマージされて最終的なデータが生成されます。**論理実行ユニットの並列実行は、すべての CPU コアと物理マシンのリソースをフルに活用し、クエリ速度を加速します。**
|
||||
上記の図では、StarRocks は SQL ステートメントをそのセマンティクスに基づいて複数の論理実行ユニット（クエリフラグメント）に解析します。各フラグメントは、計算の複雑さに基づいて、1 つまたは複数の物理実行ユニット（フラグメントインスタンス）によって実装されます。物理実行ユニットは、StarRocks における最小のスケジューリングユニットです。これらはバックエンド（BEs）にスケジュールされて実行されます。1 つの論理実行ユニットは、図の右側に示されているように、Scan、Project、Agg オペレーターなど、1 つ以上のオペレーターを含むことができます。各物理実行ユニットはデータの一部のみを処理し、その結果は最終データを生成するためにマージされます。**論理実行ユニットの並列実行は、すべての CPU コアと物理マシンのリソースを完全に活用し、クエリ速度を加速します。**
|
||||
|
||||
|
||||
|
||||
多くの他のデータ分析システムで使用される Scatter-Gather フレームワークとは異なり、MPP フレームワークはクエリリクエストを処理するためにより多くのリソースを活用できます。Scatter-Gather フレームワークでは、最終的なマージ操作を実行できるのは Gather ノードのみです。MPP フレームワークでは、データはマージ操作のために複数のノードにシャッフルされます。高カーディナリティフィールドでの Group By や大規模テーブルジョインなどの複雑なクエリにおいて、StarRocks の MPP フレームワークは Scatter-Gather フレームワークに比べて顕著なパフォーマンスの優位性を持っています。
|
||||
多くの他のデータ分析システムで使用される Scatter-Gather フレームワークとは異なり、MPP フレームワークは、クエリリクエストを処理するためにより多くのリソースを活用できます。Scatter-Gather フレームワークでは、最終的なマージ操作を実行できるのは Gather ノードのみです。MPP フレームワークでは、データはマージ操作のために複数のノードにシャッフルされます。高カーディナリティフィールドの Group By や大規模テーブルのジョインなどの複雑なクエリにおいて、StarRocks の MPP フレームワークは Scatter-Gather フレームワークに比べて顕著なパフォーマンスの利点があります。
|
||||
|
||||
## 完全ベクトル化された実行エンジン
|
||||
## 完全ベクトル化実行エンジン
|
||||
|
||||
完全ベクトル化された実行エンジンは、データを列指向で組織し処理するため、CPU 処理能力をより効率的に活用します。具体的には、StarRocks はデータを保存し、メモリ内でデータを組織し、SQL オペレーターをすべて列指向で計算します。列指向の組織は CPU キャッシュをフルに活用します。列指向の計算は、仮想関数呼び出しと分岐判断の数を減らし、より十分な CPU 命令フローを実現します。
|
||||
完全ベクトル化実行エンジンは、データを列指向で整理し処理するため、CPU 処理能力をより効率的に活用します。具体的には、StarRocks はデータを保存し、メモリ内でデータを整理し、SQL オペレーターをすべて列指向で計算します。列指向の組織化は、CPU キャッシュを最大限に活用します。列指向の計算は、仮想関数呼び出しや分岐判断の数を減らし、より十分な CPU 命令フローを実現します。
|
||||
|
||||
ベクトル化された実行エンジンはまた、SIMD 命令をフルに活用します。このエンジンは、より少ない命令でより多くのデータ操作を完了できます。標準データセットに対するテストでは、このエンジンがオペレーターの全体的なパフォーマンスを 3 倍から 10 倍向上させることが示されています。
|
||||
ベクトル化実行エンジンは、SIMD 命令も最大限に活用します。このエンジンは、より少ない命令でより多くのデータ操作を完了できます。標準データセットに対するテストでは、このエンジンがオペレーターの全体的なパフォーマンスを 3 倍から 10 倍に向上させることが示されています。
|
||||
|
||||
オペレーターのベクトル化に加えて、StarRocks はクエリエンジンのために他の最適化も実装しています。例えば、StarRocks は Operation on Encoded Data 技術を使用して、エンコードされた文字列上で直接オペレーターを実行し、デコードの必要をなくしています。これにより、SQL の複雑さが顕著に減少し、クエリ速度が 2 倍以上向上します。
|
||||
オペレーターのベクトル化に加えて、StarRocks はクエリエンジンに対して他の最適化も実装しています。たとえば、StarRocks は Operation on Encoded Data 技術を使用して、エンコードされた文字列に対して直接オペレーターを実行し、デコードの必要をなくしています。これにより、SQL の複雑さが顕著に減少し、クエリ速度が 2 倍以上に向上します。
|
||||
|
||||
## ストレージとコンピュートの分離
|
||||
|
||||
[storage-compute separation architecture](./Architecture.md) は 3.0 から導入されました。このアーキテクチャでは、コンピューティングとストレージが分離され、リソースの分離、コンピュートノードの弾力的なスケーリング、高性能なクエリを実現します。ストレージとコンピュートの分離は、StarRocks により高い柔軟性、性能、データの可用性、低コストをもたらします。
|
||||
[storage-compute separation architecture](./Architecture.md) は 3.0 から導入されました。このアーキテクチャでは、コンピューティングとストレージが分離され、リソースの分離、コンピュートノードの弾力的なスケーリング、高性能なクエリを実現します。ストレージとコンピュートの分離により、StarRocks はより柔軟で高性能、データの可用性が向上し、コストが低減されます。
|
||||
|
||||
|
||||
|
||||
ストレージとコンピュートの分離モードでは、コンピューティングとストレージが分離され、独立してスケーリング可能であり、ユーザーがコンピュートノードを追加したいときにストレージをスケールする必要があるというストレージとコンピュートが結合されたモードで長く存在していたコストを排除します。さらに、コンピューティングは数秒以内に動的にスケールし、特にトラフィックのピークと谷が顕著な場合にリソース利用率を向上させます。
|
||||
ストレージとコンピュートの分離モードでは、コンピューティングとストレージが分離され、独立してスケールできます。これにより、ストレージとコンピュートが結合されたモードで、ユーザーがコンピュートノードを追加したいときにストレージをスケールしなければならないという長年のコストが排除されます。さらに、コンピューティングは数秒以内に動的にスケールでき、特にトラフィックのピークと谷が顕著な場合にリソースの利用率を向上させます。
|
||||
|
||||
ストレージ層は、オブジェクトストレージのほぼ無制限の容量と高い信頼性を活用して、大量のデータストレージとデータの永続性を実現します。StarRocks は、AWS S3、Google Cloud Storage、Azure Blob Storage、HDFS、その他の S3 互換ストレージ（MinIO など）と連携できます。
|
||||
ストレージ層は、オブジェクトストレージのほぼ無制限の容量と高い信頼性を活用して、大量のデータストレージとデータの永続性を実現します。StarRocks は、AWS S3、Google Cloud Storage、Azure Blob Storage、HDFS、その他の S3 互換ストレージ（MinIO など）など、さまざまなオブジェクトストレージシステムと連携できます。
|
||||
|
||||
ユーザーは、StarRocks をパブリッククラウド、プライベートクラウド、またはオンプレミスのデータセンターにデプロイすることができます。StarRocks は Kubernetes ベースのデプロイメントをサポートし、ストレージとコンピュートが分離されたクラスターの自動デプロイメントのための Operator を提供します。
|
||||
|
||||
ストレージとコンピュートの分離モードにおける StarRocks は、ストレージとコンピュートが結合されたモードと同じ機能を提供します。データの書き込みとホットデータのクエリパフォーマンスも同様です。ユーザーは、ストレージとコンピュートが結合されたモードと同様に、データの更新、データレイク分析、マテリアライズドビューの加速を行うことができます。
|
||||
ストレージとコンピュートの分離モードの StarRocks は、ストレージとコンピュートが結合されたモードと同じ機能を提供します。データの書き込みとホットデータのクエリパフォーマンスも同様です。ユーザーは、ストレージとコンピュートが結合されたモードと同様に、データの更新、データレイク分析、マテリアライズドビューの加速を行うことができます。
|
||||
|
||||
## コストベースオプティマイザ
|
||||
|
||||
|
||||
|
||||
複数テーブルジョインクエリのパフォーマンスを最適化するのは難しいです。実行エンジンだけでは、複数テーブルジョインクエリのシナリオで実行計画の複雑さが数桁異なる可能性があるため、優れたパフォーマンスを提供することはできません。関連するテーブルが多いほど、実行計画も多くなり、最適な計画を選ぶのが NP 難しい問題になります。優れたクエリオプティマイザだけが、効率的な複数テーブル分析のための比較的最適なクエリ計画を選択できます。
|
||||
複数テーブルジョインクエリのパフォーマンスを最適化するのは難しいです。実行エンジンだけでは、実行プランの複雑さが複数テーブルジョインクエリシナリオで数桁異なる可能性があるため、優れたパフォーマンスを提供することはできません。関連するテーブルが多いほど、実行プランも多くなり、最適なプランを選択するのが NP 難しい問題になります。効率的な複数テーブル分析のためには、優れたクエリオプティマイザだけが、比較的最適なクエリプランを選択できます。
|
||||
|
||||
StarRocks は、ゼロから新しい [CBO](../using_starrocks/Cost_based_optimizer.md) を設計しました。この CBO は、カスケードのようなフレームワークを採用し、ベクトル化された実行エンジンのために深くカスタマイズされ、多くの最適化と革新を備えています。これらの最適化には、共通テーブル式 (CTE) の再利用、サブクエリの書き換え、Lateral Join、Join Reorder、分散ジョイン実行の戦略選択、低カーディナリティの最適化が含まれます。CBO は、合計 99 の TPC-DS SQL ステートメントをサポートしています。
|
||||
StarRocks は、ゼロから新しい [CBO](../using_starrocks/Cost_based_optimizer.md) を設計しました。この CBO は、カスケード型フレームワークを採用し、ベクトル化実行エンジンに深くカスタマイズされ、多くの最適化と革新を備えています。これらの最適化には、共通テーブル式（CTE）の再利用、サブクエリの書き換え、Lateral Join、Join Reorder、分散ジョイン実行の戦略選択、低カーディナリティの最適化が含まれます。CBO は、合計 99 の TPC-DS SQL ステートメントをサポートしています。
|
||||
|
||||
CBO により、StarRocks は競合他社よりも優れた複数テーブルジョインクエリパフォーマンスを提供し、特に複雑な複数テーブルジョインクエリにおいて優れています。
|
||||
CBO により、StarRocks は、特に複雑な複数テーブルジョインクエリにおいて、競合他社よりも優れた複数テーブルジョインクエリパフォーマンスを提供します。
|
||||
|
||||
## リアルタイムで更新可能な列指向ストレージエンジン
|
||||
|
||||
StarRocks は、同じタイプのデータを連続して保存できる列指向ストレージエンジンです。列指向ストレージでは、データをより効率的にエンコードでき、圧縮率を高め、ストレージコストを削減します。列指向ストレージは、総データ読み取り I/O を削減し、クエリパフォーマンスを向上させます。さらに、ほとんどの OLAP シナリオでは、特定の列のみがクエリされます。列指向ストレージにより、ユーザーは列の一部のみをクエリでき、ディスク I/O を大幅に削減します。
|
||||
StarRocks は、同じタイプのデータを連続して保存できる列指向ストレージエンジンです。列指向ストレージでは、データをより効率的にエンコードでき、圧縮率が向上し、ストレージコストが低減されます。列指向ストレージは、総データ読み取り I/O を削減し、クエリパフォーマンスを向上させます。さらに、ほとんどの OLAP シナリオでは、特定の列のみがクエリされます。列指向ストレージにより、ユーザーは特定の列のみをクエリでき、ディスク I/O を大幅に削減できます。
|
||||
|
||||
StarRocks は、ほぼリアルタイムの分析のために数秒以内にデータをロードできます。StarRocks のストレージエンジンは、各データ取り込み操作の原子性、一貫性、分離性、耐久性 (ACID) を保証します。データロードトランザクションでは、トランザクション全体が成功するか失敗するかのいずれかです。並行トランザクションは互いに影響を与えず、トランザクションレベルの分離を提供します。
|
||||
StarRocks は、ほぼリアルタイムの分析のために数秒以内にデータをロードできます。StarRocks のストレージエンジンは、各データ取り込み操作の原子性、一貫性、分離性、耐久性（ACID）を保証します。データロードトランザクションでは、トランザクション全体が成功するか失敗するかのいずれかです。同時トランザクションは互いに影響を与えず、トランザクションレベルの分離を提供します。
|
||||
|
||||
|
||||
|
||||
StarRocks のストレージエンジンは、Delete-and-insert パターンを使用しており、効率的な部分更新と Upsert 操作を可能にします。ストレージエンジンは、プライマリキーインデックスを使用してデータを迅速にフィルタリングし、データ読み取り時に Sort や Merge 操作を必要としません。このエンジンは、セカンダリインデックスもフルに活用できます。大量のデータ更新でも高速で予測可能なクエリパフォーマンスを提供します。
|
||||
StarRocks のストレージエンジンは、Delete-and-insert パターンを使用しており、効率的な部分更新と Upsert 操作を可能にします。ストレージエンジンは、プライマリキーインデックスを使用してデータを迅速にフィルタリングし、データ読み取り時にソートとマージ操作を必要としません。このエンジンは、セカンダリインデックスも最大限に活用できます。大量のデータ更新でも、迅速で予測可能なクエリパフォーマンスを提供します。
|
||||
|
||||
## インテリジェントなマテリアライズドビュー
|
||||
|
||||
StarRocks は、インテリジェントな [materialized views](../using_starrocks/async_mv/Materialized_view.md) を使用して、クエリとデータウェアハウスのレイヤリングを加速します。他の類似製品のマテリアライズドビューとは異なり、ベーステーブルとの手動データ同期が必要なところ、StarRocks のマテリアライズドビューは、ベーステーブルのデータ変更に応じて自動的にデータを更新し、追加のメンテナンス操作を必要としません。さらに、マテリアライズドビューの選択も自動です。StarRocks がクエリパフォーマンスを向上させる適切なマテリアライズドビュー (MV) を特定した場合、クエリを自動的に書き換えて MV を利用します。このインテリジェントなプロセスは、手動の介入を必要とせずにクエリ効率を大幅に向上させます。
|
||||
StarRocks は、インテリジェントな [マテリアライズドビュー](../using_starrocks/async_mv/Materialized_view.md) を使用して、クエリとデータウェアハウスのレイヤリングを加速します。他の類似製品のマテリアライズドビューとは異なり、ベーステーブルとの手動データ同期が必要な場合、StarRocks のマテリアライズドビューは、ベーステーブルのデータ変更に応じて自動的にデータを更新し、追加のメンテナンス操作を必要としません。さらに、マテリアライズドビューの選択も自動です。StarRocks がクエリパフォーマンスを向上させる適切なマテリアライズドビュー（MV）を特定した場合、クエリを自動的に書き換えて MV を利用します。このインテリジェントなプロセスは、手動の介入を必要とせずにクエリ効率を大幅に向上させます。
|
||||
|
||||
StarRocks の MV は、従来の ETL データモデリングプロセスを置き換えることができます。上流のアプリケーションでデータを変換する代わりに、StarRocks 内で MV を使用してデータを変換するオプションがあり、データ処理パイプラインを簡素化します。
|
||||
|
||||
例えば、図では、データレイク上の生データを使用して、外部 MV に基づいて正規化テーブルを作成できます。非正規化テーブルは、非同期マテリアライズドビューを通じて正規化テーブルから作成できます。別の MV は、正規化テーブルから作成され、高い同時実行クエリとより良いクエリパフォーマンスをサポートします。
|
||||
たとえば、図では、データレイク上の生データを使用して、外部 MV に基づいて正規化テーブルを作成できます。非正規化テーブルは、非同期マテリアライズドビューを通じて正規化テーブルから作成できます。別の MV は、正規化テーブルから作成され、高コンカレンシークエリとより良いクエリパフォーマンスをサポートします。
|
||||
|
||||
|
||||
|
||||
|
|
@ -74,6 +74,6 @@ StarRocks の MV は、従来の ETL データモデリングプロセスを置
|
|||
|
||||
|
||||
|
||||
ローカルデータの効率的な分析に加えて、StarRocks は [data lakes](../data_source/catalog/catalog_overview.md) に保存されたデータを分析するためのコンピュートエンジンとして機能します。Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake などが含まれます。StarRocks の重要な機能の 1 つは、外部カタログであり、外部で管理されるメタストアへのリンクとして機能します。この機能により、データ移行の必要なく、外部データソースをシームレスにクエリすることができます。このため、ユーザーは HDFS や Amazon S3 などの異なるシステムから、Parquet、ORC、CSV などのさまざまなファイル形式でデータを分析できます。
|
||||
ローカルデータの効率的な分析に加えて、StarRocks は、Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake などの [データレイク](../data_source/catalog/catalog_overview.md) に保存されたデータを分析するためのコンピュートエンジンとして機能します。StarRocks の重要な機能の 1 つは、外部カタログであり、外部で管理されているメタストアへのリンクとして機能します。この機能により、データ移行の必要なく、外部データソースをシームレスにクエリする機能をユーザーに提供します。このため、ユーザーは HDFS や Amazon S3 などの異なるシステムから、Parquet、ORC、CSV などのさまざまなファイル形式でデータを分析できます。
|
||||
|
||||
前述の図は、StarRocks がデータの計算と分析を担当し、データレイクがデータの保存、組織化、メンテナンスを担当するデータレイク分析シナリオを示しています。データレイクは、オープンストレージ形式でデータを保存し、柔軟なスキーマを使用して、さまざまな BI、AI、アドホック、レポートのユースケースに対して「単一の真実の源」に基づくレポートを生成することを可能にします。StarRocks は、そのベクトル化エンジンと CBO の利点をフルに活用し、データレイク分析のパフォーマンスを大幅に向上させます。
|
||||
上記の図は、StarRocks がデータの計算と分析を担当し、データレイクがデータの保存、組織化、メンテナンスを担当するデータレイク分析シナリオを示しています。データレイクは、ユーザーがオープンストレージ形式でデータを保存し、柔軟なスキーマを使用して、さまざまな BI、AI、アドホック、およびレポートのユースケースに対して「単一の真実の源」のレポートを作成できるようにします。StarRocks は、そのベクトル化エンジンと CBO の利点を最大限に活用し、データレイク分析のパフォーマンスを大幅に向上させます。
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
FEs: FE
|
||||
BEs: BE
|
||||
distributed architecture: &da 分散アーキテクチャ
|
||||
distributed-architecture: *da
|
||||
Data loading: データロード
|
||||
Data unloading: データアンロード
|
||||
load: ロード
|
||||
|
|
@ -17,7 +19,11 @@ shared-data cluster: 共有データクラスタ
|
|||
shared-nothing cluster: 共有なしクラスタ
|
||||
zero-migration: ゼロマイグレーション
|
||||
native vectorized engine: ネイティブベクトル化エンジン
|
||||
vectorized query engine: ベクトル化クエリエンジン
|
||||
query federation/federated query: フェデレーションクエリ
|
||||
query plan: &qp クエリプラン
|
||||
query planning: *qp
|
||||
query analysis: *qp
|
||||
columnar storage: 列指向（カラムナ）ストレージ
|
||||
row storage: 行指向（ロウ）ストレージ
|
||||
intelligent materialized view: インテリジェントなマテリアライズドビュー
|
||||
|
|
@ -27,6 +33,8 @@ synchronous materialized view: 同期マテリアライズドビュー
|
|||
asynchronous materialized view: 非同期マテリアライズドビュー
|
||||
unified batch and streaming, batch-stream integrated: バッチストリーム統合
|
||||
high availability: 高可用性
|
||||
high concurrency: &hc 高い同時実行性
|
||||
high-concurrency: *hc
|
||||
high scalability: 高拡張性
|
||||
data ingestion: データ取り込み
|
||||
denormalized table/flat table: 非正規化テーブル
|
||||
|
|
@ -61,6 +69,9 @@ approximate distinct count: 近似重複排除カウント
|
|||
table schema: テーブルスキーマ
|
||||
sort key: ソートキー
|
||||
bucketing key: バケッティングキー
|
||||
List Partitioning: リストパーティション化
|
||||
secondary partitioning: セカンダリパーティション
|
||||
Range Partitioning: レンジパーティション化
|
||||
partitioning column: パーティション列
|
||||
partition key: パーティションキー
|
||||
random bucketing: ランダムバケット法
|
||||
|
|
@ -69,6 +80,7 @@ automatic partitioning: 自動パーティション化
|
|||
dynamic partitioning: 動的パーティション化
|
||||
expression partitioning: 式に基づくパーティション化
|
||||
list partitioning: リストパーティション化
|
||||
partition division: パーティション分割
|
||||
replica: レプリカ
|
||||
user profiling: ユーザープロファイリング
|
||||
user retention: ユーザーリテンション
|
||||
|
|
@ -85,7 +97,6 @@ approximation algorithm: 近似アルゴリズム
|
|||
nested query: ネストクエリ
|
||||
memory leak: メモリリーク
|
||||
memory bloat: メモリ肥大化
|
||||
secondary partitioning: セカンダリパーティション
|
||||
pruning: プルーニング
|
||||
partition file: パーティションファイル
|
||||
abstract syntax tree: 抽象構文ツリー
|
||||
|
|
@ -133,8 +144,6 @@ async refresh: 非同期リフレッシュ
|
|||
query acceleration: クエリアクセラレーション
|
||||
segment file: セグメントファイル
|
||||
Hybrid row-column storage: 行と列のハイブリッドストレージ
|
||||
List Partitioning: リストパーティション化
|
||||
Range Partitioning: レンジパーティション化
|
||||
Bitmap index: ビットマップインデックス
|
||||
Bloom filter index: ブルームフィルターインデックス
|
||||
shared-data: 共有データ
|
||||
|
|
|
|||
Loading…
Reference in New Issue