1
00:00:08,640 --> 00:00:14,700
ようこそDBAのためのTiDB基礎コースへ、これはモジュール1

2
00:00:14,700 --> 00:00:20,100
TiDBデータベースアーキテクチャ概要です。
私の名前はジェフで、私はあなたの講師です。このモジュールを完了すると、

3
00:00:20,820 --> 00:00:27,000
TiDBデータベースの全体的なアーキテクチャを理解し、

4
00:00:27,000 --> 00:00:34,800
TiDBサーバー、TiKV、PDの主な機能を説明できるようになります。始める前に、

5
00:00:34,800 --> 00:00:41,340
TiDB と言ったときに2つの意味があることを知っておく必要があります。
TiDB は最初にデータベース自体であり、

6
00:00:41,340 --> 00:00:47,580
そしてTiDBデータベース内にTiDBコンポーネントがあります。

7
00:00:48,240 --> 00:00:54,360
一度理解したら、問題が起きないはずです。
TiDB アーキテクチャに進みましょう。

8
00:00:56,040 --> 00:01:01,740
TiDBは、オンライントランザクション処理とオンライン分析処理の

9
00:01:01,740 --> 00:01:07,740
両方をサポートする分散リレーショナルデータベースです。
データベースがOLTPとOLAPの両方のユースケースをサポートするものは、

10
00:01:07,740 --> 00:01:13,020
ハイブリッド・トランザクショナル・アナリティカル・データベース
（HTAPデータベース）としても知られています。

11
00:01:13,740 --> 00:01:19,800
TiDBは、水平スケールアウトとスケールイン、金融グレードの高い可用性、

12
00:01:20,580 --> 00:01:27,840
リアルタイムHTAP、およびクラウドネイティブの
分散サポートを提供します。さらに、

13
00:01:27,840 --> 00:01:37,140
TiDBはMySQL 5.7クライアントプロトコルと互換性があり、
MySQLエコシステムとも互換性があります。

14
00:01:37,140 --> 00:01:46,380
TiDBデータベースの三つのコンポーネントは、PDクラスタ、
TiDBサーバー、およびTiKVです。PDクラスタは、

15
00:01:46,380 --> 00:01:52,980
TiDBデータベースの全体の制御センターであり、
それをデータベースの頭脳と考えてください。

16
00:01:52,980 --> 00:02:00,300
TiKVノードのリージョンの分散をスケジューリングし、
TiKVノードの健康状態と分散状態を収集し、

17
00:02:00,300 --> 00:02:07,260
Global Timestamp Oracleタイムスタンプを生成し、
分散トランザクションにトランザクションIDを割り当てる責任があります。

18
00:02:07,260 --> 00:02:13,620
PD自体も少なくとも3つのノードから構成されており、
高い可用性を持っています。

19
00:02:13,620 --> 00:02:19,500
奇数個のPDノードをデプロイすることをお勧めします。

20
00:02:20,940 --> 00:02:27,240
TiDBサーバー、これは私が先ほど言及したコンポーネントで、
クライアントの接続を割り当てる責任があります。

21
00:02:27,240 --> 00:02:33,660
言い換えると、TiDBデータベースに接続するとき、
クライアントはTiDBサーバーコンポーネントに接続します。

22
00:02:33,660 --> 00:02:40,980
TiDBサーバーは、クライアント接続、SQL文の解析、
SQL文のコンパイル、実行計画の生成、

23
00:02:40,980 --> 00:02:46,860
およびクライアントアプリケーションへの結果の返却の責任を持ちます。

24
00:02:46,860 --> 00:02:52,440
データベースがクエリを実行するためのステップとして、
実行計画があります。

25
00:02:53,340 --> 00:03:01,080
TiDBがどこにデータを保存するのか、疑問があるかもしれません。 

26
00:03:01,080 --> 00:03:07,560
それは素晴らしい質問です、OLTPデータはキー・バリュー・ペアの形でTiKVクラスタに保存されます。

