1
00:00:00,000 --> 00:00:08,740
[音楽]

2
00:00:08,740 --> 00:00:10,740
TiDBサーバーを簡単に紹介しました

3
00:00:10,740 --> 00:00:14,760
私たちは、そのサーバーモジュールとステートレス性を紹介しました。

4
00:00:15,480 --> 00:00:19,020
さて、次はTiKVクラスタのアーキテクチャに進みましょう。

5
00:00:19,020 --> 00:00:22,440
キーと値のペアのドメインを少し深く掘り下げてみましょう。

6
00:00:23,340 --> 00:00:26,340
私たちはすでに TiKV がキーバリューモデルであることを学びました。

7
00:00:27,060 --> 00:00:29,340
TiKVは順序付けトラバース方法を提供しています。

8
00:00:30,180 --> 00:00:35,280
キーと値のペアは、キーのバイナリ順に従って順序付けられるため、

9
00:00:35,280 --> 00:00:39,840
キーの位置を検索して、NEXT()メソッドを連続して呼び出すことで、

10
00:00:39,840 --> 00:00:41,820
増加する順序でより大きなキーを取得できます。

11
00:00:42,960 --> 00:00:47,760
水平スケーリングを実装するために、ストレージデータは複数の

12
00:00:47,760 --> 00:00:48,120
ノードに分散されます。

13
00:00:49,560 --> 00:00:54,240
TiKVは全体のKVスペースを、キーの範囲に応じた多数のセグメントに分割します。

14
00:00:54,780 --> 00:00:58,140
各セグメントは連続したキーのシリーズです。

15
00:00:59,400 --> 00:01:01,380
一つのリージョンには、複数のセグメントがあります。

16
00:01:01,380 --> 00:01:05,400
1つのリージョンのデフォルトサイズは96メガバイトです。

17
00:01:06,660 --> 00:01:12,600
各リージョンは、左側が閉じていて右側が開いた区間で、

18
00:01:12,600 --> 00:01:13,560
開始キーと終了キーで記述されます。

19
00:01:14,640 --> 00:01:16,980
リージョンはまた、レプリケーションの単位でもあります。

20
00:01:16,980 --> 00:01:20,100
各リージョンには、固有のRaftレプリケーショングループがあります。

21
00:01:20,700 --> 00:01:23,400
スライドに表示されているリージョン1と同様です。

22
00:01:25,080 --> 00:01:27,720
各リージョンには、固有のLeaderノードとFollowerノードがあります。

23
00:01:27,720 --> 00:01:30,180
Raftは分散合意プロトコルです。

24
00:01:31,140 --> 00:01:36,240
Raftは、Leader選出やメンバー変更のような重要な機能を

25
00:01:36,240 --> 00:01:36,600
提供します。

26
00:01:38,100 --> 00:01:43,980
Raftは具体的にはレプリカの追加、レプリカの削除、Leadersの移行、

27
00:01:43,980 --> 00:01:46,380
ログのレプリケーションなどを担当しています。

28
00:01:47,880 --> 00:01:52,545
TiKVがRaftデータレプリケーションを使用するとき、変更されたデータはすべてRaftログに配置されます。

29
00:01:52,545 --> 00:01:59,220
Raftログレプリケーション機能に従い、データは安全かつ信頼性の高い方法で、

30
00:01:59,220 --> 00:02:01,620
各レプリケーショングループのノードに同期化されます。

31
00:02:02,460 --> 00:02:07,380
Raftプロトコルでは、Raftグループ内の過半数のノードに同期的にレプリケーションするだけで

32
00:02:07,380 --> 00:02:12,600
データが正常に書き込まれたことを安全に確認できます。

33
00:02:13,160 --> 00:02:19,680
TiKVはデータを直接ディスクに書き込まず、データを保管するためにRocksDBを使用し、

34
00:02:19,680 --> 00:02:21,900
RocksDBがデータの配置を担当しています。

35
00:02:21,900 --> 00:02:26,100
RocksDBは、FacebookによってオープンソースでリリースされたシングルインスタンスのKVストレージエンジンです。

