diff --git a/ai/examples/image-search-with-pytidb.md b/ai/examples/image-search-with-pytidb.md index 27e6cd2ffefaf..25699d99b2d64 100644 --- a/ai/examples/image-search-with-pytidb.md +++ b/ai/examples/image-search-with-pytidb.md @@ -61,7 +61,7 @@ EOF ### ステップ4．データセットをダウンロードして解凍する {#step-4-download-and-extract-the-dataset} -[オックスフォード・ペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。 +[オックスフォードペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。 *Linux/macOSの場合：* @@ -86,7 +86,7 @@ streamlit run app.py サンプルアプリでは、 **Load Sample Data**ボタンをクリックすると、サンプルデータがデータベースに読み込まれます。 -または、オックスフォード・ペット・データセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。 +または、オックスフォードペットデータセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。 ### ステップ7. 検索 {#step-7-search} diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index db4c849cd6ba4..9f49854d4fb13 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -1,13 +1,13 @@ --- title: Checkpoint Backup -summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイント・バックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。 +summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイントバックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。 --- # チェックポイントバックアップ {#checkpoint-backup} スナップショットバックアップは、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v6.5.0より前のバージョンでは、中断前にバックアップされたデータはエラーが解決された後でも無効となり、最初からバックアップをやり直す必要がありました。大規模クラスターの場合、これはかなりのコスト増加につながります。 -TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイント・バックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。 +TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイントバックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。 ## アプリケーションシナリオ {#application-scenarios} @@ -17,13 +17,13 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。 -`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 +`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイントバックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 `br`バックアップを再試行する際、外部ストレージからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 `br`チェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。 ## 使用制限 {#usage-limitations} -チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。 +チェックポイントバックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。 ### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc} diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index ac56c6ecf0ab8..640088bf2a2e5 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -7,7 +7,7 @@ summary: TiDB v7.1.0ではチェックポイント復元が導入され、中断 スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。 -TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 +TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイントリストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 ## アプリケーションシナリオ {#application-scenarios} diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 7bda2ed107107..d5809ea5a6c91 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -152,7 +152,7 @@ JDBC API の使用方法については、 [JDBC公式チュートリアル](htt #### Prepare APIを使用する {#use-prepare-api} -OLTP（オンライン・トランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。 +OLTP（オンライントランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。 現在、ほとんどの上位フレームワークはSQL実行のためにPrepare APIを呼び出しています。開発でJDBC APIを直接使用する場合は、Prepare APIを選択するように注意してください。 diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 05d5c34bf4381..8d687c05e385f 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -234,9 +234,9 @@ CREATE TABLE `bookshop`.`users` ( `bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 -このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 +このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（Hybrid Transactional and Analytical Processing）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 -TiDBでは、オンライン・トランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 +TiDBでは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 ### 列ベースのデータを複製する {#replicate-column-based-data} diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 197218edb068a..837435992f83a 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-hybrid-oltp-and-olap-queries/','/ja/tidbclo # HTAPクエリ {#htap-queries} -HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 +HTAPは、Hybrid Transactional and Analytical Processingの略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 TiDBは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向ストレージエンジンであるTiFlashを使用します。HTAPでは、行ベースのストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのストレージエンジンはOLTPのパフォーマンスを最適化し、列指向ストレージエンジンはOLAPのパフォーマンスを最適化します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index ff5f6a8c67e9d..6ffce57b93b53 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -1,15 +1,15 @@ --- title: DR Solution Based on Primary and Secondary Clusters -summary: TiCDCに基づいたプライマリ・セカンダリディザスタリカバリの実装方法を学びましょう。 +summary: TiCDCに基づいたプライマリセカンダリディザスタリカバリの実装方法を学びましょう。 --- # プライマリクラスタとセカンダリクラスタに基づく災害復旧ソリューション {#dr-solution-based-on-primary-and-secondary-clusters} プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスタとセカンダリクラスタで構成されます。プライマリクラスタはユーザーからのリクエストを処理し、セカンダリクラスタはプライマリクラスタからデータをバックアップします。プライマリクラスタに障害が発生した場合、セカンダリクラスタがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。 -プライマリ・セカンダリ型災害復旧ソリューションには、以下の利点があります。 +プライマリセカンダリ型災害復旧ソリューションには、以下の利点があります。 -- 高可用性：プライマリ・セカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。 +- 高可用性：プライマリセカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。 - 高速切り替え：プライマリクラスタに障害が発生した場合、システムはセカンダリクラスタに迅速に切り替えてサービスの提供を継続できます。 - データの一貫性：セカンダリクラスタは、プライマリクラスタのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスタに切り替わった場合でも、データは基本的に最新の状態に保たれます。 @@ -408,7 +408,7 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht > **Note:** > -> プライマリ・セカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。 +> プライマリセカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。 ### プライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する {#perform-bidirectional-replication-between-the-primary-and-secondary-clusters} diff --git a/explore-htap.md b/explore-htap.md index 152f9d34bf4a7..ee41b1b3f21d8 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -39,7 +39,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 - ハイブリッドワークロードの分離 - 高負荷なオンライン・トランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。 + 高負荷なオンライントランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。 - ETLテクノロジースタックを簡素化する @@ -51,7 +51,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 ## アーキテクチャ {#architecture} -TiDBでは、オンライン・トランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 +TiDBでは、オンライントランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 アーキテクチャの詳細については、 [TiDB HTAPのアーキテクチャ](/tiflash/tiflash-overview.md#architecture)を参照してください。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 4e59c9780f57c..14aba8199eac5 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -15,7 +15,7 @@ TiDB がサポートするオペレーティングシステムについては、 ### 開発、テスト、または本番環境における TiDB クラスターの推奨ハードウェア構成は何ですか? {#what-is-the-recommended-hardware-configuration-for-a-tidb-cluster-in-the-development-test-or-production-environment} -TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェア・サーバー・プラットフォーム、またはARMアーキテクチャのハードウェア・サーバー・プラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバー・ハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 +TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェアサーバープラットフォーム、またはARMアーキテクチャのハードウェアサーバープラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバーハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 ### 10 ギガビットのネットワークカード 2枚の目的は何ですか? {#whats-the-purposes-of-2-network-cards-of-10-gigabit} diff --git a/glossary.md b/glossary.md index 02a2f398b19e6..b77bb0956f316 100644 --- a/glossary.md +++ b/glossary.md @@ -217,7 +217,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 ### オンライントランザクション処理（OLTP） {#online-transaction-processing-oltp} -オンライン・トランザクション処理（OLTP）とは、レコードの選択、挿入、更新、削除といったトランザクション処理に特化したデータベースワークロードを指します。 +オンライントランザクション処理（OLTP）とは、レコードの選択、挿入、更新、削除といったトランザクション処理に特化したデータベースワークロードを指します。 ### メモリ不足 (OOM) {#out-of-memory-oom} diff --git a/import-example-data.md b/import-example-data.md index ed177b8463540..9dc592465daae 100644 --- a/import-example-data.md +++ b/import-example-data.md @@ -5,7 +5,7 @@ summary: Bikeshare サンプルデータベースをインストールします # サンプルデータベースのインポート {#import-example-database} -TiDB マニュアルで使用されている例では、 [キャピタル・バイクシェア・データライセンス契約](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 +TiDB マニュアルで使用されている例では、 [Capital Bikeshare Data License Agreement](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 ## すべてのデータファイルをダウンロードする {#download-all-data-files} diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index a43f57f86b1c7..a622c724fc6a0 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -99,7 +99,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ## ステップ2. 全データの移行 {#step-2-migrate-full-data} -環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップ・リストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 +環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップおよびリストア機能を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 > **Note:** > diff --git a/migration-overview.md b/migration-overview.md index ac63d56bdb9ed..e01981dbe0d18 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -40,7 +40,7 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 - [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) -シャードテーブルのデータサイズが大きく（例えば1TiB以上）、移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してシャードテーブルを迅速にマージ・インポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分シャーディングデータ（binlog）を複製できます。 +シャードテーブルのデータサイズが大きく（例えば1TiB以上）、移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してシャードテーブルを迅速にマージおよびインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分シャーディングデータ（binlog）を複製できます。 - [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) diff --git a/optimizer-hints.md b/optimizer-hints.md index 85b297fec9225..2903278789382 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -100,13 +100,13 @@ SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > > 場合によっては、 `INL_JOIN`ヒントが効かないことがあります。詳しくは[`INL_JOIN`ヒントは有効になりません](#inl_join-hint-does-not-take-effect)を参照してください。 -ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス・ネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルが`WHERE`条件でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： +ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックスネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルが`WHERE`条件でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： ```sql SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id; ``` -上記のSQL文では、ヒント`INL_JOIN(t1, t2)`はオプティマイザに、 `t1`と`t2`に対してインデックス・ネストループ結合アルゴリズムを使用するように指示しています。これは、 `t1`と`t2`の間でインデックス・ネストループ結合アルゴリズムが使用されることを意味するわけではないことに注意してください。ヒントは、 `t1`と`t2`がそれぞれ別のテーブル（ `t3` ）に対してインデックス・ネストループ結合アルゴリズムを使用することを示しています。 +上記のSQL文では、ヒント`INL_JOIN(t1, t2)`はオプティマイザに、 `t1`と`t2`に対してインデックスネストループ結合アルゴリズムを使用するように指示しています。これは、 `t1`と`t2`の間でインデックスネストループ結合アルゴリズムが使用されることを意味するわけではないことに注意してください。ヒントは、 `t1`と`t2`がそれぞれ別のテーブル（ `t3` ）に対してインデックスネストループ結合アルゴリズムを使用することを示しています。 `INL_JOIN()`で指定されたパラメータは、クエリプランを作成する際に内部テーブルとして使用される候補テーブルです。例えば、 `INL_JOIN(t1)`は、TiDB がクエリプランを作成する際に内部テーブルとして`t1`を使用することを検討することを意味します。候補テーブルに別名がある場合は、 `INL_JOIN()`のパラメータとしてその別名を使用する必要があります。別名がない場合は、テーブルの元の名前をパラメータとして使用してください。例えば、 `select /*+ INL_JOIN(t1) */ * from t t1, t t2 where t1.a = t2.b;`というクエリでは、 `INL_JOIN()`のパラメータとして`t`ではなく、 `t`テーブルの別名である`t1`または`t2`を使用する必要があります。 @@ -124,7 +124,7 @@ SELECT /*+ NO_INDEX_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ### INL_HASH_JOIN {#inl_hash_join} -ヒント`INL_HASH_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・ハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用するための条件は、インデックス・ネストループ結合アルゴリズムを使用するための条件と同じです。2つのアルゴリズムの違いは、 `INL_JOIN`は結合された内部テーブルにハッシュテーブルを作成するのに対し、 `INL_HASH_JOIN`は結合された外部テーブルにハッシュテーブルを作成する点です。 `INL_HASH_JOIN`はメモリ使用量に制限がありますが、ヒント`INL_JOIN`は内部テーブルで一致する行数に応じてメモリ使用量が異なります。 +ヒント`INL_HASH_JOIN(t1_name [, tl_name])`は、インデックスネストループハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用するための条件は、インデックスネストループ結合アルゴリズムを使用するための条件と同じです。2つのアルゴリズムの違いは、 `INL_JOIN`は結合された内部テーブルにハッシュテーブルを作成するのに対し、 `INL_HASH_JOIN`は結合された外部テーブルにハッシュテーブルを作成する点です。 `INL_HASH_JOIN`はメモリ使用量に制限がありますが、ヒント`INL_JOIN`は内部テーブルで一致する行数に応じてメモリ使用量が異なります。 ### NO_INDEX_HASH_JOIN(t1_name [, tl_name ...]) {#no_index_hash_joint1_name--tl_name-} @@ -136,7 +136,7 @@ SELECT /*+ NO_INDEX_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > > TiDB v8.3.0 以降、`INL_MERGE_JOIN`ヒントは非推奨となり、誤った結果を返す可能性があるため、効果がなくなりました。クエリでこのヒントを指定した場合、TiDB はこれを無視して別の結合アルゴリズムを選択します。 -TiDB v8.3.0 より前では、ヒント`INL_MERGE_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・マージ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用する条件は、インデックス・ネストループ結合アルゴリズムを使用する条件と同じです。 +TiDB v8.3.0 より前では、ヒント`INL_MERGE_JOIN(t1_name [, tl_name])`は、インデックスネストループマージ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用する条件は、インデックスネストループ結合アルゴリズムを使用する条件と同じです。 ### NO_INDEX_MERGE_JOIN(t1_name [, tl_name ...]) {#no_index_merge_joint1_name--tl_name-} diff --git a/privilege-management.md b/privilege-management.md index 29bb4f35f1b09..a8d49022f5f9e 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -483,7 +483,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### アルター・リソース・グループ {#alter-resource-group} +### アルターリソースグループ {#alter-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 82cedaf896d59..921459fda92bc 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -174,7 +174,7 @@ TiDB バージョン: 6.1.0 TiKV API V2 は、次のような新しい Raw Key Valueストレージ形式とアクセス インターフェイスを提供します。 - - データはMVCCに保存され、データの変更タイムスタンプが記録されます。この機能は、変更データキャプチャ（CDC）と増分バックアップ・リストアの実装の基盤となります。 + - データはMVCCに保存され、データの変更タイムスタンプが記録されます。この機能は、変更データキャプチャ（CDC）と増分バックアップおよびリストアの実装の基盤となります。 - データはさまざまな使用法に応じてスコープ設定され、単一の TiDB クラスター、トランザクション KV、RawKV アプリケーションの共存をサポートします。 diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 72d09b6430980..4568293f4768f 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.6 - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - [`changefeed-error-stuck-duration`](/ticdc/ticdc-changefeed-config.md) : 内部エラーまたは例外が発生したときに、変更フィードが自動的に再試行される期間を設定できます[＃9875](https://github.com/pingcap/tiflow/issues/9875) @[asddongmen](https://github.com/asddongmen) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[CharlesCheung96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} @@ -33,7 +33,7 @@ TiDB バージョン: 6.5.6 - OOM を防ぐためにリゾルバのメモリ使用量を最適化します [＃15458](https://github.com/tikv/tikv/issues/15458) @[overvenus](https://github.com/overvenus) - ルータオブジェクトのLRUCacheを排除してメモリ使用量を削減し、OOM を防止します。 [＃15430](https://github.com/tikv/tikv/issues/15430) @[Connor1996](https://github.com/Connor1996) - - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[トニー・シュッキ](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) + - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[tonyxuqqi](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) - PD diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 7d7a499991a26..b0f377bbc1a29 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -15,7 +15,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 以前の LTS 6.5.0 と比較して、7.1.0 には、 [6.6.0-DMR](/releases/release-6.6.0.md) 、 [7.0.0-DMR](/releases/release-7.0.0.md)でリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。 -
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーション・クラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
+
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーションクラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
## 機能の詳細 {#feature-details} @@ -101,7 +101,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。 - TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 + TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイントリストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 詳細については[ドキュメント](/br/br-checkpoint-restore.md)を参照してください。 diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 01c1db6657718..af0f97a44f188 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -18,7 +18,7 @@ TiDB バージョン: 7.1.3 - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)を設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[CharlesCheung96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} diff --git a/sql-plan-management.md b/sql-plan-management.md index 2225f4ec691ba..de66ee199d548 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -630,7 +630,7 @@ SHOW GLOBAL BINDINGS; [アップグレード中の実行計画の回帰を防ぐ](#prevent-regression-of-execution-plans-during-an-upgrade)に使用されるこの機能は、キャプチャ条件を満たすクエリをキャプチャし、これらのクエリのバインディングを作成します。 -プラン・ベースラインとは、オプティマイザがSQL文の実行に使用できる承認済みのプランの集合を指します。通常、TiDBはプランが適切に実行されることを確認した後にのみ、プランをプラン・ベースラインに追加します。ここで言うプランとは、オプティマイザが実行計画を再現するために必要なすべてのプラン関連の詳細（SQLプラン識別子、ヒントセット、バインド値、オプティマイザ環境など）を包含するものです。 +プランベースラインとは、オプティマイザがSQL文の実行に使用できる承認済みのプランの集合を指します。通常、TiDBはプランが適切に実行されることを確認した後にのみ、プランをプランベースラインに追加します。ここで言うプランとは、オプティマイザが実行計画を再現するために必要なすべてのプラン関連の詳細（SQLプラン識別子、ヒントセット、バインド値、オプティマイザ環境など）を包含するものです。 ### キャプチャを有効にする {#enable-capturing} diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 4354d53eba98d..6d7ce3cd6c54d 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -7,13 +7,13 @@ summary: TiDB Cloudのアーキテクチャ概念について学びましょう -TiDB Cloudは、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）であり、オープンソースのHTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（Hybrid Transactional and Analytical Processing）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 -TiDB Cloudは、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）であり、オープンソースのHTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（Hybrid Transactional and Analytical Processing）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 diff --git a/tidb-cloud/dedicated/_index.md b/tidb-cloud/dedicated/_index.md index adb8cd80da229..0a5f0bfcf2b67 100644 --- a/tidb-cloud/dedicated/_index.md +++ b/tidb-cloud/dedicated/_index.md @@ -3,7 +3,7 @@ title: TiDB Cloud Documentation aliases: ['/ja/tidbcloud/privacy-policy','/ja/tidbcloud/terms-of-service','/ja/tidbcloud/service-level-agreement'] hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/essential/_index.md b/tidb-cloud/essential/_index.md index f52c9aa34e3d5..f2255ea8a16d4 100644 --- a/tidb-cloud/essential/_index.md +++ b/tidb-cloud/essential/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/premium/_index.md b/tidb-cloud/premium/_index.md index 65c7bc9902b5a..c55ff262ab5c3 100644 --- a/tidb-cloud/premium/_index.md +++ b/tidb-cloud/premium/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、TiDBの優れた機能をすべてクラウド上で提供する、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ、課金、統合、参照のためのガイド、サンプル、リファレンスを提供します。 +summary: TiDB Cloudは、TiDBの優れた機能をすべてクラウド上で提供する、フルマネージド型のデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ、課金、統合、参照のためのガイド、サンプル、リファレンスを提供します。 --- diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 21dbf8d67767e..3e5808875025e 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -45,7 +45,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] ### ルート証明書の発行と有効性 {#root-certificate-issuance-and-validity} -TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツ・エンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 +TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [Let's Encrypt](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlclient](https://github.com/PyMySQL/mysqlclient)を使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`を設定する必要があります。 diff --git a/tidb-cloud/starter/_index.md b/tidb-cloud/starter/_index.md index bd05b89ecf258..16011a64fba8d 100644 --- a/tidb-cloud/starter/_index.md +++ b/tidb-cloud/starter/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index b226e0e164142..a7939290d4cc1 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -117,7 +117,7 @@ TiDB は MySQL と高い互換性があります。データがセルフホス ### TiDB CloudのHTAP機能を利用するにはどうすればよいですか？ {#how-do-i-make-use-of-tidb-cloud-s-htap-capabilities} -従来、データベースにはオンライン・トランザクション処理（OLTP）データベースとオンライン分析処理（OLAP）データベースの2種類がありました。OLTPとOLAPのリクエストは、多くの場合、それぞれ独立したデータベースで処理されます。このような従来のアーキテクチャでは、OLTPデータベースからOLAP用のデータウェアハウスやデータレイクへデータを移行するには、時間がかかり、エラーが発生しやすいプロセスとなります。 +従来、データベースにはオンライントランザクション処理（OLTP）データベースとオンライン分析処理（OLAP）データベースの2種類がありました。OLTPとOLAPのリクエストは、多くの場合、それぞれ独立したデータベースで処理されます。このような従来のアーキテクチャでは、OLTPデータベースからOLAP用のデータウェアハウスやデータレイクへデータを移行するには、時間がかかり、エラーが発生しやすいプロセスとなります。 TiDB Cloudは、ハイブリッドトランザクション分析処理（HTAP）データベースとして、OLTP（TiKV）ストアとOLAP（ TiFlash ）ストア間でデータを自動的に確実に複製することで、システムアーキテクチャの簡素化、メンテナンスの複雑さの軽減、トランザクションデータに対するリアルタイム分析のサポートを実現します。HTAPの一般的なユースケースとしては、ユーザーパーソナライゼーション、AIによるレコメンデーション、不正検出、ビジネスインテリジェンス、リアルタイムレポートなどが挙げられます。 @@ -152,7 +152,7 @@ TiDB CloudはTLS 1.2またはTLS 1.3をサポートしています。 ### TiDB Cloudを自分のVPC内で実行できますか？ {#can-i-run-tidb-cloud-in-my-vpc} -いいえ。TiDB Cloudはデータベース・アズ・ア・サービス（DBaaS）であり、 TiDB Cloud VPC内でのみ動作します。クラウドコンピューティングのマネージドサービスとして、 TiDB Cloudは物理ハードウェアのセットアップやソフトウェアのインストールを必要とせずにデータベースへのアクセスを提供します。 +いいえ。TiDB Cloudはデータベースアズアサービス（DBaaS）であり、 TiDB Cloud VPC内でのみ動作します。クラウドコンピューティングのマネージドサービスとして、 TiDB Cloudは物理ハードウェアのセットアップやソフトウェアのインストールを必要とせずにデータベースへのアクセスを提供します。 ### 私のTiDB Cloudのリソースは安全ですか？ {#is-my-tidb-cloud-resource-secure} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index a76ac9dd73893..277044ea53bb9 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -27,9 +27,9 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -43,7 +43,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 530ad43570577..bf0a56c77a6eb 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -27,9 +27,9 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -42,7 +42,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 99837c4fb90c6..2ed5ba9791ce4 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -48,9 +48,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -64,7 +64,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index fa5211f4a314e..29e00becd1c63 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -28,9 +28,9 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -43,7 +43,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index b0c34ee9a4433..e57363aa66bd6 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -48,9 +48,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -64,7 +64,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 3762632bcfcd2..2da1f8387cef1 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -28,9 +28,9 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -43,7 +43,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index c9e1fa40aa0fd..053a5dfbd4991 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -53,9 +53,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -69,7 +69,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index bc5fb92dc8636..7e31c2060d06b 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -39,9 +39,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -54,7 +54,7 @@ raft-engine.prefill-for-recycle = true 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index 3ef88396906b7..667eeba80f389 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -53,9 +53,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -69,7 +69,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index fd579d1452477..27008b71082ce 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -39,9 +39,9 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge @@ -54,7 +54,7 @@ raft-engine.prefill-for-recycle = true 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 22e13176b0ca8..73558225f9fd3 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -404,7 +404,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## 参照 {#see-also} - [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) -- [アルター・リソース・グループ](/sql-statements/sql-statement-alter-resource-group.md) +- [アルターリソースグループ](/sql-statements/sql-statement-alter-resource-group.md) - [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) - [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index ffbeb0692f00d..eb17ca5f08882 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -12,7 +12,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 - バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイクエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイクエリウォッチリストを手動で管理できます。 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index fb5843551d3e8..c57f9e47f7552 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -283,7 +283,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ > **Note:** > -> 悲観的・トランザクション・モードが設定されている場合でも、自動コミット・トランザクションはまず楽観的・モードでコミットを試行します。競合が発生した場合、自動再試行中にトランザクションは悲観的・トランザクション・モードに切り替わります。 +> 悲観的トランザクションモードが設定されている場合でも、自動コミットトランザクションはまず楽観的モードでコミットを試行します。競合が発生した場合、自動再試行中にトランザクションは悲観的トランザクションモードに切り替わります。 ### 読み書き競合 {#read-write-conflicts}