27
00:03:07,560 --> 00:03:13,140
TiKVクラスタは、データの永続性、並行性制御、
ストレージレベルでのデータフィルタリングによりクエリの

28
00:03:13,140 --> 00:03:19,500
実行が高速化され、高可用性、およびデータの一貫性を確保する責任を担っています。

29
00:03:19,500 --> 00:03:27,720
TiKVモジュールでどのようにこれを行うかを説明します。
TiDBサーバーレイヤーはステートレスであり、

30
00:03:27,720 --> 00:03:33,060
実際には複数のTiDBサーバーインスタンスを実行します。

31
00:03:33,060 --> 00:03:39,660
それぞれのインスタンスには、ユーザーが接続するために使用できる
独自のIPアドレスがありますが、

32
00:03:39,660 --> 00:03:48,480
実際にはこのような方法ではありません。LVS、HAプロキシ、
F5などのロードバランサーを介して外部世界に1つのIPアドレスを提供したいと考えています。

33
00:03:48,480 --> 00:03:55,740
ロードバランサーを使用することで、クライアントの
接続を複数のTiDBサーバーインスタンスに均一に分散できます。

34
00:03:55,740 --> 00:04:03,060
TiFlashは、TiDBにOLAP機能を提供するカラムストレージエンジンです。

35
00:04:03,060 --> 00:04:09,360
TiKV はデータの主要な保存場所です。
TiKVは、Raft分散合意アルゴリズムを使用してTiFlashとデータを同期し、

36
00:04:09,360 --> 00:04:17,040
これによりロードバランシングと強力な一貫性のある読み取りを確保します。
TiFlashはリアルタイムの更新もサポートしています。

37
00:04:17,040 --> 00:04:26,220
TiKVとTiFlashの組み合わせが、TiDBをHTAPデータベースにするものです。次に、

38
00:04:26,220 --> 00:04:33,000
TiDB、TiKV、TiFlash、PDの主要な機能実装原則と特徴について議論します。

39
00:04:34,920 --> 00:04:40,560
TiDBサーバーの主要な機能と実装原則を詳しく見てみましょう。

40
00:04:40,560 --> 00:04:46,920
TiDBサーバー自体は、SQLコンピューティングエンジンにのみ責任があり、
データを保存しないため、TiDBサーバーはステートレスです。

41
00:04:46,920 --> 00:04:54,240
システムが多数の同時接続に直面している場合、
TiDBサーバーインスタンスを追加して負荷分散を実装し、

42
00:04:54,240 --> 00:05:00,300
同時処理能力を向上させることができます。

43
00:05:01,740 --> 00:05:08,100
まず見るべきことは、クライアント接続の取り扱いです。

44
00:05:08,100 --> 00:05:14,160
ユーザーはユーザー名とパスワードによって認証され、
接続されたユーザーは権限を与えられます。

45
00:05:14,160 --> 00:05:20,460
つまり、データベースに問い合わせることができます。
これらのタスクは主にプロトコルレイヤーモジュールによって行われます。

46
00:05:21,360 --> 00:05:27,420
2番目は、SQL文を解析してコンパイルすることです。
SQL文を受け取った後で。

47
00:05:28,140 --> 00:05:34,200
TiDBサーバーは、コンパイルプロセス中にそれを解析してコンパイルし、

48
00:05:34,200 --> 00:05:39,720
最適化して実行計画を生成することを行います。これらのタスクは、
パース と コンパイル モジュールによって行われます。

49
00:05:41,340 --> 00:05:49,020
関係データとKVデータの変換。
TiKVではデータがキー・バリュー・ペアの形式で格納されるため、

50
00:05:49,020 --> 00:05:53,820
リレーショナルデータベースのテーブル、インデックス、
行とキー・バリュー・ペア構造との間に大きな違いがあります。

51
00:05:53,820 --> 00:06:00,960
SQLを実行したい場合は、関係データとKVストレージとの
間を変換できる必要があります。

52
00:06:00,960 --> 00:06:09,720
次に、SQL文の実行です。

