EN: |+| Now I'm going to look at the cluster of TiDB servers also known as the SQL layer. JA: |+|今からSQLレイヤーとしても知られるTiDBサーバーのクラスタを見てみます。 EN: |+| Thanks to this layer TiDB understands SQL statements. JA: |+|このレイヤーのおかげで、TiDBはSQL文を理解できます。 EN: |+| One of the most important features of SQL layer is managing the mapping between the |+| table row in relational database domain and the key value pair in KV domain. JA: |+|SQLレイヤーの最も重要な機能の一つは、リレーショナルデータベースドメインのテーブル行と |+| KVドメインのキー・バリューペアとのマッピングを管理することです。 EN: |+| Here is how the mapping works. JA: |+|ここでは、マッピングの動作について説明します。 EN: TiDB assigns a table ID to the table. JA: TiDBはテーブルにテーブルIDを割り当てます。 EN: |+| The table ID is an integer that is unique across the cluster. JA: |+|テーブルIDは、クラスタ全体でユニークな整数です。 EN: |+| TiDB also assigns a row ID to each row. JA: |+| TiDBは各行に行IDを割り当てます。 EN: The row ID is also an integer being unique within the table. JA: テーブル内でユニークな行IDも整数です。 EN: |+| In the slide, on the left side, there are three rows with four columns. JA: |+| スライドの左側に、3つの行があり、それぞれが4つのカラムで構成されています。 EN: |+| The first column is the primary key of the table. JA: |+|最初のカラムは、テーブルのプライマリキーです。 EN: The KV domain is on the |+| right side. JA: KVドメインは|+|右側にあります。 EN: The key is shown in red. JA: キーは赤で表示されます。 EN: The value is enclosed in the square brackets. JA: 値は角かっこで囲まれています。 EN: |+| Additionally, for the row ID, TiDB server has made a small optimization, |+| which is, if the primary key column for your table is integer data type, |+| then SQL layer will use the primary key as the row ID directly to compose the key for the KV record. JA: |+| また、行IDについては、TiDBサーバーが小さな最適化を行っており、|+| それは、テーブルの主キーカラムが整数データ型である場合、|+| SQLレイヤーは主キーをそのまま行IDとして使用し、KVレコードのキーを構成します。 EN: |+| This is exactly the case shown on a slide. JA: |+| これは、スライドに示されたケースとまさに同じです。 EN: On the other hand, if the primary key column is a non |+| integer data type, the SQL layer will generate and encode a row ID for the key in KV record. JA: 一方、主キーカラムが非整数のデータ型である場合、SQLレイヤーはキーのために|+| 行IDを生成およびエンコードし、KVレコードに格納します。 EN: |+| We will cover more details related to the row ID in the clustered index section, |+| in another course named TiDB Specific features and transaction control. JA: |+| TiDBの特徴機能およびトランザクション制御内の別のコース、|+|「クラスタ化されたインデックスセクション」で、行IDに関するより詳しい詳細について説明します。 EN: |+| The row ID can be used effectively in a unique get or point get query. JA: |+| 行IDはユニーク取得またはポイント取得クエリで効果的に使用されます。 EN: |+| The table prefix can be used in full table scan. JA: |+|テーブルプレフィックスは、フルテーブルスキャンで使用することができます。 EN: From TiKV map point of view, |+| the full table scan in relational domain is an actually a range scan in KV domain. JA: TiKV マップの観点からは、|+|リレーショナル領域でのフルテーブルスキャンは実際にはKV領域でのレンジスキャンです。 EN: |+| Now let's do a deep dive into a single TiKV server to see what |+| modules the TiDB server has on it and what are the related functions. JA: |+|今度は、1つのTiKVサーバーに深く入り込んで、|+| TiDBサーバーにあるモジュールとそれに関連する機能を見てみましょう。 EN: |+| Suppose the client issues an SQL statement over the network. JA: |+|ネットワーク越しにクライアントがSQL文を発行したと仮定します。 EN: The front end handles the |+| request is the protocol layer. JA: フロントエンドが要求を |+| 処理するのはプロトコルレイヤーです。 EN: The protocol layer actually makes the TiDB server a network server. JA: プロトコルレイヤーにより、TiDBサーバーが実際にネットワークサーバーになります。 EN: |+| Then you reach the session context stage after you have been authenticated. JA: |+| 認証が完了した後、セッションのコンテキスト段階に到達します。 EN: |+| After you get a session context, the request enters the parsing stage. JA: |+|セッションコンテキストを取得した後、リクエストは解析段階に入ります。 EN: |+| Parser is going to treat your SQL statement text as a logical tree structure, |+| and then analyze your intention, such as what database objects you would like to |+| access and what operations you would like to do on these database objects. JA: |+|パーサーはSQL文を論理ツリー構造として扱い、|+|アクセスしたいデータベースオブジェクトと、|+| これらのオブジェクトに対して行いたい操作などの意図を解析します。 EN: |+| After that it will be sent to a logical optimizer which is a rule-based optimizer. JA: |+|その後、ルールベースのオプティマイザである論理オプティマイザに送信されます。 EN: The logical |+| optimizer may rewrite your SQL statement into a good shape following a series of rules. JA: 論理オプティマイザは、|+| 一連のルールに従ってあなたのSQL文を適切な形に書き換える可能性があります。 EN: |+| This can help the following step to generate a better execution plan. JA: |+|これは、次のステップでより良い実行計画を生成するのに役立つ可能性があります。 EN: |+| The output is the logical execution plan. JA: |+|出力は論理的な実行計画です。 EN: |+| After that it is sent to the physical optimizer which is a cost based optimizer. JA: |+|その後、コストベースのオプティマイザである物理オプティマイザに送信されます。 EN: |+| The physical optimizer is aware of some other important information, |+| such as the statistics of the objects your SQL statement needs directly or indirectly. JA: |+|物理オプティマイザは、SQL文に必要なオブジェクトの統計など、|+| 他の重要な情報も認識しています。 EN: |+| For example it might include how many rows the table has, |+| what is the average length of each row, and the information about the indexes. JA: |+|例えば、テーブルに含まれる行数、各行の平均長、|+| およびインデックスの情報を含む場合があります。 EN: |+| Statistics like this can help the physical optimization to get a better execution plan, |+| which the logical optimization cannot. JA: |+|このような統計は、物理オプティマイザによるより良い実行計画を得るのに役立ちますが、|+| 論理最適化ではそれができません。 EN: |+| Now we have the physical execution plan it can |+| be passed into the local and the distributed executor to execute. JA: |+|これで物理的な実行計画を手に入れたので、|+| それをローカルおよび分散実行エグゼキュータに渡して実行できます。 EN: |+| Another thing, we should keep in mind, |+| is that a client can only connect to one TiDB server instance at the same time, |+| which means the relationship between client session and TiDB server instance is one to one. JA: |+|もう一つ注意すべきことは、|+|クライアントは同時に1つのTiDBサーバーインスタンスにしか接続できないということです。|+|つまり、クライアントセッションとTiDBサーバーインスタンスの関係は1対1であるということです。 EN: |+| The local execution means that the task is executed on the TiDB |+| server instance where the session is connected to. JA: |+|ローカル実行は、セッションが接続されているTiDB|+|サーバーインスタンス上でタスクが実行されることを意味します。 EN: |+| Distributed execution means the distributed SQL |+| instructions will be sent to TiKV servers for executions. JA: |+|分散実行とは、分散SQL命令がTiKVサーバーに送信され、|+|実行されることを意味します。 EN: |+| We already know that there can be a lot of TiKV servers in the backend. JA: |+|バックエンドには多数のTiKVサーバーがある可能性があることはすでに知っています。 EN: So multiple |+| TiKV servers may receive the distributed SQL instructions and leads parallel execution. JA: したがって、|+| 複数のTiKVサーバーが分散SQL命令を受信し、並列実行を行う可能性があります。 EN: |+| We also have a course available called TiDB Performance Tuning which covers the |+| topics including SQL tuning, query optimizer and the distributed SQL. JA: |+|「TiDB パフォーマンスチューニング」というコースがあります。このコースでは、SQL チューニング、|+| クエリオプティマイザ、および分散 SQL を含むトピックを扱っています。 EN: |+| If you are interested in the performance tuning topics on TiDB, |+| I highly recommend your enrol this course. JA: |+|もしTiDBのパフォーマンスチューニングに興味がある場合は、|+|このコースに登録することを強くお勧めします。 EN: |+| One question you might have is that since the client session can only connect to one TiDB server |+| at a time, what if this TiDB node is down? JA: |+|一つの疑問として、クライアントセッションが常に1つのTiDBサーバーにしか接続できないのなら、|+| このTiDBノードがダウンしている場合、どうなるのでしょうか。 EN: In this case, what should the client application do? JA: この場合、クライアントアプリケーションは何をすべきですか。 EN: |+| In fact the answer is very simple, since the TiDB server is stateless, |+| meaning no business data persisted on TiDB server node, |+| when it goes down you can just reconnect and recreate your session to a healthy TiDB server. JA: |+|実際の答えは非常に簡単です。TiDBサーバーは状態を持ちません、すなわち、|+| TiDBサーバーノードにビジネスデータが保存されていないことを意味します。したがって、|+| TiDBサーバーがダウンした場合は、単に再接続して、正常なTiDBサーバーにセッションを再作成すればよいです。 EN: |+| The client session should be able to handle any |+| unfinished transaction before and after the reconnecting. JA: |+|再接続前後に、未完了のトランザクションを処理できるように、 |+| クライアントセッションを設定する必要があります。 EN: |+| We do have a course talking about transaction handling. JA: |+|トランザクション処理に関する話題を扱ったコースがあります。 EN: |+| Next I'm going to show you an example. JA: |+|次に、例を示します。 EN: I will kill my TiDB server instance in |+| the playground sandbox, and see what happens. JA: プレイグラウンドサンドボックス内の |+| TiDBサーバーインスタンスを停止して、何が起こるかを確認します。 EN: |+| Two simple client programs are running at the same time. JA: |+|2つのシンプルなクライアントプログラムが同時に実行されています。 EN: |+| One programs keeps inserting new planets into planets table and the |+| other one is querying on the same table. JA: |+|あるプログラムは、惑星テーブルに新しい惑星を挿入し続けており、|+| もう一つのプログラムは同じテーブルでクエリを実行しています。 EN: Both application implements |+| the basic reconnect and a simple transaction recommit mechanism in case of connection loss. JA: アプリケーションの両方がコネクションの喪失に備えて |+| 基本的な再接続と単純なトランザクション再コミット機構を実装しています。 EN: |+| Let's check the status of my playground cluster first. JA: |+|最初に私のプレイグラウンドクラスタの状態を確認します。 EN: |+| Now we have the PID of each instance, my target is the TiDB server instance right now. JA: |+|今、各インスタンスのPIDがあります。ターゲットは今、TiDBサーバーインスタンスです。 EN: |+| Let's spin up our little client programs. JA: |+|私たちの小さなクライアントプログラムを起動します。 EN: |+| The first one is the planet's creator with random planet names. JA: |+|最初のものは、ランダムな惑星名を持つ惑星を作成します。 EN: |+| Then, let's query against the planet table. JA: |+| それでは、planetテーブルにクエリを実行します。 EN: |+| You can see the new planets are being discovered. JA: |+|新しい惑星が見つかりました。 EN: Now two tiny programs are running. JA: 今、二つの小さなプログラムが実行されています。 EN: |+| Please 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. JA: |+|両方のプログラムは3つのTiDBサーバーインスタンスを認識しており、|+|接続障害の場合は任意のTiDBサービスに接続するように設計されています。 EN: |+| They are written in Python and very straightforward. JA: |+|それらはPythonで書かれており、非常にわかりやすいです。 EN: |+| You can go through the code if you like |+| Let me kill one TiDB instance. JA: |+|コードを見ることもできます。|+|私はTiDBの1つのインスタンスを停止します。 EN: |+| Both programs encountered exceptions and they did not give up easily. JA: |+|両方のプログラムは例外に遭遇しましたが、簡単には諦めませんでした。 EN: |+| Within a short time, they can reconnect to another TiDB server and continue their tasks. JA: |+|短時間のうちに、彼らは別のTiDBサーバーに再接続して、タスクを継続することができます。 EN: |+| Let me kill one more TiDB instance. JA: |+|もう1つのTiDBインスタンスを停止します。 EN: |+| As you can see the failover happens again |+| Let me kill the last TiDB instance. JA: |+|フェイルオーバーが再度発生していることがわかりました。|+| 最後のTiDBインスタンスを停止します。 EN: There will be no TiDB server after |+| this kill operation. JA: この停止操作後、TiDBサーバーは存在しなくなります。 |+| EN: As I only have three TiDB server instance. JA: TiDBサーバーのインスタンスが3つしかないためです。 EN: |+| You can see now my programs have no TiDB server to talk to. JA: |+| 今、私のプログラムには話すTiDBサーバーがないことがわかります。 EN: |+| My business is literally paused. JA: |+|私のビジネスは文字通り停止しています。 EN: What can I do now? JA: 今、私に何ができますか。 EN: Do I lost any data? JA: データを失っていませんでしたか。 EN: No, |+| because the TiDB server is stateless. JA: いいえ、|+| なぜならTiDBサーバーは状態を持っていないからです。 EN: What I should do is add TiDB servers back to the cluster |+| to fit my business requirements. JA: 私がすべきことは、TiDBサーバーをクラスタに再追加して、|+| 私のビジネス要件に合わせることです。 EN: For my dummy business here, actually one TiDB server is enough. JA: この架空のビジネスの場合、実際には1つのTiDBサーバーで十分です。 EN: |+| So I am going to add one TiDB server instance. JA: |+|だから、私はTiDBサーバーのインスタンスを1つ追加するつもりです。 EN: |+| This operation is actually a scaling out operation. JA: |+| この操作は実際にはスケーリングアウト操作です。 EN: |+| I can do that with very intuitive command line. JA: |+| とても直感的なコマンドラインでそれができます。 EN: Let me run it now. JA: 今すぐ実行してみます。 EN: |+| Everything is back to normal. JA: |+|すべてが元に戻りました。 EN: I lost three old TiDB instances, |+| and then one new TiDB instance joined the cluster. JA: 私は古いTiDBインスタンスを3つ失いました。|+| そして、新しい一つのTiDBインスタンスがクラスタに参加しました。 EN: |+| No data is lost in this simple demo. JA: |+|このシンプルなデモでは、データは失われません。 EN: |+| I added TiDB instance back manually. JA: |+|TiDBのインスタンスを手動で追加しました。 EN: In production, |+| you don't have to do this manually. JA: 本番環境では、|+| 手動でこれを行う必要はありません。 EN: You have multiple options to do it in an automatic way. JA: 自動的に行うための複数のオプションがあります。 EN: |+| If you are in TiDB Cloud, it will be even more convenient. JA: |+|もしTiDB Cloudを利用している場合、さらに簡単になります。