36
00:02:27,180 --> 00:02:29,940
元々はGoogle LevelDBからフォークされたものです。

37
00:02:31,080 --> 00:02:36,060
RocksDBは単一のインスタンスの永続エンジンとして、TiKVの様々な要件を満たすことができます。

38
00:02:37,380 --> 00:02:42,720
リージョンごとにデータを分散・複製することで、TiKVは分散型のキーバリューシステムとなり、

39
00:02:42,720 --> 00:02:48,660
過半数のTiKVノードが稼働している限り、確かな災害復旧能力を持つようになりました。

40
00:02:49,620 --> 00:02:53,520
どんな少数ノードの障害でも、データの整合性は崩れません。

41
00:02:54,060 --> 00:02:55,740
今回のデモの時間です。

42
00:02:55,740 --> 00:03:00,180
私はプレイグラウンドのTiKVサーバーインスタンスを停止して、何が起こるか見てみます。

43
00:03:01,260 --> 00:03:03,300
プレイグラウンドの状態をチェックします。

44
00:03:11,580 --> 00:03:14,940
今回のターゲットは TiKV インスタンスです。

45
00:03:16,500 --> 00:03:19,740
私のシンプルなアプリケーションはまだ動作していることに注意してください。

46
00:03:20,760 --> 00:03:24,180
ただお知らせしておきますが、私のシンプルなアプリケーションには2つのロールがあります。

47
00:03:24,180 --> 00:03:29,940
片方はランダムに生成された惑星データを惑星テーブルに挿入し続け、

48
00:03:29,940 --> 00:03:32,640
他方はデータを読み取って単純な計算を行います。

49
00:03:33,600 --> 00:03:37,740
シンプルなアプリケーションの詳細は、前回の講義で見つけることができます。

50
00:03:39,000 --> 00:03:40,860
TiKVのインスタンスを1つ停止します。

51
00:03:56,040 --> 00:03:58,800
アプリケーション側からは何も起こらなかったように見えます。

52
00:03:59,520 --> 00:04:04,860
この結果に基づくと、1つの TiKV ノードを停止することは私のアプリケーションに影響がないと言えます。

53
00:04:06,120 --> 00:04:08,880
この挙動は2つの事実に基づいています。

54
00:04:08,880 --> 00:04:15,480
最初に、私の例では読み取りレプリカのデフォルトカウントは3であり、1つのTiKVノードがなくなり、

55
00:04:15,480 --> 00:04:16,740
2つがまだ生きています。

56
00:04:16,740 --> 00:04:19,080
したがって、過半数は依然として生きています。

57
00:04:19,980 --> 00:04:24,900
Raftプロトコルに従って、新しく選ばれたLeaderかどうかに関わらず、Leaderはそこにあります。

58
00:04:24,900 --> 00:04:29,040
Leaderが動作しているため、システムは読み取りと書き込みが可能です。

59
00:04:29,700 --> 00:04:34,560
第二に、TiDBサーバが、クライアントアプリケーション

60
00:04:34,560 --> 00:04:36,300
とTiKVサーバー間の通信を分離しています。

61
00:04:36,300 --> 00:04:38,580
SQL レイヤーは、実際にはフロントエンドアプリケーションに対して

62
00:04:38,580 --> 00:04:41,640
TiKV ノードの障害を隠蔽します。

63
00:04:42,780 --> 00:04:48,180
しかしながら、運用の観点から言えば、もしプロダクション環境であれば、

64
00:04:48,180 --> 00:04:54,000
すでにバックエンドの不運な変更に関するアラームを受け取ったはずです。

65
00:04:54,000 --> 00:04:54,120
つまり、1つのTiKVノードがダウンしたことを意味します。

66
00:04:54,900 --> 00:04:58,140
自動化するか、手動で対応するかを設定できます。

67
00:04:58,140 --> 00:05:01,620
最も重要なことは、あなたのアプリケーションに何も感じさせないことです。

68
00:05:02,580 --> 00:05:08,520
TiDBインスタンスの場合と同様に、追加で一つのTiKVインスタンスを