53
00:06:09,720 --> 00:06:18,000
コンパイルされた実行計画にしたがって、
それはTiKVでバッチで実行されます。

54
00:06:18,000 --> 00:06:24,960
実行モジュールとDistSQLモジュールによってデータが読み込まれます。
トランザクションに関連する操作は、

55
00:06:24,960 --> 00:06:33,240
トランザクションモジュールとKVモジュールによって完了されます。
オンラインDDLの実行。TiDBデータベースは、

56
00:06:33,240 --> 00:06:39,780
データ定義言語操作がテーブルをロックしないように設計されています。
スキーマロードモジュール、ワーカーモジュール、

57
00:06:39,780 --> 00:06:47,100
およびスタートジョブモジュールによってこれが行われます。
そして最後に、ガベージコレクションです。

58
00:06:47,100 --> 00:06:53,040
ガベージコレクションバックエンドモジュールは、
期限切れの古いバージョンからデータを回復する責任があり、

59
00:06:53,040 --> 00:06:59,640
この部分はTiKVコースで説明されます。
次に、TiKVモジュールを見てみましょう。

60
00:07:02,040 --> 00:07:08,700
TiKVは何度か話しましたが、
OLTPデータである我々の関係データを処理します。

61
00:07:09,600 --> 00:07:16,020
永続的なデータ。 TiKV は、これを実現するために TiDB データベース
に永続的なリレーショナルストレージを提供します。

62
00:07:16,800 --> 00:07:22,680
これを実現するために、PingCAP は RocksDB ストレージエンジンを選択しました。

63
00:07:22,680 --> 00:07:30,120
RocksDBはLSMツリーのデータ構造に基づいています。
TiKV は、RocksDB を永続的なストレージ・エンジンとして使用しています。

64
00:07:30,720 --> 00:07:36,360
RocksDBエンジンは、データが失われないように、
write-ahead logsなどのメカニズムを使用しています。

65
00:07:36,360 --> 00:07:43,920
次の要素である、分散トランザクションサポートについて、TiDBはGoogleが公開した

66
00:07:43,920 --> 00:07:49,020
Percolatorトランザクションモデルをベースにした2フェーズコミットアプローチを使用しています。
Percolatorトランザクションモデルは、

67
00:07:49,020 --> 00:07:56,040
KVノードごとにストレージロックスペースが別々に割り当てられることを保証します。
これはRocksDBカラムファミリーロックを使用します。

68
00:07:56,040 --> 00:08:03,120
これはまた、カラムクラスタと呼ばれます。
このプロセスにおいて、Timestamp OracleとPDも役割を果たします。

69
00:08:03,120 --> 00:08:09,960
TiDBデータベースは、
楽観的ロッキングと悲観的ロッキングの2つのロッキングモードをサポートしています。

70
00:08:09,960 --> 00:08:17,160
次の要素は、レプリカの強い一貫性と高い可用性です。

71
00:08:18,360 --> 00:08:24,420
Raftアルゴリズムでは、データはリージョンに格納され、
各リージョンには3つのレプリカがあります。

72
00:08:24,420 --> 00:08:32,040
デフォルトでは、レプリカのサイズは96メガバイトを超えてはなりません。
レプリカがこのサイズを超えると、

73
00:08:32,040 --> 00:08:37,440
複数のリージョンに分割されます。
これにより、TiDBが動的にスケールできるようになります。

74
00:08:38,460 --> 00:08:47,640
次は、MVCC またはマルチバージョンの同時実行制御です。
MVCC は、高度な並行読み書きに不可欠です。

75
00:08:47,640 --> 00:08:53,340
それは、分散トランザクションや高速データ復旧などの
機能の基礎となるものです。

76
00:08:53,340 --> 00:09:03,060
TiKVのMVCC実装は、

77
00:09:03,060 --> 00:09:08,280
キーの後ろにバージョン番号を追加することで行われ、
過去のバージョンデータが一定期間に達したら、

78
00:09:08,280 --> 00:09:17,460
TiDBサーバーのガベージコレクションによってクリーンアップされます。
次は、コプロセッサーです。

