|+|今からSQLレイヤーとしても知られるTiDBサーバーのクラスタを見てみます。

|+|このレイヤーのおかげで、TiDBはSQL文を理解できます。

|+|SQLレイヤーの最も重要な機能の一つは、リレーショナルデータベースドメインのテーブル行とKVドメインのキー値ペアのマッピングを管理することです。 |+|

|+|ここでは、マッピングの動作方法について説明します。

TiDBはテーブルにテーブルIDを割り当てます。

|+|テーブルIDは、クラスタ全体で一意の整数です。

|+|`TiDBは各行に行IDを割り当てます。`

テーブル内でユニークな整数である行IDもあります。

|+| スライドの左側に、3つの行があり、それぞれが4つのカラムで構成されています。

|+|最初のカラムは、テーブルのプライマリキーです。

KVドメインは|+|右側にあります。

キーは赤で表示されます。

値は角かっこで囲まれています。

|+| また、行IDについては、TiDBサーバーが小さな最適化を行っており、|+| つまり、テーブルの主キーカラムが整数データ型である場合、|+| SQLレイヤーは主キーをそのまま行IDとして使用し、KVレコードのキーを構成します。

|+| これは、スライドに示されたケースとまさに同じです。

一方、主キーカラムが非整数のデータ型である場合、SQLレイヤーはキーのために行IDを生成およびエンコードし、KVレコードに格納します。 |+|

|+| 「クラスタ化されたインデックスセクション」で、行IDに関するより詳しい詳細について、 |+| 他のコースであるTiDB特徴機能およびトランザクション制御でカバーします。

The row ID can be used effectively in a unique get or point get query. |+| 行IDはユニーク取得またはポイント取得クエリで効果的に使用できます。

|+|テーブルプレフィックスは、フルテーブルスキャンで使用することができます。

TiKVマップの観点から、|+|関係ドメインでの完全なテーブルスキャンは実際にはKV需要でのレンダースキャンです。

|+|今度は、1つのTiKVサーバーに深く入り込んで、TiDBサーバーにあるモジュールとそれに関連する機能を見てみましょう。 |+|

|+|ネットワーク越しにクライアントがSQL文を発行したと仮定します。

フロントエンドが要求を処理するのはプロトコルレイヤーです。 |+|

プロトコルレイヤーにより、TiDBサーバーが実際にネットワークサーバーになります。

認証が完了した後、|+|セッションのコンテキストステージに到達します。

|+|セッションコンテキストを取得した後、リクエストはパッシング段階に入ります。

|+|Parserはあなたが実行したい操作やアクセスしたいデータベースオブジェクトなどを分析し、あなたの意図を論理ツリー構造として扱います。 |+| |+|

|+|その後、ルールベースの最適化器である論理最適化器に送信されます。

論理最適化プログラムは、一連のルールに従ってあなたのSQL文を適切な形に書き換える可能性があります。 |+|

|+|この部分は次のステップでより良い実行計画を生成するのに役立つ可能性があるため、存在する場合は英語の文に戻して、それ以外の場合は無視します。

|+|出力は論理的な遠足計画です。

|+|その後、コストベースの最適化プログラムに送信されます。

|+|物理的な最適化プログラムは、SQL文に必要なオブジェクトの統計など、他の重要な情報にも認識しています。 |+|

|+|例えば、テーブルに含まれる行数、各行の平均長さ、およびインデックスの情報を含む場合があります。 |+|

|+|このような統計は、物理最適化によるより良い除外計画を得るのに役立ちますが、論理最適化ではそれができません。 |+|

|+|現在、物理的な実行計画があるため、それをローカルおよび分散実行エグゼキュータに渡して実行できます。 |+|

|+|もう一つ注意すべきことは、クライアントは同時に1つのTiDBサーバーインスタンスにしか接続できないということです。つまり、クライアントセッションとTiDBサーバーインスタンスの関係は1対1であるということです。 |+| |+|

|+|ローカル実行は、セッションが接続されているTiDB|+|サーバーインスタンス上でタスクが実行されることを意味します。

|+|分散実行とは、分散SQL命令がTiKVサーバーに送信され、実行されることを意味します。 |+|

|+|バックエンドには多数のTiKVサーバーがある可能性があることはすでに知っています。

したがって、複数のTiKVサーバーが分散SQL命令を受信し、並列実行を行う可能性があります。 |+|

