1
00:00:07,980 --> 00:00:13,980
今からSQLレイヤーとしても知られるTiDBサーバーのクラスタを見てみます。

2
00:00:14,640 --> 00:00:17,640
このレイヤーのおかげで、TiDBはSQL文を理解できます。

3
00:00:18,420 --> 00:00:23,100
SQLレイヤーの最も重要な機能の一つは、リレーショナルデータベースドメインのテーブル行と

4
00:00:23,100 --> 00:00:28,680
KVドメインのキー・バリューペアとのマッピングを管理することです。

5
00:00:29,460 --> 00:00:34,260
ここでは、マッピングの動作について説明します。TiDBはテーブルにテーブルIDを割り当てます。

6
00:00:34,920 --> 00:00:38,820
テーブルIDは、クラスタ全体でユニークな整数です。

7
00:00:40,320 --> 00:00:46,800
TiDBは各行に行IDを割り当てます。テーブル内でユニークな行IDも整数です。

8
00:00:47,400 --> 00:00:52,380
スライドの左側に、3つの行があり、それぞれが4つのカラムで構成されています。

9
00:00:52,380 --> 00:00:57,180
最初のカラムは、テーブルのプライマリキーです。KVドメインは

10
00:00:57,180 --> 00:01:03,960
右側にあります。キーは赤で表示されます。値は角かっこで囲まれています。

11
00:01:05,160 --> 00:01:09,960
また、行IDについては、TiDBサーバーが小さな最適化を行っており、

12
00:01:10,620 --> 00:01:15,480
それは、テーブルの主キーカラムが整数データ型である場合、

13
00:01:15,480 --> 00:01:23,040
SQLレイヤーは主キーをそのまま行IDとして使用し、KVレコードのキーを構成します。

14
00:01:24,360 --> 00:01:30,420
これは、スライドに示されたケースとまさに同じです。一方、主キーカラムが非整数のデータ型である場合、SQLレイヤーはキーのために

15
00:01:30,420 --> 00:01:37,140
行IDを生成およびエンコードし、KVレコードに格納します。

16
00:01:38,340 --> 00:01:43,140
TiDBの特徴機能およびトランザクション制御内の別のコース、

17
00:01:43,140 --> 00:01:48,120
「クラスタ化されたインデックスセクション」で、行IDに関するより詳しい詳細について説明します。

18
00:01:49,920 --> 00:01:54,600
行IDはユニーク取得またはポイント取得クエリで効果的に使用されます。

19
00:01:55,500 --> 00:02:01,200
テーブルプレフィックスは、フルテーブルスキャンで使用することができます。TiKV マップの観点からは、

20
00:02:01,200 --> 00:02:06,660
リレーショナル領域でのフルテーブルスキャンは実際にはKV領域でのレンジスキャンです。

21
00:02:08,340 --> 00:02:12,420
今度は、1つのTiKVサーバーに深く入り込んで、

22
00:02:12,420 --> 00:02:16,740
TiDBサーバーにあるモジュールとそれに関連する機能を見てみましょう。

23
00:02:17,880 --> 00:02:23,400
ネットワーク越しにクライアントがSQL文を発行したと仮定します。フロントエンドが要求を

24
00:02:23,400 --> 00:02:29,640
処理するのはプロトコルレイヤーです。プロトコルレイヤーにより、TiDBサーバーが実際にネットワークサーバーになります。

25
00:02:30,420 --> 00:02:34,620
認証が完了した後、セッションのコンテキスト段階に到達します。

26
00:02:35,340 --> 00:02:39,720
セッションコンテキストを取得した後、リクエストは解析段階に入ります。

27
00:02:40,860 --> 00:02:44,940
パーサーはSQL文を論理ツリー構造として扱い、

28
00:02:44,940 --> 00:02:49,860
アクセスしたいデータベースオブジェクトと、

29
00:02:49,860 --> 00:02:55,020
これらのオブジェクトに対して行いたい操作などの意図を解析します。

30
00:02:56,220 --> 00:03:02,460
その後、ルールベースのオプティマイザである論理オプティマイザに送信されます。論理オプティマイザは、

31
00:03:02,460 --> 00:03:07,500
一連のルールに従ってあなたのSQL文を適切な形に書き換える可能性があります。