79
00:09:17,460 --> 00:09:23,820
TiKV は、コプロセッサー機能を使用して、

80
00:09:23,820 --> 00:09:31,380
ローカルノードでデータフィルタリングや部分集計などを行うことができるため、
SQL 計算を

81
00:09:31,380 --> 00:09:36,660
分散ストレージノードにプッシュダウンして完了させることができます。

82
00:09:36,660 --> 00:09:43,680
TiDBサーバーのCPU、キャッシュ、メモリを最大限に活用し、
ネットワークインタラクションコストを削減した上で、

83
00:09:43,680 --> 00:09:49,200
分散ストレージノードの
並列処理能力も最大限に活用することができるようなメカニズムです。

84
00:09:50,460 --> 00:09:54,600
次はPlacement Driverについて話しましょう、
Placement Driverを覚えていますか？

85
00:09:55,380 --> 00:10:01,080
先ほども言及しましたが、それは一般的にPDと呼ばれています。
TiDBデータベースの頭脳となっています。

86
00:10:01,080 --> 00:10:08,040
PDは、TiKVクラスタ全体のメタデータのストレージに責任があります。

87
00:10:08,040 --> 00:10:12,660
PDはTiDBクラスタ上のデータがどこに存在するかを維持する責任があります。

88
00:10:12,660 --> 00:10:16,440
また、Raftが使用する情報の維持にも責任があります。

89
00:10:17,160 --> 00:10:22,500
TiDBサーバーはPDからルーティング情報を取得し、その情報を使って

90
00:10:22,500 --> 00:10:30,540
TiKVクラスタのデータにアクセスします。
PDにはトポロジーラベル情報も格納されています。

91
00:10:30,540 --> 00:10:36,720
これについては、今後のモジュールで取り上げます。

92
00:10:36,720 --> 00:10:41,520
PDに関して、何を推奨したか覚えていますか？
ここで、少し思い出してみましょう。

93
00:10:46,080 --> 00:10:52,020
少し難しかったでしょうか?
PDクラスタ内のPDノードの数は奇数にすることを推奨されていました。

94
00:10:52,020 --> 00:10:59,700
その理由については、今後のモジュールで詳しく説明します。

95
00:11:00,660 --> 00:11:06,960
次に、PDはグローバルIDとトランザクションIDを割り当てる責任があります。

96
00:11:06,960 --> 00:11:14,520
PDが割り当てるのは、ストアIDやリージョンID、ピアID、テーブルID、
インデックスIDなどのグローバルIDと、分散トランザクションのトランザクションIDです。

97
00:11:14,520 --> 00:11:22,980
PDは、Timestamp Oracleを使用してグローバルなタイムスタンプを生成する責任があります。

98
00:11:22,980 --> 00:11:29,160
Timestamp Oracleは、データベース内のトランザクションの
順序を保証するためのグローバルなタイムスタンプです。

99
00:11:29,160 --> 00:11:36,840
後ほど詳細を説明しますが
データベースがトランザクションの

100
00:11:36,840 --> 00:11:42,000
もし物事をロールバックする必要がある場合、
順序を正確に知ることが非常に重要です。

101
00:11:43,380 --> 00:11:50,760
PDはスケジューリングのためのクラスタ情報を収集する責任があります。

102
00:11:50,760 --> 00:11:56,880
TiKVノードは、PDにクラスタの状態を定期的に報告します。

103
00:11:56,880 --> 00:12:04,200
TiKVノード間のリージョンを関連するステータスに従って
PDがスケジューリングする責任があります。

104
00:12:04,200 --> 00:12:12,120
先のセクションで96メガバイトなどでレプリカを分割することについて話したことと関係しています。
これの詳細は後で紹介します。

105
00:12:12,120 --> 00:12:20,400
最後に、PDはTiDBダッシュボードサービスの提供に責任があります。

106
00:12:20,400 --> 00:12:26,400
PDが小さなWebサーバーをホストして、TiDBダッシュボードを実行しています。