69
00:05:08,520 --> 00:05:08,760
停止するつもりはありません。

70
00:05:09,480 --> 00:05:13,020
これを行うと、Raftプロトコルの過半数ルールが破れてしまうためです。

71
00:05:13,020 --> 00:05:16,500
このクラスタを回復するには、データベース操作スキルが必要です。

72
00:05:17,160 --> 00:05:19,260
TiKVクラスタは状態を持つことを覚えておいてください。

73
00:05:19,260 --> 00:05:24,720
データベース運用学習コースの中の、

74
00:05:24,720 --> 00:05:25,440
TiDBの管理コースでTiKVクラスタの回復スキルをカバーします。

75
00:05:26,820 --> 00:05:30,900
教育ポータルのウェブサイトでトレーニングカタログの詳細について確認してください。

76
00:05:32,100 --> 00:05:34,440
Raftプロトコルから1つ上のレベルに上がりましょう。

77
00:05:34,440 --> 00:05:38,460
MVCC、即ちマルチバージョン同時実行制御について話します。

78
00:05:40,020 --> 00:05:42,900
バージョン番号はTimestamp Oracleから取得されます。

79
00:05:42,900 --> 00:05:48,000
行またはキーの値ペアが更新されると、古いエントリと新しいエントリの両方が

80
00:05:48,000 --> 00:05:48,240
TiKVに格納されます。

81
00:05:49,440 --> 00:05:53,100
基本的には、キーの後にバージョン番号を追加することで実装されています。

82
00:05:54,000 --> 00:06:00,180
以前のバージョンのエントリーを利用することで、フラッシュバッククエリ、フラッシュバック

83
00:06:00,180 --> 00:06:03,360
テーブルなどのさまざまなシナリオをサポートでき、最も重要なことに、並行操作を行うことができます。

84
00:06:04,560 --> 00:06:09,000
同じキーの値を更新する2つのセッションがほぼ同時にあると想像します。

85
00:06:10,020 --> 00:06:15,480
Timestamp Oracle、略してTSOに関しては、同時という概念は存在しないことに注意します。

86
00:06:16,560 --> 00:06:19,500
異なる2つの変更には常に異なるバージョン番号があります。

87
00:06:20,520 --> 00:06:23,940
しかし、SQLレイヤーでのTiDBは、

88
00:06:23,940 --> 00:06:27,120
悲観的および楽観的なトランザクションロックを実装する柔軟性を

89
00:06:27,120 --> 00:06:27,960
まだ持っています。

90
00:06:29,040 --> 00:06:32,640
TiDB 固有機能コースで、これら2つのロックについて説明します。

91
00:06:33,900 --> 00:06:39,540
TiKVが提供するもう一つの重要な機能は、オペレータのプッシュダウンと分散SQLです。

92
00:06:41,520 --> 00:06:46,200
並列実行の性質のため、クエリのパフォーマンスを向上させることができます。

93
00:06:48,480 --> 00:06:53,460
前述のように、TiKVノードは分散SQLのための実行部隊となります。

94
00:06:54,240 --> 00:06:59,520
スライドに示されているように、クエリはカテゴリー 1 に属する全ての惑星から数を

95
00:06:59,520 --> 00:07:00,120
取得する必要があります。

96
00:07:00,120 --> 00:07:06,240
TiDB サーバーと TiKV サーバーの間の多数の RPC 呼び出しを避けるため、

97
00:07:06,240 --> 00:07:12,000
カテゴリ ID が 1 である場合、というクエリ内の述語条件が、

98
00:07:12,000 --> 00:07:12,600
ストレージノードにプッシュダウンされて処理されます。

99
00:07:13,440 --> 00:07:18,060
その上で、集計関数のcountもストレージノードにプッシュダウンして、

100
00:07:18,060 --> 00:07:19,080
事前集計を行うことができます。

101
00:07:20,040 --> 00:07:23,400
従って、各TiKVノードは1つのカウントのみを返すだけで済みます。

102
00:07:24,420 --> 00:07:29,940
その後、合計数は TiDB サーバーである SQL レイヤーによって集計されるため、