「TiDB パフォーマンスチューニング」というコースがあります。このコースでは、SQL チューニング、クエリオプティマイザ、および分散 SQL を含むトピックを扱っています。|+| ただし、英語の文章に「|+|」がある場合は、翻訳結果に再度挿入する必要があります。

|+|もしTiDBのパフォーマンスチューニングに興味がある場合は、|+|このコースに登録することを強くお勧めします。

|+|クライアントセッションは常に1つのTiDBサーバーに接続できるため、このTiDBノードがダウンしている場合、どうなりますか。 |+|

この場合、クライアントアプリケーションは何をすべきですか。

|+|実際の答えは非常に簡単です。TiDBサーバーは状態を持たず、TiDBサーバーノードにビジネスデータが保存されていないことを意味します。したがって、TiDBサーバーがダウンした場合は、単に再接続して、健康なTiDBサーバーにセッションを再作成すればよいです。 |+| |+|

|+|再接続前後に、未完了のトランザクションを処理できるように、クライアントセッションを設定する必要があります。 |+|

|+|トランザクション処理に関する話題を扱ったコースがあります。

|+|次に、例を示します。

I will kill my TiDBサーバーインスタンス in the playground sandbox, and see what happens. |+| 私は、プレイグラウンドサンドボックス内の私のTiDBサーバーインスタンスを停止して、何が起こるかを確認します。

|+|2つのシンプルなクライアントプログラムが同時に実行されています。

|+|あるプログラムは、惑星テーブルに新しい惑星を挿入し続けており、もう一つのプログラムは同じテーブルでクエリを実行しています。 |+|

アプリケーションの両方が基本的な再接続と単純なトランザクション再コミット機構を実装しています。これにより、接続が失われた場合に、アプリケーションは再接続し、トランザクションを再実行することができます。|+| この記号は原文中に含まれていれば、翻訳結果に戻す必要があります。

|+|最初に私のプレイグラウンドクラスタの状態を確認します。

|+|今、各インスタンスのPIDがあります。ターゲットは今、TiDBサーバーインスタンスです。

|+|私たちの小さなクライアントプログラムを起動します。

|+|最初のものは、ランダムな惑星名を持つ惑星の創造者です。

|+| それでは、planetテーブルにクエリを実行します。

|+|新しい惑星が発見されているのが見られます。

今、二つの小さなプログラムが実行されています。

Pリース note both programs are aware of three TiDB server instances, they are designed to connect to any TiDB service in case of the connection failure.

|+|両方のプログラムは3つのTiDBサーバーインスタンスを認識していますが、|+|接続障害の場合は任意のTiDBサービスに接続するように設計されています。

|+|彼らはPythonで書かれており、非常にわかりやすいです。

|+|コードを見たい場合は進むことができます|+|私はTiDBの1つのインスタンスを殺します。

|+|両方のプログラムは例外に遭遇し、簡単には諦めなかった。

|+|短時間であれば、彼らは別のTiDBサーバーに再接続して、タスクを継続することができます。

|+|もう1つのTiDBインスタンスを殺してもいいですか。

|+|フェイルオーバーが再度発生していることがわかりました。最後のTiDBインスタンスを削除します。 |+|

このkill操作後、TiDBサーバーは存在しなくなります。 |+|

私はTiDBサーバーのインスタンスが3つしかないため、述べき事項が制限されています。

|+| 今、私のプログラムには話すTiDBサーバーがないことがわかります。

|+|私のビジネスは文字通り停止しています。

今、私に何ができますか。

データを失っていませんでしたか。

いいえ、TiDBサーバーは状態を持っておらず、|+| ありません。

私がすべきことは、TiDBサーバーをクラスタに再追加して、私のビジネス要件に合わせることです。 |+|

私のダミービジネスの場合、実際には1つのTiDBサーバーで十分です。

|+|だから、私はTiDBサーバーのインスタンスを1つ追加するつもりです。

|+| この操作は実際にはスケーリングアウト操作です。

|+| とても直感的なコマンドラインでそれができます。

今すぐ実行してみます。

|+|すべてが元に戻りました。

私は古いTiDBインスタンスを3つ失いました。そして、新しいTiDBインスタンスがクラスタに参加しました。 |+|

|+|このシンプルなデモでは、データは失われません。

|+|TiDBのインスタンスを手動で追加しました。

本番環境では、手動でこれを行う必要はありません。 |+|

自動的に行うための複数のオプションがあります。

|+|もしTiDB Cloudを利用している場合、さらに便利になります。