107
00:12:26,400 --> 00:12:31,380
TiDBデータベースに関する情報を簡単に見つけることができるダッシュボードが提供されています。
また後でこれについて話し合いましょう。

108
00:12:33,540 --> 00:12:39,900
2番目のコンポーネントであるTiFlashは、HTAPの
アナリティクス側を実装していることを思い出します。

109
00:12:39,900 --> 00:12:47,460
TiKVをOLTP側のストレージとして必要とすることをここで取り上げておきましょう。

110
00:12:47,460 --> 00:12:54,180
PinpCAPは、分析が必要ないユースケースを持つ顧客がいます。
これらの顧客は、ストレージにTiKVのみを使用しています。

111
00:12:54,180 --> 00:13:02,640
もし本当に彼らがOLAP機能を拡張する必要があると決定した場合、
TiFlashを簡単にインストールすることで、

112
00:13:02,640 --> 00:13:08,940
TiDB環境にOLAP機能を追加することができます。

113
00:13:09,480 --> 00:13:12,900
TiFlashの特徴として、以下の能力があります。

114
00:13:14,760 --> 00:13:22,980
非同期レプリケーション。
TiKVは実際にはTiFlashがそれなしでは動作しない主要なストレージコンポーネントです。

115
00:13:22,980 --> 00:13:30,600
別の言い方をすると、TiKVだけではTiDBを持てるが、
TiFlashだけでは持てないということです。

116
00:13:30,600 --> 00:13:37,320
TiDBにデータを挿入、更新、またはロードするとき、

117
00:13:37,320 --> 00:13:45,060
最初にTiKVに書き込まれ、その後TiFlashにレプリケートされます。
この操作は非同期で行われます。

118
00:13:45,060 --> 00:13:50,220
Raftには、このタスクを実行する特別な役割があります。それがRaft Learnerです。

119
00:13:51,420 --> 00:13:58,080
TiFlashノードがダウンした場合や、ネットワークが高いレイテンシーを持つ場合でも、
データはTiKVから読み取ることができます。

120
00:13:58,080 --> 00:14:05,160
このような冗長性は、正常な運用を確実にします。
TiKVシステムの自動ロードバランシングと高可用性を継承することも、

121
00:14:05,160 --> 00:14:10,680
このレプリケーションメカニズムによって実現されます。

122
00:14:10,680 --> 00:14:16,560
追加のレプリケーションパイプラインを必要とせず、
TiKVのデータ転送を1対多の方法で直接受信することができます。

123
00:14:16,560 --> 00:14:23,220
TiKVのデータが失われない限り、
いつでもTiFlashのレプリカを作成することができます。

124
00:14:25,320 --> 00:14:32,880
次に、TiFlashはTiKVと同じスナップショット分離レベルのサポートを提供し、
読み取りデータが最新であることを保証し、

125
00:14:32,880 --> 00:14:39,000
以前に書き込まれたデータを読み取ることができることを保証します。

126
00:14:39,000 --> 00:14:46,440
この一貫性は、データのレプリケーションの進捗を検証することによって達成されます。

127
00:14:46,440 --> 00:14:52,500
読み取りリクエストが受信されるたびに、
リージョンレプリカと TiFlash が進行を開始します

128
00:14:52,500 --> 00:15:00,780
リージョンレプリカとTiFlashは、Leaderノードへの非常に軽いプロシージャコールリクエストを開始し、

129
00:15:00,780 --> 00:15:06,540
読み取りリクエストのタイムスタンプでカバーされるデータを少なくとも含んでいることをプロセスが確認した場合にのみ、
読み取りに応答します。

130
00:15:08,100 --> 00:15:15,180
次に、進捗確認を開始します。
カラム指向ストアは、分析クエリの効率性を改善します。

131
00:15:15,180 --> 00:15:22,140
はい、これは以前も言ったことですが、
TiFlashは列指向データストアであるということは重要ですので再度取り上げます。

