Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions basic-features.md
Original file line number Diff line number Diff line change
Expand Up @@ -185,18 +185,18 @@ summary: TiDBの機能概要について学びましょう。

| パーティショニング | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 |
| ------------------------------------------------------------------------------------------------------------ | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
| [範囲分割](/partitioned-table.md#range-partitioning) | Y | Y | Y | Y | Y | Y | Y |
| [レンジパーティショニング](/partitioned-table.md#range-partitioning) | Y | Y | Y | Y | Y | Y | Y |
| [ハッシュパーティショニング](/partitioned-table.md#hash-partitioning) | Y | Y | Y | Y | Y | Y | Y |
| [キーパーティショニング](/partitioned-table.md#key-partitioning) | Y | Y | Y | Y | N | N | N |
| [List パーティショニング](/partitioned-table.md#list-partitioning) | Y | Y | Y | Y | Y | Y | E |
| [List COLUMNS パーティショニング](/partitioned-table.md) | Y | Y | Y | Y | Y | Y | E |
| [リストおよびリスト列パーティションテーブルのデフォルトパーティション](/partitioned-table.md#default-list-partition) | Y | Y | Y | N | N | N | N |
| [リストパーティショニング](/partitioned-table.md#list-partitioning) | Y | Y | Y | Y | Y | Y | E |
| [リストCOLUMNSパーティショニング](/partitioned-table.md) | Y | Y | Y | Y | Y | Y | E |
| [リストおよびリストCOLUMNSパーティションテーブルのデフォルトパーティション](/partitioned-table.md#default-list-partition) | Y | Y | Y | N | N | N | N |
| [`EXCHANGE PARTITION`](/partitioned-table.md) | Y | Y | Y | Y | Y | E | E |
| [`REORGANIZE PARTITION`](/partitioned-table.md#reorganize-partitions) | Y | Y | Y | Y | N | N | N |
| [`COALESCE PARTITION`](/partitioned-table.md#decrease-the-number-of-partitions) | Y | Y | Y | Y | N | N | N |
| [動的剪定](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E |
| [範囲列パーティショニング](/partitioned-table.md#range-columns-partitioning) | Y | Y | Y | Y | Y | N | N |
| [範囲 INTERVAL 分割](/partitioned-table.md#range-interval-partitioning) | Y | Y | Y | Y | E | N | N |
| [動的プルーニング](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E |
| [レンジCOLUMNSパーティショニング](/partitioned-table.md#range-columns-partitioning) | Y | Y | Y | Y | Y | N | N |
| [レンジ INTERVAL パーティショニング](/partitioned-table.md#range-interval-partitioning) | Y | Y | Y | Y | E | N | N |
| [パーティションテーブルを非パーティションテーブルに変換する](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table) | Y | Y | Y | N | N | N | N |
| [既存のテーブルをパーティション分割する](/partitioned-table.md#partition-an-existing-table) | Y | Y | Y | N | N | N | N |
| [グローバルインデックス](/global-indexes.md) | Y | N | N | N | N | N | N |
Expand All @@ -214,7 +214,7 @@ summary: TiDBの機能概要について学びましょう。
| [拡張統計](/extended-statistics.md) | E | E | E | E | E | E | E |
| 統計フィードバック | N | N | N | N | N | 非推奨 | 非推奨 |
| [統計情報を自動的に更新する](/statistics.md#automatic-update) | Y | Y | Y | Y | Y | Y | Y |
| [動的剪定](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E |
| [動的プルーニング](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E |
| [`PREDICATE COLUMNS`の統計情報を収集する](/statistics.md#collect-statistics-on-some-columns) | Y | E | E | E | E | E | E |
| [統計情報を収集するためのメモリ割り当て量を制御する](/statistics.md#the-memory-quota-for-collecting-statistics) | E | E | E | E | E | E | N |
| [約10000行のデータをランダムにサンプリングして、統計情報を素早く構築します](/system-variables.md#tidb_enable_fast_analyze) | 非推奨 | 非推奨 | 非推奨 | E | E | E | E |
Expand Down
16 changes: 8 additions & 8 deletions best-practices/tidb-partitioned-tables-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/tidb-partitioned-tables-best-practices/','/ja/tidb/de

TiDBのパーティションテーブルは、大規模データセットの管理、クエリ効率の向上、一括データ削除の容易化、書き込みホットスポット問題の緩和など、多用途なアプローチを提供します。データを論理セグメントに分割することで、TiDBはパーティションプルーニングを活用し、クエリ実行時に不要なデータをスキップします。これにより、リソース消費が削減され、特に大規模データセットを扱うオンライン分析処理(OLAP)ワークロードにおいてパフォーマンスが向上します。

一般的なユースケースとしては、 [範囲分割](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)を使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。
一般的なユースケースとしては、 [レンジパーティショニング](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)を使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。

もう1つのシナリオは、ハッシュまたはキーパーティショニングを使用して書き込みホットスポットの問題に対処することです。特に、 [`AUTO_INCREMENT`](/auto-increment.md) IDを使用するワークロードでは、シーケンシャルな挿入によって特定のTiKVリージョンに過負荷がかかる可能性があります。書き込みをパーティションに分散させることでワークロードのバランスを取ることができますが、レンジパーティショニングと同様に、パーティションプルーニング条件のないクエリではパフォーマンスが低下する可能性があります。このような状況では、グローバルインデックスが役立ちます。

Expand Down Expand Up @@ -59,7 +59,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル

テストでは次の構成を使用します。

- パーティションテーブルには、 `date`列で定義された 365 個の範囲パーティションが含まれています
- パーティションテーブルには、 `date`列で定義された 365 個のレンジパーティションが含まれています
- ワークロードは、各インデックスキーが複数の行と一致する大量の OLTP クエリパターンをシミュレートします。
- このテストでは、さまざまなパーティション数も評価し、パーティションの粒度がクエリのレイテンシーとインデックスの効率にどのように影響するかを測定します。

Expand Down Expand Up @@ -112,7 +112,7 @@ WHERE `fa`.`sid` IN (

#### テスト結果 {#test-results}

次の表は、365 個の範囲パーティションを持つテーブルから 400 行を返すクエリの結果を示しています。
次の表は、365 個のレンジパーティションを持つテーブルから 400 行を返すクエリの結果を示しています。

| コンフィグレーション | 平均クエリ時間 | COP タスク(インデックススキャン) | COP タスク(テーブル検索) | COP タスクの合計 |
| ------------------------- | ------- | ------------------ | ------------- | -------- |
Expand Down Expand Up @@ -284,7 +284,7 @@ TTL=`expire_time` + INTERVAL 0 DAY TTL_ENABLE='ON'
TTL_JOB_INTERVAL='10m';
```

次の例は、Range INTERVAL パーティション化を使用するパーティションテーブルを示しています
次の例は、レンジ INTERVAL パーティショニングを使用するパーティションテーブルを示しています

```sql
CREATE TABLE `ad_cache` (
Expand Down Expand Up @@ -440,7 +440,7 @@ PARTITION BY KEY (id) PARTITIONS 16;

### ホットスポットを読む {#read-hotspots}

範囲パーティション化されたテーブルでは、クエリがパーティションキーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。
レンジパーティション化されたテーブルでは、クエリがパーティションキーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。

**根本的な原因:**

Expand Down Expand Up @@ -491,7 +491,7 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの

#### ベストプラクティス {#best-practices}

新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、次の手順に従います。
新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、次の手順に従います。

##### ステップ1. `SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`を使用する {#step-1-use-shard-row-id-bits-and-pre-split-regions}

Expand Down Expand Up @@ -599,13 +599,13 @@ SHOW TABLE employees PARTITION (p4) regions;

#### ベストプラクティス {#best-practices}

新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。
新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。

### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables}

#### 利点 {#advantages}

- 新しい範囲パーティションによるホットスポットのリスクはありません
- 新しいレンジパーティションによるホットスポットのリスクはありません
- ポイントおよび範囲クエリの読み取りパフォーマンスが良好です。

#### デメリット {#disadvantages}
Expand Down
8 changes: 4 additions & 4 deletions global-indexes.md
Original file line number Diff line number Diff line change
Expand Up @@ -301,20 +301,20 @@ FROM sbtest
WHERE k IN (xx, xx, xx)
```

範囲パーティション(100 パーティション):
レンジパーティション(100 パーティション):

| テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU |
| ----------------------------------------------- | ----- | -------- | -------- | ------ |
| クラスター化された非パーティションテーブル | 225 | 19,999 | 30,293 | 7.92 |
| PK でパーティション化されたクラスター化テーブル範囲 | 68 | 480 | 511 | 114.87 |
| PK によって範囲分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 207 | 17,798 | 27,707 | 11.73 |
| PK によってレンジ分割されたクラスター化テーブル | 68 | 480 | 511 | 114.87 |
| PK によってレンジ分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 207 | 17,798 | 27,707 | 11.73 |

ハッシュパーティション(100パーティション):

| テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU |
| ------------------------------------------- | ----- | -------- | -------- | ------ |
| クラスター化された非パーティションテーブル | 166 | 20,361 | 28,922 | 7.86 |
| PK で分割されたクラスター化テーブルハッシュ | 60 | 244 | 283 | 119.73 |
| PK によってハッシュ分割されたクラスター化テーブル | 60 | 244 | 283 | 119.73 |
| PKでハッシュ分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 156 | 18,233 | 15,581 | 10.77 |

前述のテストでは、高同時実行環境において、グローバルインデックスによってパーティションテーブルのクエリパフォーマンスが大幅に向上し、最大50倍のパフォーマンス向上が実現できることが実証されています。さらに、グローバルインデックスはリクエストユニット(RU)の消費量を大幅に削減します。パーティション数が増えるにつれて、パフォーマンスのメリットはさらに顕著になります。
2 changes: 1 addition & 1 deletion mysql-compatibility.md
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ TiDBでは、サポートされているすべてのDDL変更をオンライン
- `CLUSTERED`タイプの主キーの追加/削除はサポートされていません。 `CLUSTERED`タイプの主キーの詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。
- 異なるタイプのインデックス( `HASH|BTREE|RTREE|FULLTEXT` )はサポートされておらず、指定されても解析されて無視されます。
- TiDB は`HASH` 、 `RANGE` 、 `LIST` 、および`KEY`パーティションタイプをサポートしています。サポートされていないパーティションタイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`を返します。ここで、 `%s`はサポートされていない特定のパーティションタイプです。
- Range、Range COLUMNS、List、およびList COLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。
- レンジ、レンジCOLUMNS、リスト、およびリストCOLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。
- ハッシュおよびキーパーティションテーブルは`ADD` 、 `COALESCE` 、および`TRUNCATE`操作をサポートします。その他のパーティション操作は無視されます。
- パーティションテーブルでは、以下の構文はサポートされていません。

Expand Down
Loading
Loading