32
00:03:08,160 --> 00:03:11,880
これは、次のステップでより良い実行計画を生成するのに役立つ可能性があります。

33
00:03:13,440 --> 00:03:15,960
出力は論理的な実行計画です。

34
00:03:17,340 --> 00:03:22,440
その後、コストベースのオプティマイザである物理オプティマイザに送信されます。

35
00:03:23,040 --> 00:03:26,640
物理オプティマイザは、SQL文に必要なオブジェクトの統計など、

36
00:03:26,640 --> 00:03:32,280
他の重要な情報も認識しています。

37
00:03:33,840 --> 00:03:37,080
例えば、テーブルに含まれる行数、各行の平均長、

38
00:03:37,080 --> 00:03:42,060
およびインデックスの情報を含む場合があります。

39
00:03:43,080 --> 00:03:48,000
このような統計は、物理オプティマイザによるより良い実行計画を得るのに役立ちますが、

40
00:03:48,000 --> 00:03:50,940
論理最適化ではそれができません。

41
00:03:52,380 --> 00:03:55,560
これで物理的な実行計画を手に入れたので、

42
00:03:55,560 --> 00:04:00,000
それをローカルおよび分散実行エグゼキュータに渡して実行できます。

43
00:04:01,320 --> 00:04:03,600
もう一つ注意すべきことは、

44
00:04:03,600 --> 00:04:07,740
クライアントは同時に1つのTiDBサーバーインスタンスにしか接続できないということです。

45
00:04:08,280 --> 00:04:13,740
つまり、クライアントセッションとTiDBサーバーインスタンスの関係は1対1であるということです。

46
00:04:14,880 --> 00:04:18,900
ローカル実行は、セッションが接続されているTiDB

47
00:04:18,900 --> 00:04:21,780
サーバーインスタンス上でタスクが実行されることを意味します。

48
00:04:23,100 --> 00:04:26,220
分散実行とは、分散SQL命令がTiKVサーバーに送信され、

49
00:04:26,220 --> 00:04:29,880
実行されることを意味します。

50
00:04:31,260 --> 00:04:36,900
バックエンドには多数のTiKVサーバーがある可能性があることはすでに知っています。したがって、

51
00:04:36,900 --> 00:04:41,880
複数のTiKVサーバーが分散SQL命令を受信し、並列実行を行う可能性があります。

52
00:04:44,100 --> 00:04:48,240
「TiDB パフォーマンスチューニング」というコースがあります。このコースでは、SQL チューニング、

53
00:04:48,240 --> 00:04:53,160
クエリオプティマイザ、および分散 SQL を含むトピックを扱っています。

54
00:04:54,480 --> 00:04:57,840
もしTiDBのパフォーマンスチューニングに興味がある場合は、

55
00:04:57,840 --> 00:05:00,180
このコースに登録することを強くお勧めします。

56
00:05:02,160 --> 00:05:07,020
一つの疑問として、クライアントセッションが常に1つのTiDBサーバーにしか接続できないのなら、

57
00:05:07,020 --> 00:05:13,200
このTiDBノードがダウンしている場合、どうなるのでしょうか。この場合、クライアントアプリケーションは何をすべきですか。

58
00:05:14,100 --> 00:05:18,600
実際の答えは非常に簡単です。TiDBサーバーは状態を持ちません、すなわち、

59
00:05:18,600 --> 00:05:22,620
TiDBサーバーノードにビジネスデータが保存されていないことを意味します。したがって、

60
00:05:23,460 --> 00:05:29,280
TiDBサーバーがダウンした場合は、単に再接続して、正常なTiDBサーバーにセッションを再作成すればよいです。

61
00:05:30,300 --> 00:05:32,880
再接続前後に、未完了のトランザクションを処理できるように、

62
00:05:32,880 --> 00:05:36,960
クライアントセッションを設定する必要があります。

63
00:05:37,620 --> 00:05:40,260
トランザクション処理に関する話題を扱ったコースがあります。

64
00:05:42,120 --> 00:05:47,580
次に、例を示します。プレイグラウンドサンドボックス内の

65
00:05:47,580 --> 00:05:50,340
TiDBサーバーインスタンスを停止して、何が起こるかを確認します。

66
00:05:51,240 --> 00:05:54,120
2つのシンプルなクライアントプログラムが同時に実行されています。