132
00:15:22,680 --> 00:15:27,120
列指向のデータストアは分析ワークフローのために設計されました。

133
00:15:27,120 --> 00:15:33,900
行指向のストレージはトランザクション処理に最適ですので、

134
00:15:33,900 --> 00:15:39,420
インデックスや小さな結果セットを含むユースケースには理想的です。
テーブルスキャンや、

135
00:15:39,420 --> 00:15:45,120
データを複数回読み取る必要がある分析技術に関する用途には、
列指向ストレージが理想的です。

136
00:15:46,440 --> 00:15:53,040
MPPの導入、膨大な並列処理機能アーキテクチャが、

137
00:15:53,040 --> 00:15:59,340
並列に複数のサーバーノードに計算タスクを配布するものです。

138
00:15:59,340 --> 00:16:04,500
各ノードでの計算が完了した後、
各部分の結果をまとめて最後の答えを得ます。

139
00:16:04,500 --> 00:16:10,440
TiFlash上の分析クエリサービスをより効率的にするために、
この処理モデルが提供されます。

140
00:16:11,400 --> 00:16:17,400
次に、ビジネスの分離です。
これは良いものです。先ほども述べたように、

141
00:16:17,400 --> 00:16:24,360
カラムストアは統計分析クエリやOLAPにとてもフレンドリーで、
行ストアはトランザクションOLTPにフレンドリーです。

142
00:16:24,360 --> 00:16:32,880
そのため、TiKVとTiFlashは、
OLTPとOLAPの2つの異なるビジネスシナリオやユースケースに使用することができます。

143
00:16:33,480 --> 00:16:40,980
この2つのユースケースの両方に1つの環境を使用することで、
管理と処理コストを節約できます。

144
00:16:40,980 --> 00:16:47,040
そして、これは大きな意味があります。
つまり、OLTPからOLAPへのETLプロセスを作成および管理する必要がなくなります。

145
00:16:47,040 --> 00:16:50,820
その結果、より多くの時間とリソースを節約できます。

146
00:16:52,020 --> 00:16:59,280
最後に、これが私のお気に入りです、TiKVかTiFlashのどちらでも、

147
00:16:59,280 --> 00:17:05,580
そのSQLエントリーはTiDBサーバーです。
それはどういう意味なのでしょうか？

148
00:17:05,580 --> 00:17:15,300
これは、どちらの用途のクエリもTiDBサーバーを介して行われ、
TiDBサーバー内のオプティマイザーがクエリに応じてTiKVとTiFlashを選択することを意味します。

149
00:17:15,300 --> 00:17:23,280
つまり、これはSQL文に基づいて選択されます。
そして、DBAや開発者として、あなたはクエリを書き、

150
00:17:23,280 --> 00:17:28,860
TiDBはデータを取得するのに最適な場所を選択します。
あなたは心配する必要はありません。完全に透明です。

151
00:17:29,820 --> 00:17:35,400
これで最初のモジュールは終わりです。
TiDB とそのアーキテクチャを簡単に見てきました。

152
00:17:35,400 --> 00:17:43,800
あなたはここで、TiDBデータベースの全体的なアーキテクチャを説明できるようになり、
理解できるようになりました。

153
00:17:43,800 --> 00:17:50,160
そうですね、理解というのは正確な目標ではないですね。
TiDBサーバー、TiKV、そしてPlacement Driverの主な特徴を説明できることにします。

154
00:17:50,160 --> 00:17:56,820
TiDBデータベースとTiDBサーバーの違いを説明できますか。

155
00:17:59,820 --> 00:18:06,060
データベースは、データベース環境全体を指します。 

156
00:18:06,060 --> 00:18:10,920
一方、TiDB サーバーは、TiDB データベースの SQL 処理コンポーネントを指します。

157
00:18:10,920 --> 00:18:15,720
それで、TiDBサーバーはTiDBデータベースのコンポーネントです。

158
00:18:17,160 --> 00:18:21,300
このモジュールを見てくれてありがとうございました。
あなたが楽しみながら多くのことを学んだことをを願っています。