diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index e3c0ea4c46e4a..b8653cf468744 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -12,9 +12,9 @@ aliases: ['/ja/tidb/stable/best-practices-on-public-cloud/'] ## KV RocksDB の圧縮 I/O フローを削減 {#reduce-compaction-i-o-flow-in-kv-rocksdb} -TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/) 、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。 +TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/)は、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。 -ディスクスループットの制限によるボトルネックを軽減するには、パフォーマンスを[Titanを有効にする](#enable-titan)向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、パフォーマンスを[すべての圧縮レベルを上げる](#increase-all-the-compression-levels)向上させることができます。 +ディスクスループットの制限によるボトルネックを軽減するには、 [Titanを有効にする](#enable-titan)ことでパフォーマンスを向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、 [すべての圧縮レベルを上げる](#increase-all-the-compression-levels)ことでパフォーマンスを向上させることができます。 ### Titanを有効にする {#enable-titan} @@ -45,7 +45,7 @@ compression-per-level = ["zstd", "zstd", "zstd", "zstd", "zstd", "zstd", "zstd"] ## Raft Engine専用のディスクを使用する {#use-a-dedicated-disk-for-raft-engine} -TiKVの[Raft Engine](/glossary.md#raft-engine) 、従来のデータベースにおける先行書き込みログ（WAL）と同様の重要な役割を果たします。最適なパフォーマンスと安定性を実現するには、パブリッククラウドにTiDBをデプロイする際に、 Raft Engine専用のディスクを割り当てることが不可欠です。次の`iostat` 、書き込み負荷の高いワークロードにおけるTiKVノードのI/O特性を示しています。 +TiKVの[Raft Engine](/glossary.md#raft-engine)は、従来のデータベースにおける先行書き込みログ（WAL）と同様の重要な役割を果たします。最適なパフォーマンスと安定性を実現するには、パブリッククラウドにTiDBをデプロイする際に、 Raft Engine専用のディスクを割り当てることが不可欠です。次の`iostat`は、書き込み負荷の高いワークロードにおけるTiKVノードのI/O特性を示しています。 ``` Device r/s rkB/s w/s wkB/s f/s aqu-sz %util @@ -53,7 +53,7 @@ sdb 1649.00 209030.67 1293.33 304644.00 13.33 5.09 48.37 sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 ``` -デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 +デバイス`sdb`はKV RocksDBに使用され、 `sdd`はRaft Engineのログを復元するために使用されます。 `sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`を呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 クラウドプロバイダーによって、IOPSやMBPSなどのパフォーマンス特性が異なる様々なディスクタイプが提供されています。そのため、ワークロードに応じて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。 @@ -65,11 +65,11 @@ sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 さまざまなパブリッククラウドに推奨されるミドルレンジ ディスクは次のとおりです。 -- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。 +- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)が推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。 -- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。 +- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。 -- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。 +- Azureでは[Premium SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)が推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。 #### ハイエンドディスク {#high-end-disk} @@ -77,7 +77,7 @@ Raft Engineのレイテンシーをさらに低減したい場合は、ハイエ - AWSでは[io2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)が推奨されます。ディスクサイズとIOPSは、お客様の特定の要件に応じてプロビジョニングできます。 -- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。 +- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。 - Azure では[Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)が推奨されます。ディスクサイズ、IOPS、MBPS は、お客様の特定の要件に応じてプロビジョニングできます。 @@ -88,7 +88,7 @@ AWS は、20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/)ボリュー 書き込み集中型のソーシャル ネットワーク アプリケーション ワークロードに AWS 上の専用の 20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/) Raft Engineディスクを使用すると、次のような改善が見られますが、推定コストはわずか 0.4% しか増加しません。 - QPS（1秒あたりのクエリ数）が17.5%増加 -- 挿入文の平均レイテンシーが18.7%減少 +- 挿入ステートメントの平均レイテンシーが18.7%減少 - 挿入ステートメントの p99レイテンシーが 45.6% 減少しました。 | メトリック | 共有Raft Engineディスク | 専用Raft Engineディスク | 違い （％） | @@ -143,9 +143,9 @@ TiFlash MPPタスクのデータシャッフルによって発生するネット Google Cloud の[ライブマイグレーション機能](https://cloud.google.com/compute/docs/instances/live-migration-process)は、ダウンタイムを発生させることなく、ホスト間でVMをシームレスに移行できます。しかし、これらの移行イベントは頻度は低いものの、TiDBクラスタで実行されているVMを含むVMのパフォーマンスに重大な影響を与える可能性があります。このようなイベントが発生すると、影響を受けるVMのパフォーマンスが低下し、TiDBクラスタでのクエリ処理時間が長くなる可能性があります。 -Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[スクリプトを見る](https://github.com/PingCAP-QE/tidb-google-maintenance)提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。 +Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[監視スクリプト](https://github.com/PingCAP-QE/tidb-google-maintenance)を提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。 -- TiDB: TiDBノードをオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、切断されたノードは自動スケーラーによって回収されることが想定されます。 +- TiDB: TiDBノードをcordonしてオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、cordonされたノードは自動スケーラーによって回収されることが想定されます。 - TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。 - PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index a5b96a21865dd..ce90dcc03637a 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -67,7 +67,7 @@ DDL変更は、ある状態から別の状態への遷移を伴い、通常は このように、複数の小さなバージョンを経ることで、複数のTiDBノード間でメタデータが正しく同期されます。これにより、プロセス中にデータの変更を伴うユーザートランザクションの正確性と一貫性が維持されます。 -`ADD INDEX`例にとると、状態変化の全体プロセスは次のようになります。 +`ADD INDEX`を例にとると、状態変化の全体プロセスは次のようになります。 ``` absent -> delete only -> write only -> write reorg -> public @@ -87,7 +87,7 @@ DDL実行のユーザーエクスペリエンスを向上させるため、TiDB - 同じテーブルに対して実行される DDL文は相互にブロックされます。 - `DROP DATABASE`と、データベース内のすべてのオブジェクトに影響する DDL文は相互にブロックされます。 - 異なるテーブルでのインデックスの追加と列タイプの変更を同時に実行できます。 -- v8.2.0 以降では、異なるテーブルに対して[論理DDL文](/best-practices/ddl-introduction.md#types-of-ddl-statements)並列実行できます。 +- v8.2.0 以降では、異なるテーブルに対して[論理DDL文](/best-practices/ddl-introduction.md#types-of-ddl-statements)を並列実行できます。 - それ以外の場合、同時 DDL 実行の可用性レベルに基づいて DDL を実行できます。 具体的には、TiDB 6.2.0 では、次の点で DDL 実行フレームワークが強化されました。 diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index 7d827cc68a111..01031623af787 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -6,7 +6,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc # Grafana を使用した TiDB 監視のベストプラクティス {#best-practices-for-monitoring-tidb-using-grafana} -トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。 +トポロジ構成にGrafanaとPrometheusを追加し、[TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)と、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。 ## 監視アーキテクチャ {#monitoring-architecture} diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 46b5158940f77..2ba137bdc0149 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -18,13 +18,13 @@ aliases: ['/ja/docs/dev/best-practices/haproxy-best-practices/','/ja/docs/dev/re HAProxyは、C言語で書かれた無料のオープンソースソフトウェアで、TCPおよびHTTPベースのアプリケーション向けの高可用性ロードバランサおよびプロキシサーバーを提供します。CPUとメモリを高速かつ効率的に使用できるため、GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter、Tuenti、AWS（Amazon Web Services）など、多くの著名なウェブサイトで広く利用されています。 -HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)を使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)ご覧ください。 +HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)を使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)をご覧ください。 ## 基本機能 {#basic-features} - [高可用性](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.4) : HAProxy は、正常なシャットダウンとシームレスな切り替えをサポートする高可用性を提供します。 - [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9種類以上の負荷分散アルゴリズムがサポートされています。 -- [健康チェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。 +- [ヘルスチェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。 - [スティッキーセッション](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.6) : アプリケーションがスティッキーセッションをサポートしていない間、HAProxy はクライアントを特定のサーバーに固定することができます。 - [SSL](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.2) : HTTPS 通信と解決がサポートされます。 - [監視と統計](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.3) ：Web ページを通じて、サービスの状態とトラフィック フローをリアルタイムで監視できます。 @@ -63,7 +63,7 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの #### 依存関係 {#dependencies} -- エペルリリース +- epel-release - gcc - systemd-devel @@ -75,7 +75,7 @@ yum -y install epel-release gcc systemd-devel ## HAProxyをデプロイ {#deploy-haproxy} -HAProxyを使用すると、負荷分散されたデータベース環境を簡単に構成・セットアップできます。このセクションでは、一般的なデプロイメント操作について説明します。実際のシナリオに合わせて[設定ファイル](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html)カスタマイズできます。 +HAProxyを使用すると、負荷分散されたデータベース環境を簡単に構成・セットアップできます。このセクションでは、一般的なデプロイメント操作について説明します。実際のシナリオに合わせて[設定ファイル](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html)をカスタマイズできます。 ### HAProxyをインストールする {#install-haproxy} diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 1e6c4dfe0c91b..6c69488d67b5e 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- ## 対象読者 {#target-audience} -このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)読みいただくことをお勧めします。 +このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)をお読みいただくことをお勧めします。 - [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) - [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) @@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- 上記の課題に対処するには、TiDBのデータセグメンテーションとスケジューリングの原理から始める必要があります。詳細については[スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/)を参照してください。 -TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。RaftRaftでは、リージョンLeaderがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)サポート）を実行します。リージョンLeaderは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。 +TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンリーダーがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポートしています）を実行します。リージョンリーダーは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。 ![TiDB Data Overview](/media/best-practices/tidb-data-overview.png) @@ -98,7 +98,7 @@ FROM ![QPS3](/media/best-practices/QPS3.png) -[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。 +[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのリーダー、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。 PD の監視メトリックでも、ホットスポットが発生したことが確認されます。 @@ -116,7 +116,7 @@ PD の監視メトリックでも、ホットスポットが発生したこと ![TiKV Region Split](/media/best-practices/tikv-Region-split.png) -上の図は、リージョン分割プロセスを示しています。データがTiKVに継続的に書き込まれると、TiKVはリージョンを複数のリージョンに分割します。リーダー選出は、分割対象のリージョンLeaderが配置されている元のストアで開始されるため、新しく分割された2つのリージョンのリーダーは同じストアに残っている可能性があります。この分割プロセスは、新しく分割されたリージョン2とリージョン3でも発生する可能性があります。このように、書き込み負荷はTiKVノード1に集中します。 +上の図は、リージョン分割プロセスを示しています。データがTiKVに継続的に書き込まれると、TiKVはリージョンを複数のリージョンに分割します。リーダー選出は、分割対象のリージョンリーダーが配置されている元のストアで開始されるため、新しく分割された2つのリージョンのリーダーは同じストアに残っている可能性があります。この分割プロセスは、新しく分割されたリージョン2とリージョン3でも発生する可能性があります。このように、書き込み負荷はTiKVノード1に集中します。 継続的な書き込みプロセス中、ノード1でホットスポットが発生していることを検出すると、PDは集中しているリーダーノードを他のノードに均等に分散させます。TiKVノードの数がリージョンレプリカの数よりも多い場合、TiKVはこれらのリージョンをアイドルノードに移行しようとします。書き込みプロセス中のこれらの2つの操作は、PDの監視メトリクスにも反映されます。 @@ -152,7 +152,7 @@ TiDBは汎用的な用途向けのデータベースであり、データ分布 このような状況とホットスポット問題を回避する必要性を踏まえ、TiDBは`Split Region`構文を使用して、同時書き込みが集中するシナリオでパフォーマンスを最適化します。上記のケースに基づいて、 `Split Region`構文を使用してリージョンを分散させ、負荷分散を観察してみましょう。 -テストで書き込まれるデータは正の範囲内で完全に離散的であるため、次のステートメントを使用して、テーブルを`minInt64`から`maxInt64`範囲内の 128 個の領域に事前に分割できます。 +テストで書き込まれるデータは正の範囲内で完全に離散的であるため、次のステートメントを使用して、テーブルを`minInt64`から`maxInt64`の範囲内の 128 個の領域に事前に分割できます。 ```sql SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128; diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index 8b2cb5b655a0c..6e5a83ed5bd4c 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -95,22 +95,22 @@ DESC TIDB_INDEX_USAGE; - 未使用のインデックス: - `QUERY_TOTAL = 0`の場合、インデックスはどのクエリでも使用されていません。 - - `LAST_ACCESS_TIME`かなり前のものを示している場合、インデックスはもはや関連がない可能性があります。 + - `LAST_ACCESS_TIME`がかなり前のものを示している場合、インデックスはもはや関連がない可能性があります。 - 非効率的なインデックス: - - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックススキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 + - `PERCENTAGE_ACCESS_100`の値が大きい場合は完全なインデックススキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`を比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 `TIDB_INDEX_USAGE`システムテーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。 -### `TIDB_INDEX_USAGE`効果的に使用する {#use-tidb-index-usage-effectively} +### `TIDB_INDEX_USAGE`を効果的に使用する {#use-tidb-index-usage-effectively} 次の点は、 `TIDB_INDEX_USAGE`システムテーブルを正しく理解して使用するのに役立ちます。 #### データの更新が遅れている {#data-updates-are-delayed} -パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 +パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`は即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 #### インデックス使用状況データは保存されません {#index-usage-data-is-not-persisted} @@ -151,13 +151,13 @@ ORDER BY total_queries DESC; | インデックス追跡 | データは各データベースインスタンスに対してローカルです。 | クラスター全体の集中ビューを提供します。 | | 主な使用例 | データベースインスタンスレベルでインデックスの使用状況をデバッグします。 | グローバルインデックスパターンとマルチノードの動作を分析します。 | -### `CLUSTER_TIDB_INDEX_USAGE`効果的に使用する {#use-cluster-tidb-index-usage-effectively} +### `CLUSTER_TIDB_INDEX_USAGE`を効果的に使用する {#use-cluster-tidb-index-usage-effectively} `CLUSTER_TIDB_INDEX_USAGE`システムテーブルは複数のノードからのデータを統合するため、次の点に注意してください。 - データ更新の遅延 - パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 + パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`は即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 - メモリベースのストレージ @@ -167,7 +167,7 @@ ORDER BY total_queries DESC; ## `schema_unused_indexes`を使用して未使用のインデックスを識別する {#identify-unused-indexes-using-schema-unused-indexes} -インデックス使用状況データを手動で分析するのは時間がかかります。このプロセスを簡素化するために、TiDBは[`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)提供しています。これは、データベースの最後の再起動以降に使用されていないインデックスを一覧表示するシステムビューです。 +インデックス使用状況データを手動で分析するのは時間がかかります。このプロセスを簡素化するために、TiDBは[`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)を提供しています。これは、データベースの最後の再起動以降に使用されていないインデックスを一覧表示するシステムビューです。 これにより、次の操作を簡単に実行できるようになります。 @@ -177,9 +177,9 @@ ORDER BY total_queries DESC; `schema_unused_indexes`を使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。 -### `schema_unused_indexes`仕組み {#how-schema-unused-indexes-works} +### `schema_unused_indexes`の仕組み {#how-schema-unused-indexes-works} -`schema_unused_indexes`ビューは`TIDB_INDEX_USAGE`から派生しており、最後の TiDB 再起動以降にクエリ アクティビティが 0 個記録されたインデックスを自動的に除外することを意味します。 +`schema_unused_indexes`ビューは`TIDB_INDEX_USAGE`から派生しており、最後の TiDB 再起動以降にクエリアクティビティが 0 回記録されたインデックスを自動的に抽出することを意味します。 未使用のインデックスのリストを取得するには、次の SQL文を実行します。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index d01e0e557a4d1..2dc2f3a483431 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -12,7 +12,7 @@ TiDBでは、データはリージョンに分割され、各リージョンに ## Raftstoreワークフロー {#raftstore-workflow} -TiKVインスタンスには複数のリージョンが存在します。RaftstoreRaftstoreはRaftステートマシンを駆動し、リージョンメッセージを処理します。これらのメッセージには、リージョンに対する読み取りまたは書き込みリクエストの処理、 Raftログの永続化または複製、 Raftハートビートの処理が含まれます。ただし、リージョン数の増加はクラスター全体のパフォーマンスに影響を与える可能性があります。これを理解するには、以下に示すRaftstoreのワークフローを理解する必要があります。 +TiKVインスタンスには複数のリージョンが存在します。RaftstoreはRaftステートマシンを駆動し、リージョンメッセージを処理します。これらのメッセージには、リージョンに対する読み取りまたは書き込みリクエストの処理、 Raftログの永続化または複製、 Raftハートビートの処理が含まれます。ただし、リージョン数の増加はクラスター全体のパフォーマンスに影響を与える可能性があります。これを理解するには、以下に示すRaftstoreのワークフローを理解する必要があります。 ![Raftstore Workflow](/media/best-practices/raft-process.png) @@ -26,7 +26,7 @@ TiKVインスタンスには複数のリージョンが存在します。Raftsto Raftstore のワークフロー図から、各リージョンのメッセージは1つずつ処理されます。リージョンの数が多い場合、 Raftstore は各リージョンのハートビートを処理するのに時間がかかり、遅延が発生する可能性があります。その結果、一部の読み取りおよび書き込みリクエストが時間内に処理されない場合があります。読み取りおよび書き込みの負荷が高い場合、 Raftstoreスレッドの CPU 使用率がボトルネックになりやすく、遅延がさらに増加してパフォーマンスに影響を及ぼします。 -一般的に、ロードされたRaftstoreのCPU使用率が85%以上に達すると、 Raftstoreはビジー状態になり、ボトルネックとなります。同時に、 `propose wait duration`数百ミリ秒に達することもあります。 +一般的に、ロードされたRaftstoreのCPU使用率が85%以上に達すると、 Raftstoreはビジー状態になり、ボトルネックとなります。同時に、 `propose wait duration`が数百ミリ秒に達することもあります。 > **Note:** > @@ -74,13 +74,13 @@ Grafana の**TiKV-Details**ダッシュボードでは、次の監視メトリ Raftstore はTiDB v3.0 以降、マルチスレッド モジュールにアップグレードされており、 Raftstoreスレッドがボトルネックになる可能性が大幅に減少しています。 -TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定されています。Raftstoreでボトルネックが発生する場合は、実際の状況に応じてこの設定項目の値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドを回避するため、この値を高くしすぎないことをお勧めします。 +TiKVでは、デフォルトで`raftstore.store-pool-size`は`2`に設定されています。Raftstoreでボトルネックが発生する場合は、実際の状況に応じてこの設定項目の値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドを回避するため、この値を高くしすぎないことをお勧めします。 -### 方法2: 休止状態リージョンを有効にする {#method-2-enable-hibernate-region} +### 方法2: Hibernateリージョンを有効にする {#method-2-enable-hibernate-region} 実際の状況では、読み取りおよび書き込みリクエストはすべてのリージョンに均等に分散されるわけではなく、一部のリージョンに集中します。そのため、一時的にアイドル状態のリージョンにおけるRaftリーダーとフォロワー間のメッセージ数を最小限に抑えることができます。これはHibernate リージョンの機能です。この機能により、 Raftstoreはアイドル状態のリージョンのRaftステートマシンに、必要がない限りティックメッセージを送信しません。そのため、これらのRaftステートマシンはハートビートメッセージを生成するためにトリガーされることがなくなり、 Raftstoreのワークロードを大幅に軽減できます。 -[TiKVマスター](https://github.com/tikv/tikv/tree/master)では、Hibernate リージョン がデフォルトで有効になっています。この機能は必要に応じて設定できます。詳細は[Hibernateリージョンを構成する](/tikv-configuration-file.md)を参照してください。 +[TiKVのmasterブランチ](https://github.com/tikv/tikv/tree/master)では、Hibernate リージョン がデフォルトで有効になっています。この機能は必要に応じて設定できます。詳細は[Hibernateリージョンを構成する](/tikv-configuration-file.md)を参照してください。 ### 方法3: `Region Merge`を有効にする {#method-3-enable-region-merge} @@ -119,7 +119,7 @@ I/O リソースと CPU リソースが十分な場合は、単一のマシン raft-base-tick-interval = "2s" ``` -上記の設定では、 `raft-base-tick-interval` Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンに tick メッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。 +上記の設定では、 `raft-base-tick-interval`は、Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンにティックメッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。 ティックメッセージ間のこの間隔は、 `election timeout`と`heartbeat`の間の間隔も決定することに注意してください。次の例をご覧ください。 @@ -132,7 +132,7 @@ raft-heartbeat-interval = raft-base-tick-interval * raft-heartbeat-ticks ### 方法6:リージョンのサイズを調整する {#method-6-adjust-region-size} -リージョンのデフォルトサイズは256MiBです。リージョンのサイズを大きくすることで、リージョンの数を減らすことができます。詳細については、 [リージョンパフォーマンスの調整](/tune-region-performance.md)ご覧ください。 +リージョンのデフォルトサイズは256MiBです。リージョンのサイズを大きくすることで、リージョンの数を減らすことができます。詳細については、 [リージョンパフォーマンスの調整](/tune-region-performance.md)をご覧ください。 > **Note:** > @@ -154,11 +154,11 @@ TiKVノード間のRaft通信に使用される最大接続数を調整するに このセクションでは、その他の問題と解決策について説明します。 -### PD Leaderの切り替えが遅い {#switching-pd-leader-is-slow} +### PDリーダーの切り替えが遅い {#switching-pd-leader-is-slow} -PDは、PD Leaderノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがLeaderを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。 +PDは、PDリーダーノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがリーダーを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。 -この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。 +この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`が有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。 ### PDルーティング情報が時間内に更新されない {#pd-routing-information-is-not-updated-in-time} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 33595a83ea44f..0e681ffa56733 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -123,7 +123,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ![Table Access Path Selection](/media/best-practices/multi-column-index-table-access-path-selection.png) -複数列のフィルターは、前述の基本的な例よりも複雑になることがよくあります。AND条件、 **OR**条件、あるいはその両方の組み合わせが含まれる場合があります。TiDBの範囲導出サブシステムは、これらのケース**を**効率的に処理し、最も選択性の高い（したがって最も効果的な）インデックス範囲を生成するように設計されています。 +複数列のフィルターは、前述の基本的な例よりも複雑になることがよくあります。 **AND**条件、 **OR**条件、あるいはその両方の組み合わせが含まれる場合があります。TiDBの範囲導出サブシステムは、これらのケースを効率的に処理し、最も選択性の高い（したがって最も効果的な）インデックス範囲を生成するように設計されています。 一般的に、サブシステムは**OR**条件から生成された範囲には**UNION**演算を適用し、 **AND**条件から生成された範囲には**INTERSECT**演算を適用します。このアプローチにより、TiDBは複雑なフィルタリングロジックであっても、可能な限り正確にデータをフィルタリングできます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 3c019f091da91..7d05b8d302408 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -42,10 +42,10 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ さまざまなスケジューラが、次の点を考慮して、独自のロジックと要件に基づいてオペレーターを生成します。 - - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しないでください。 + - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しない - 異常な状態のリージョンのバランスをとらない - - リーダーを保留中のピアに転送しないでください - - リーダーを直接削除しないでください + - リーダーを保留中のピアに転送しない + - リーダーを直接削除しない - さまざまなリージョンピアの物理的な分離を破壊しない - ラベルプロパティなどの制約に違反しない @@ -84,13 +84,13 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 2. 負荷分散と同様の方法でこれらのリージョンを再分配します。 -ホット書き込みリージョンの場合、 `hot-region-scheduler`リージョンピアとリーダーの両方の再配布を試行します。ホット読み取りリージョンの場合、 `hot-region-scheduler`リージョンリーダーのみを再配布します。 +ホット書き込みリージョンの場合、 `hot-region-scheduler`はリージョンピアとリーダーの両方の再配布を試行します。ホット読み取りリージョンの場合、 `hot-region-scheduler`はリージョンリーダーのみを再配布します。 ### クラスタトポロジの認識 {#cluster-topology-awareness} クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。 -リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 +リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ) 異なるラックに、ラックが不十分な場合は異なるホストにスケジュールしようとします。 ### スケールインと障害回復 {#scale-in-and-failure-recovery} @@ -206,7 +206,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - 負荷の不均衡を引き起こすホットリージョンがあります。この場合、 [ホットリージョンのスケジュール](#hot-regions-are-not-evenly-distributed)に基づいてさらに分析する必要があります。 - 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [リージョンの統合](#region-merge-is-slow)スケジューリングが適しています。 -- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。 +- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)を参考にして`leader-weight`と`region-weight`の値を調整してください。 - その他の不明な理由。ただし、 `leader-weight`と`region-weight`の値を調整することで、リーダー/リージョンの配分を制御することができます。 異なるストア間で評価に大きな差がある場合は、オペレーター関連の指標、特にオペレーターの生成と実行に焦点を当てて調査する必要があります。主な状況としては、以下の2つが挙げられます。 @@ -231,7 +231,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 - 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 -- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 +- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 対応するオペレーターの生成に失敗した場合、考えられる理由は次のとおりです。 @@ -291,12 +291,12 @@ v3.0.4およびv2.1.16以前では、特定の状況（主にテーブルの削 TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30分後 (設定項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。 -実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。 +実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`を大きく調整することができます。 -TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 +TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`を加算した場合と同様の効果）。 v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を指定します（デフォルトでは無効）。 > **Note:** > -> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**Leaderの排除**リクエストを処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 +> **リーダーの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**リーダーの排除**リクエストを処理できない場合があります。その結果、**リーダーの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md index 36937a40bf8c4..fb2f337bc316e 100644 --- a/best-practices/readonly-nodes.md +++ b/best-practices/readonly-nodes.md @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/'] ### 1. 一部のTiKVノードを読み取り専用として指定する {#1-specify-some-tikv-nodes-as-read-only} -一部のTiKVノードを読み取り専用として指定するには、これらのノードに特別なラベル（ラベルキーのプレフィックスとして`$`使用）を付けます。配置ルールを使用してこれらのノードにデータを格納するように明示的に指定しない限り、PDはこれらのノードにデータをスケジュールしません。 +一部のTiKVノードを読み取り専用として指定するには、これらのノードに特別なラベル（ラベルキーのプレフィックスとして`$`を使用）を付けます。配置ルールを使用してこれらのノードにデータを格納するように明示的に指定しない限り、PDはこれらのノードにデータをスケジュールしません。 `tiup cluster edit-config`コマンドを実行して読み取り専用ノードを構成できます。 @@ -117,7 +117,7 @@ set tidb_replica_read=learner; #### 3.2 クラスターデータのバックアップ時にFollower Readを使用する {#3-2-use-follower-read-when-backing-up-cluster-data} -クラスターデータのバックアップ時に読み取り専用ノードからデータを読み取るには、brコマンドラインで`--replica-read-label`オプションを指定します。シェルで次のコマンドを実行する際は、 `$`解析されないように、ラベルを一重引用符で囲む必要があることに注意してください。 +クラスターデータのバックアップ時に読み取り専用ノードからデータを読み取るには、brコマンドラインで`--replica-read-label`オプションを指定します。シェルで次のコマンドを実行する際は、 `$`が解析されないように、ラベルを一重引用符で囲む必要があることに注意してください。 ```shell tiup br backup full ... --replica-read-label '$mode:readonly' diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index f3e7fc44ff520..a2aab5621b1bc 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -77,10 +77,10 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに接続して自身のテナント（データベース）内のデータを操作します。多数の接続をサポートするには、次の点に留意してください。 - より多くの同時リクエストをサポートするには、TiDB 設定項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。 -- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。 -- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`文が長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 +- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ割り当てを増やすことをお勧めします。 +- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`文が長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ割り当てを増やすことをお勧めします。 -## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully} +## ステイル読み取りは慎重に使用してください {#use-stale-read-carefully} [ステイル読み取り](/stale-read.md)を使用すると、古いスキーマバージョンによって過去のスキーマがフルロードされ、パフォーマンスに重大な影響を与える可能性があります。この問題を軽減するには、 [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740)の値を（例えば`255`に）増やしてください。 diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index 434f5259035cf..cdcb613ca164d 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -1,6 +1,6 @@ --- title: Best Practices for Local Reads in Three-Data-Center Deployments -summary: TiDBの3データセンターデプロイモデルでは、センター間データ読み取りによりアクセスレイテンシーが増加する可能性があります。これを軽減するために、 ステイル読み取り機能ではローカルの履歴データへのアクセスを可能にし、リアルタイムデータ可用性を犠牲にしてレイテンシーを削減します。地理的に分散されたシナリオでステイル読み取りを使用する場合、TiDBはセンター間ネットワークレイテンシーを回避するためにローカルレプリカにアクセスします。これは、zone`ラベルを設定し、`tidb_replica_read`を`closest-replicas`に設定することで実現されます。Stale ステイル読み取りの実行方法の詳細については、ドキュメントを参照してください。 +summary: TiDBの3データセンターデプロイモデルでは、センター間データ読み取りによりアクセスレイテンシーが増加する可能性があります。これを軽減するために、 ステイル読み取り機能ではローカルの履歴データへのアクセスを可能にし、リアルタイムデータ可用性を犠牲にしてレイテンシーを削減します。地理的に分散されたシナリオでステイル読み取りを使用する場合、TiDBはセンター間ネットワークレイテンシーを回避するためにローカルレプリカにアクセスします。これは、 `zone`ラベルを設定し、`tidb_replica_read`を`closest-replicas`に設定することで実現されます。ステイル読み取りの実行方法の詳細については、ドキュメントを参照してください。 aliases: ['/ja/tidb/stable/three-dc-local-read/'] --- diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 0286129f04031..b82df5bcee30f 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -82,14 +82,14 @@ TiKVはフォアグラウンドタスクに加えて、バックグラウンド #### `rocksdb.max-background-jobs`と`rocksdb.max-sub-compactions` {#rocksdb-max-background-jobs-and-rocksdb-max-sub-compactions} -RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。デフォルト値は`rocksdb.max-background-jobs`ですが、 `8`に設定されており、明らかに必要なリソースを超えています。したがって、リソース使用量を制限するために値を調整する必要があります。 +RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。 `rocksdb.max-background-jobs`のデフォルト値は`8`であり、明らかに必要なリソースを超えています。したがって、リソース使用量を制限するために値を調整する必要があります。 -`rocksdb.max-sub-compactions` 、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。 +`rocksdb.max-sub-compactions`は、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。 このテストでは、 `rocksdb.max-background-jobs`の値は`3`に、 `rocksdb.max-sub-compactions`の値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。 -- 書き込み停止が発生する場合は、値を`rocksdb.max-background-jobs`増やします。 -- 書き込み停止が続く場合は、値`rocksdb.max-sub-compactions`を`2`または`3`に設定します。 +- 書き込み停止が発生する場合は、 `rocksdb.max-background-jobs`の値を増やします。 +- 書き込み停止が続く場合は、 `rocksdb.max-sub-compactions`の値を`2`または`3`に設定します。 #### `rocksdb.rate-bytes-per-sec` {#rocksdb-rate-bytes-per-sec} diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index b38dfe42961de..eccb373a3d041 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -22,7 +22,7 @@ TiDBは、MySQLのプロトコルと構文に対応した分散データベー ## 基本概念 {#basic-concepts} -ベストプラクティスは、その実装原則と密接に関連しています。Raftコンセンサスアルゴリズム、分散トランザクション、データシャーディング、Raftバランシング、SQLからキーバリュー（KV）へのマッピングソリューション、セカンダリインデックスの実装方法、分散実行エンジンなど、基本的なメカニズムを習得することをお勧めします。 +ベストプラクティスは、その実装原則と密接に関連しています。Raftコンセンサスアルゴリズム、分散トランザクション、データシャーディング、ロードバランシング、SQLからキーバリュー（KV）へのマッピングソリューション、セカンダリインデックスの実装方法、分散実行エンジンなど、基本的なメカニズムを習得することをお勧めします。 このセクションでは、これらの概念について説明します。詳細については、 [PingCAPのブログ記事](https://pingcap.com/blog/)を参照してください。 @@ -108,7 +108,7 @@ MySQLで培った多くの経験は、TiDBにも応用できます。ただし 以下の2つの条件では、2回のアクセスという問題は発生しません。 - - インデックスの列は既にクエリの要件を満たしています。 `c`テーブルの`t`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。 + - インデックスの列は既にクエリの要件を満たしています。 `t`テーブルの`c`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`を例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。 - テーブルの主キーは整数型です。この場合、TiDBは主キーの値を行IDとして使用します。したがって、クエリ条件が主キーに基づいている場合は、行IDの範囲を直接構築し、テーブルデータをスキャンして結果を取得できます。 @@ -160,9 +160,9 @@ TiDBクラスタのデプロイには[TiUP](/production-deployment-using-tiup.md `INSERT` 、 `UPDATE` 、 `DELETE`のいずれのステートメントであっても、ステートメントをバッチに分割するか、ステートメントに制限を追加することをお勧めします。 -大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`を使用することをお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`条件としてループを終了します。 +大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`を使用することをお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`を条件としてループを終了します。 -一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージコレクションによってすべてクリアされます）、次の`DELETE`文に影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`上のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。 +一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージコレクションによってすべてクリアされます）、次の`DELETE`文に影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。 ```sql for i from 0 to 23: @@ -203,7 +203,7 @@ TiDB 4.0 以降、TiDB は使いやすさを向上させるために[TiDB Dashbo TiDB には、中国語と英語の両方で多数の公式文書があります。問題が発生した場合は、 [FAQ](/faq/tidb-faq.md)と[TiDB クラスタトラブルシューティングガイド](/troubleshoot-tidb-cluster.md)から始めることができます。 [TiDBリポジトリ（GitHub）](https://github.com/pingcap/tidb)でIssueリストを検索したり、Issueを作成したりすることもできます。 -TiDB には便利な移行ツールも多数あります。詳細については、[移行ツールの概要](/ecosystem-tool-user-guide.md)ご覧ください。 +TiDB には便利な移行ツールも多数あります。詳細については、[移行ツールの概要](/ecosystem-tool-user-guide.md)をご覧ください。 TiDB の技術的な詳細に関する記事については、 [PingCAP公式ブログサイト](https://pingcap.com/blog/)を参照してください。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index bda9c4e031abf..b103916a1a6f4 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -51,7 +51,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル このテストでは、次のテーブル構成間でのクエリパフォーマンスを比較します。 -- パーティションテーブル +- 非パーティションテーブル - ローカルインデックスを持つパーティションテーブル - グローバルインデックスを持つパーティションテーブル @@ -116,7 +116,7 @@ WHERE `fa`.`sid` IN ( | コンフィグレーション | 平均クエリ時間 | COP タスク（インデックススキャン） | COP タスク（テーブル検索） | COP タスクの合計 | | ------------------------- | ------- | ------------------ | ------------- | -------- | -| パーティションテーブル | 12.6ミリ秒 | 72 | 79 | 151 | +| 非パーティションテーブル | 12.6ミリ秒 | 72 | 79 | 151 | | ローカルインデックスを持つパーティションテーブル | 108ミリ秒 | 600 | 375 | 975 | | グローバルインデックスを持つパーティションテーブル | 14.8ミリ秒 | 69 | 383 | 452 | @@ -133,7 +133,7 @@ WHERE `fa`.`sid` IN ( 次の例は、各構成の実行計画を示しています。 -
パーティションテーブル +
非パーティションテーブル ``` | id | estRows | estCost | actRows | task | access object | execution info | operator info | memory | disk | @@ -255,11 +255,11 @@ TTL パフォーマンスに関する調査結果は次のとおりです。 - 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30分に増加し、変動も大きくなります。 - 負荷が高い場合、TTL ジョブは追加のスキャンと削除のオーバーヘッドにより全体的な QPS を低下させます。 -`DROP PARTITION`パフォーマンスに関する調査結果は次のとおりです。 +`DROP PARTITION`のパフォーマンスに関する調査結果は次のとおりです。 - `ALTER TABLE ... DROP PARTITION`ステートメントは、パーティション全体をほぼ即座に削除します。 - この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。 -- `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。 +- `DROP PARTITION`は、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。 #### TiDBでTTLと`DROP PARTITION`を使用する {#use-ttl-and-drop-partition-in-tidb} @@ -310,7 +310,7 @@ FIRST PARTITION LESS THAN ('2025-02-19 18:00:00') LAST PARTITION LESS THAN ('2025-02-19 20:00:00'); ``` -`FIRST PARTITION`と`LAST PARTITION`定期的に更新するには、次のようなDDL文を実行します。これらの文は古いパーティションを削除し、新しいパーティションを作成します。 +`FIRST PARTITION`と`LAST PARTITION`を定期的に更新するには、次のようなDDL文を実行します。これらの文は古いパーティションを削除し、新しいパーティションを作成します。 ```sql ALTER TABLE ad_cache FIRST PARTITION LESS THAN ("${nextTimestamp}"); @@ -319,7 +319,7 @@ ALTER TABLE ad_cache LAST PARTITION LESS THAN ("${nextTimestamp}"); #### 推奨事項 {#recommendations} -- 大規模なデータクリーンアップや時間ベースのデータクリーンアップには、パーティション分割テーブル（パーティション番号`DROP PARTITION`を使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。 +- 大規模または時間ベースのデータクリーンアップには、 `DROP PARTITION`を使用したパーティション分割テーブルを使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。 - きめ細かいデータクリーンアップやバックグラウンドデータクリーンアップにはTTLを使用してください。TTLは、書き込みスループットが高いワークロードや、大量のデータを迅速に削除するワークロードには適していません。 ### パーティション削除の効率: ローカルインデックスとグローバルインデックス {#partition-drop-efficiency-local-indexes-vs-global-indexes} @@ -379,7 +379,7 @@ TiDBはテーブルデータとインデックスをリージョンに保存し **パーティション化されていないテーブル** -パーティションテーブルでは、新しい行は常に最大のキー値を持ち、同じ「最後の」リージョンに書き込まれます。この単一のリージョンは、1つのTiKVノードによって処理されるため、書き込みのボトルネックになる可能性があります。 +パーティション化されていないテーブルでは、新しい行は常に最大のキー値を持ち、同じ「最後の」リージョンに書き込まれます。この単一のリージョンは、1つのTiKVノードによって処理されるため、書き込みのボトルネックになる可能性があります。 **ハッシュまたはキーでパーティション分割されたテーブル** @@ -428,7 +428,7 @@ PARTITION BY KEY (id) PARTITIONS 16; SELECT * FROM server_info WHERE `serial_no` = ?; ``` -- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`サポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例： +- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`をサポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例： ```sql ALTER TABLE server_info ADD UNIQUE INDEX(serial_no, id) GLOBAL; @@ -599,7 +599,7 @@ SHOW TABLE employees PARTITION (p4) regions; #### ベストプラクティス {#best-practices} -新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 +新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)の手順に従います。 ### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index e76046d07fc3f..ae30e459118ab 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -1,6 +1,6 @@ --- title: Best Practices for Using UUIDs as Primary Keys -summary: UUIDを主キーとして使用すると、ネットワーク通信の削減、ほとんどのプログラミング言語とデータベースでのサポート、列挙攻撃からの保護などの利点が得られます。UUIDはバイナリ形式でBINARY(16)`列に保存することをお勧めします。また、ホットスポットの発生を防ぐため、TiDBでは`swap_flag`の設定を避けることをお勧めします。UUIDはMySQLと互換性があります。 +summary: UUIDを主キーとして使用すると、ネットワーク通信の削減、ほとんどのプログラミング言語とデータベースでのサポート、列挙攻撃からの保護などの利点が得られます。UUIDはバイナリ形式で`BINARY(16)`列に保存することをお勧めします。また、ホットスポットの発生を防ぐため、TiDBでは`swap_flag`の設定を避けることをお勧めします。UUIDはMySQLと互換性があります。 aliases: ['/ja/tidb/stable/uuid/','/ja/tidbcloud/uuid/'] --- @@ -26,9 +26,9 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} -`UUID_TO_BIN()`関数は、 1つの引数 (UUID)、または 2つの引数 (2 番目の引数は`swap_flag`とともに使用できます。 +`UUID_TO_BIN()`関数は、 1つの引数（UUID）で使用することも、 2つの引数（2番目の引数は`swap_flag`）で使用することもできます。 -[ホットスポット](/best-practices/high-concurrency-best-practices.md)回避するために、 TiDB で`swap_flag`設定しないことをお勧めします。 +[ホットスポット](/best-practices/high-concurrency-best-practices.md)を回避するために、 TiDB で`swap_flag`を設定しないことをお勧めします。 ホットスポットを回避するために、UUID ベースの主キーに[`CLUSTERED`オプション](/clustered-indexes.md)を明示的に設定することもできます。