67
00:05:54,840 --> 00:05:59,940
あるプログラムは、惑星テーブルに新しい惑星を挿入し続けており、

68
00:05:59,940 --> 00:06:04,740
もう一つのプログラムは同じテーブルでクエリを実行しています。アプリケーションの両方がコネクションの喪失に備えて

69
00:06:04,740 --> 00:06:10,740
基本的な再接続と単純なトランザクション再コミット機構を実装しています。

70
00:06:12,300 --> 00:06:15,060
最初に私のプレイグラウンドクラスタの状態を確認します。

71
00:06:16,200 --> 00:06:22,380
今、各インスタンスのPIDがあります。ターゲットは今、TiDBサーバーインスタンスです。

72
00:06:23,520 --> 00:06:25,920
私たちの小さなクライアントプログラムを起動します。

73
00:06:26,940 --> 00:06:30,540
最初のものは、ランダムな惑星名を持つ惑星を作成します。

74
00:06:34,140 --> 00:06:36,480
それでは、planetテーブルにクエリを実行します。

75
00:06:41,400 --> 00:06:47,820
新しい惑星が見つかりました。今、二つの小さなプログラムが実行されています。

76
00:06:48,660 --> 00:06:52,800
両方のプログラムは3つのTiDBサーバーインスタンスを認識しており、

77
00:06:53,340 --> 00:06:57,720
接続障害の場合は任意のTiDBサービスに接続するように設計されています。

78
00:07:01,680 --> 00:07:05,100
それらはPythonで書かれており、非常にわかりやすいです。

79
00:07:06,000 --> 00:07:07,740
コードを見ることもできます。

80
00:07:10,680 --> 00:07:12,660
私はTiDBの1つのインスタンスを停止します。

81
00:07:25,620 --> 00:07:30,420
両方のプログラムは例外に遭遇しましたが、簡単には諦めませんでした。

82
00:07:34,980 --> 00:07:40,860
短時間のうちに、彼らは別のTiDBサーバーに再接続して、タスクを継続することができます。

83
00:07:48,600 --> 00:07:50,940
もう1つのTiDBインスタンスを停止します。

84
00:07:59,760 --> 00:08:02,220
フェイルオーバーが再度発生していることがわかりました。

85
00:08:09,660 --> 00:08:14,700
最後のTiDBインスタンスを停止します。この停止操作後、TiDBサーバーは

86
00:08:14,700 --> 00:08:18,420
存在しなくなります。TiDBサーバーのインスタンスが3つしかないためです。

87
00:08:23,940 --> 00:08:27,780
今、私のプログラムには話すTiDBサーバーがないことがわかります。

88
00:08:29,460 --> 00:08:36,300
私のビジネスは文字通り停止しています。今、私に何ができますか。データを失っていませんでしたか。いいえ、

89
00:08:36,300 --> 00:08:42,660
なぜならTiDBサーバーは状態を持っていないからです。私がすべきことは、TiDBサーバーをクラスタに再追加して、

90
00:08:42,660 --> 00:08:51,180
私のビジネス要件に合わせることです。この架空のビジネスの場合、実際には1つのTiDBサーバーで十分です。

91
00:08:53,460 --> 00:08:56,100
だから、私はTiDBサーバーのインスタンスを1つ追加するつもりです。

92
00:08:56,640 --> 00:08:59,820
この操作は実際にはスケーリングアウト操作です。

93
00:09:01,200 --> 00:09:06,480
とても直感的なコマンドラインでそれができます。今すぐ実行してみます。

94
00:09:30,000 --> 00:09:34,260
すべてが元に戻りました。私は古いTiDBインスタンスを3つ失いました。

95
00:09:34,260 --> 00:09:37,320
そして、新しい一つのTiDBインスタンスがクラスタに参加しました。

96
00:09:38,100 --> 00:09:40,740
このシンプルなデモでは、データは失われません。

97
00:09:41,820 --> 00:09:46,020
TiDBのインスタンスを手動で追加しました。本番環境では、

98
00:09:46,020 --> 00:09:51,300
手動でこれを行う必要はありません。自動的に行うための複数のオプションがあります。

99
00:09:52,080 --> 00:09:55,440
もしTiDB Cloudを利用している場合、さらに簡単になります。