103
00:07:29,940 --> 00:07:34,320
有効な行のみが返され、無意味なネットワーク転送が回避されます。

104
00:07:36,000 --> 00:07:40,140
今度は、TiDBのアーキテクチャを従来のデータベースと比較してみましょう。

105
00:07:40,140 --> 00:07:46,380
TiDBと多くの伝統的なモノリシックまたは非分散型のデータベースは、

106
00:07:46,380 --> 00:07:47,940
ACIDと強い一貫性をサポートしています。

107
00:07:48,720 --> 00:07:51,300
しかし、TiDBには分散アーキテクチャがあります。

108
00:07:51,300 --> 00:07:55,920
SQLレイヤー、ストレージレイヤー、管理レイヤーを分離します。

109
00:07:56,700 --> 00:08:01,980
したがって、TiDBは弾力的にスケーリング・インとスケーリング・アウトを行うことができ、

110
00:08:01,980 --> 00:08:02,340
またあなたの業務への影響はほぼゼロです。

111
00:08:02,340 --> 00:08:03,180
TiDBも高い可用性があります。

112
00:08:03,180 --> 00:08:04,980
自動フェイルオーバーをサポートしています。

113
00:08:06,420 --> 00:08:09,840
数個のレプリカの障害は、あなたのビジネスにとって完全に透過的です。

114
00:08:10,920 --> 00:08:13,140
TiDBのスケーリングも非常に便利です。

115
00:08:13,140 --> 00:08:17,280
あなたのビジネスロジックを変更する必要はありませんし、シャーディングキーを追加する必要もありません。

116
00:08:17,280 --> 00:08:21,420
TiDBは、高い同時実行の状況に対処するように設計されています。

117
00:08:21,420 --> 00:08:26,340
従来のデータベースに比べて、より多くの同時読み書きリクエストを処理できます。

118
00:08:28,320 --> 00:08:31,800
伝統的なデータベースにも、スケールアウトの試みがあります。

119
00:08:32,400 --> 00:08:37,320
このスライドは、その試みの1つを示しています：複数ノード共有ストレージアーキテクチャ。

120
00:08:38,280 --> 00:08:42,960
このアーキテクチャの高レベルのアイデアは、既存のハードウェアを組み合わせて、

121
00:08:42,960 --> 00:08:45,060
より優れたハードウェアのように振る舞うことです。

122
00:08:45,900 --> 00:08:47,520
これは実際にはスケールアウトではありません。

123
00:08:47,520 --> 00:08:49,980
依然としてスケールアップの手段です。

124
00:08:50,940 --> 00:08:56,040
しかしながら、クラスタに構成されたノードの数に関わらず、データは共有ストレージに保存され、

125
00:08:56,040 --> 00:09:00,540
ミドルウェアのハートビートが、メモリレベルのバッファキャッシュを伝送するための責任を負っており、

126
00:09:00,540 --> 00:09:03,600
これが明らかなボトルネックとなっています。

127
00:09:03,600 --> 00:09:09,120
この解決策には、ネットワーク接続などの特殊ハードウェアが必要なため、

128
00:09:09,120 --> 00:09:10,620
非常に高価です。

129
00:09:12,360 --> 00:09:15,000
もう一つのより一般的な方法はシャーディングを使用することです。

130
00:09:15,600 --> 00:09:20,460
シャードキーに従って、複数の従来型データベースにデータが格納されます。

131
00:09:21,120 --> 00:09:25,200
実際の世界では、データベースのシャードが50以上あることは珍しいことではありません。

132
00:09:26,880 --> 00:09:31,860
このようにすると、データベース管理システムは、クロスシャーディングトランザクションにACIDプロパティを

133
00:09:31,860 --> 00:09:33,300
提供できなくなります。

134
00:09:34,440 --> 00:09:39,540
アプリケーションは、クロスシャーディングトランザクションのためにACIDロジックを自分で実装する必要があります。

135
00:09:40,560 --> 00:09:43,320
運用と管理にとっては悪夢です。