1
00:00:00,000 --> 00:00:14,040
[音楽] TiDB について話す時、なぜ分散データベースと呼ぶのか。アーキテクチャについて深く掘り下げる前に、

2
00:00:14,040 --> 00:00:19,380
別の簡単な質問にすばやく答えたいと思います。

3
00:00:19,980 --> 00:00:27,300
なぜTiDBを使用する必要があるのですか。TiDBを使用し始めるとすぐに、以下の利点が明らかになります。

4
00:00:27,300 --> 00:00:34,440
はじめに、TiDBはシームレスな拡張性を備えています。TiDBではすべてのすべてのキーコンポーネントはお互いに分離されており、

5
00:00:34,440 --> 00:00:40,980
水平スケーラビリティをサポートしています。第二に、TiDBは高可用性を提供します。

6
00:00:41,820 --> 00:00:46,740
状態を持つコンポーネントでは、一貫性のあるデータレプリケーションがサポートされています。

7
00:00:47,520 --> 00:00:52,500
あなたは、そのようなコンポーネントを複数展開することで簡単に高可用性を達成でき、

8
00:00:52,500 --> 00:00:57,780
複数の地域に展開することでスムーズな災害復旧を保証できます。

9
00:00:58,920 --> 00:01:05,100
第三に、TiDBは実際にはSQLとトランザクション互換性を持つ水平スケーラブルな

10
00:01:05,100 --> 00:01:12,720
キーバリューデータベースです。TiDBを使用することで、SQLとNoSQLの両方の利点を同時に得ることができます。

11
00:01:15,240 --> 00:01:21,660
そして、あなたのデータベースは巨大な容量に成長する可能性があり、MySQLデータベースでは想像もできないような規模になるかもしれません。

12
00:01:23,760 --> 00:01:29,340
TiDBの自動シャーディングは完全にアプリケーションに透過的です。つまり、

13
00:01:29,340 --> 00:01:35,580
データが増えた場合に必要なアプリケーションの変更がゼロです。最後に、標準SQLを使用してTiDBとコミュニケーションができます。

14
00:01:35,580 --> 00:01:41,760
あなたはすでにビッグデータのパーティーに参加するチケットをもっているようなものです。ETLや、

15
00:01:41,760 --> 00:01:48,240
データの抽出、変換、および読み込みが必要ありません。TiDBは任意のデータ量をストアし、取得することができます。

16
00:01:49,200 --> 00:01:55,740
そして、それはトランザクション処理に適した行ベースのストアと、同時に解析処理に適した列指向

17
00:01:55,740 --> 00:02:02,760
ストレージの両方を提供します。これについてはこのコースの後半で詳しく説明します。

18
00:02:07,080 --> 00:02:13,560
TiDBを使用しないアーキテクチャの例がここにあります。ここに6つのデータベースクライアントのインスタンスが配置されています。もちろん、

19
00:02:14,220 --> 00:02:20,880
実際にはもっとあるかもしれません。アーキテクチャはすでにクラウドに適したものです。

20
00:02:20,880 --> 00:02:27,900
ここでのアベイラビリティゾーンとは、クラウドサービスプロバイダによって提供されるデータセンターまたはAZを指します。

21
00:02:29,040 --> 00:02:35,880
そして、オンラインでのトランザクション処理にはMySQLがあります。ここにあるスタンバイデータベースは、高可用性と災害復旧の

22
00:02:35,880 --> 00:02:41,700
用途のLeaderデータベースの完全なレプリカです。

23
00:02:42,480 --> 00:02:48,840
Leaderへの書き込みとレプリカへの読み取りを使用すると、かなりのワークロードを処理できます。

24
00:02:48,840 --> 00:02:55,500
また、読み取りパフォーマンスを向上させるために、トランジットオブジェクトまたはホットスポットオブジェクトのキャッシュがあります。

25
00:02:56,400 --> 00:03:03,600
NoSQLデータベースは、水平方向にスケーラブルな永続ストアであり、そのノードはアベイラビリティゾーン全域にまたがることができます。

26
00:03:03,600 --> 00:03:10,740
これにより、高可用性、災害復旧、パフォーマンス、拡張性の要件を

27
00:03:10,740 --> 00:03:19,800
大規模な環境で達成することができます。データレイヤーアーキテクチャはある程度複雑です。MySQLマスターにズームインします。ビジネスが成長するにつれて、データは単一のマシンを超えて増え続けるため、

28
00:03:19,800 --> 00:03:25,560
別の解決策が必要になる場合があります。一つの方法は、書き込みの増加を処理するために、

29
00:03:25,560 --> 00:03:31,500
シャーディングと呼ばれる方法を使って、データを複数のデータベースに分割することです。

30
00:03:32,880 --> 00:03:38,220
例えば、最初に、ユーザーIDがアルファベットのAからZで始まる

31
00:03:38,220 --> 00:03:45,840
ユーザーのすべての情報を1つのデータベースに格納することがあります。書き込みキャパシティを増やすために、

32
00:03:45,840 --> 00:03:52,800
データベースを二つに分割します。ええ、いくつかのユーザーは最初のデータベースを扱い、別のいくつかのユーザーは 2 番目のデータベースを扱っています。

33
00:03:53,520 --> 00:03:58,620
ここではユーザーIDの最初の文字を例として使用していますが、

34
00:03:58,620 --> 00:04:04,260
実際には人々が特定のデータに使用されるシャードを決定するために一貫性のあるハッシュを使用することがあります。

35
00:04:05,580 --> 00:04:10,680
容量をさらに増やす必要がある場合は、同じことをしてデータセットを再分割します。

36
00:04:11,700 --> 00:04:15,540
シャードを追加すると、レポートの生成がますます困難になります。

37
00:04:17,280 --> 00:04:22,800
それらは書き込み操作にのみ使用されます。そして、読み取りパフォーマンスを良くするために、

38
00:04:22,800 --> 00:04:28,260
ローカルのアベイラビリティゾーンにレプリカが必要になり、高可用性と災害復旧のために、

39
00:04:28,260 --> 00:04:34,680
対となるAZにスタンバイデータベースが必要になります。 これは開発者や運用チームにとってはまったく楽しくないです。

40
00:04:36,120 --> 00:04:41,520
TiDBを使用することで、データレイヤーのアーキテクチャは簡単になり、

41
00:04:41,520 --> 00:04:50,040
複雑さもNoSQL同様に大幅に軽減されます。TiDBは分散型であり、水平スケーリングに対応しています。

42
00:04:51,660 --> 00:04:55,980
TiDBはシャーディングを自動的に処理して、アプリケーションに透過的です。

43
00:04:57,300 --> 00:05:04,080
NoSQLとは異なり、TiDBはトランザクションとSQLをネイティブでサポートしており、MySQLと互換性があります。

44
00:05:04,740 --> 00:05:11,100
TiDB内では、レプリケーションが自動的に行われ、シャーディングが自動的に行われ、行ベースと

45
00:05:11,100 --> 00:05:17,460
列指向ストアの変換が自動的に行われます。MySQLとNoSQLデータベースの両方に代わる、

46
00:05:17,460 --> 00:05:22,740
多目的データベースの役目を果たします。

47
00:05:24,120 --> 00:05:27,900
TiDBでは多くのことに対応できるので、アプリケーションに集中できます。

48
00:05:28,740 --> 00:05:36,780
ユーザーは、将来の成長の痛みを心配することなく、データのアジリティを獲得します。しかし、TiDBでは多くのことに対応できますが、アプリケーションによって引き起こされるホットスポットの

49
00:05:36,780 --> 00:05:42,960
ボトルネックを完全に除去することはできないと言わざるを得ません。

50
00:05:43,800 --> 00:05:49,200
そのため、Redisなどのキャッシュコンポーネントは、アプリケーションのホットスポットの場合に対してまだ必要です。

51
00:05:50,280 --> 00:05:55,260
データベース運用の学習パスの中でTiDB パフォーマンスチューニングコースや、開発者向けの学習パスの中のTiDB固有機能コースで、

52
00:05:55,260 --> 00:06:01,800
ホットスポットを軽減する方法について詳細に説明します。

53
00:06:02,820 --> 00:06:09,660
TiDBデータベースの主要コンポーネント、つまりTiDBは3種類のサーバークラスタで構成されています。

54
00:06:10,320 --> 00:06:14,700
それらすべてがお互いに通信し、データベースクラスタを形成します。

55
00:06:16,500 --> 00:06:24,000
コンポーネントとして、TiDBサーバークラスタ、TiKVサーバークラスタ、およびPlacement Driverクラスタ、

56
00:06:24,000 --> 00:06:32,100
別名PDクラスタが含まれます。すべての3つのサブクラスタは互いに切り離されています。TiDBサーバーの数は、

57
00:06:32,100 --> 00:06:37,920
TiKVサーバーの数やPDサーバーの

58
00:06:37,920 --> 00:06:46,920
数と一致する必要はありません。 例えば、2つのTiDBサーバー、3つのPDサーバー、そして6つのTiKVサーバーを持つことができます。

59
00:06:46,920 --> 00:06:54,000
最初に議論したいサーバークラスタは、TiDBサーバークラスタです。TiDB と TiDB サーバークラスタの

60
00:06:54,000 --> 00:07:01,080
間違いを起こさないように注意しましょう。TiDBサーバークラスタは、TiDBのコンポーネントであるサブクラスタです。

61
00:07:02,400 --> 00:07:08,520
TiDB サブクラスタは SQL レイヤーを表し、MySQLプロトコルの接続エンドポイントを公開します。

62
00:07:09,480 --> 00:07:14,280
TiDBサーバーインスタンスは、データベースクライアントからの

63
00:07:14,280 --> 00:07:20,340
接続を受け入れる責任があります。TiDBサーバークラスタは状態を持たず、実際に複数の

64
00:07:20,340 --> 00:07:26,220
TiDBサーバーインスタンスを起動できます。そして、LVS、HAProxy、またはF5 Big IPなどのロードバランシングコンポーネントを介して、

65
00:07:26,220 --> 00:07:35,040
統合されたDNS名を提供できます。もしパブリッククラウドを利用している場合、

66
00:07:35,040 --> 00:07:41,880
クラウドサービスプロバイダーが提供する Elastic Load Balancing サービスも利用できます。したがって、

67
00:07:41,880 --> 00:07:47,820
アプリケーションの明示的な労力なしに、

68
00:07:47,820 --> 00:07:55,200
複数のTiDBサーバーインスタンス全体でクライアント接続を均等に分散させることができます。TiDBサーバーは実際にはテーブルデータを保存していません。

69
00:07:55,200 --> 00:08:00,960
SQL文を解析し、データリクエストをTiKVクラスタのストレージレイヤーに転送するだけです。

70
00:08:02,340 --> 00:08:08,280
私が議論したい2番目のサブクラスタは、PD、すなわちPlacement Driverサーバークラスタです。

71
00:08:09,180 --> 00:08:14,280
TiDB全体のメタデータ管理モジュールであり、各TiKVノードのリアルタイムデータ

72
00:08:14,280 --> 00:08:19,980
分散状況とTiDB全体のトポロジ設定を格納します。

73
00:08:20,880 --> 00:08:27,060
分散トランザクションのトランザクションIDを生成します。

74
00:08:27,060 --> 00:08:33,420
これはTSOすなわちタイムスタンプ・オラクルに基づいたものです。TSOは、分散データベースにおいても、

75
00:08:33,420 --> 00:08:38,100
2つの変更が時系列的に順序付けられることを保証するタイムスタンプです。

76
00:08:39,540 --> 00:08:45,240
PDはメタデータをストアするだけでなく、TiKVノードからリアルタイムに報告されたデータ分布に基づいて、

77
00:08:45,240 --> 00:08:51,780
特定のTiKVノードに標準スケジューリングコマンドを発行します。

78
00:08:53,160 --> 00:08:59,880
PDはクラスタ全体の頭脳と考えられています。クラスタはRaftアルゴリズムで支えられているため、

79
00:08:59,880 --> 00:09:06,480
PDを奇数のノードに展開する必要があります。それは通常、少なくとも3つの

80
00:09:06,480 --> 00:09:13,500
ノードを展開することを推奨しています。過半数のノードが生きている限り、クラスタは読み取りと書き込みの操作が可能です。

81
00:09:16,740 --> 00:09:21,840
最後のサブクラスタであるTiKVクラスタは、テーブルデータの保存を担当しています。

82
00:09:22,440 --> 00:09:27,720
外部から見ると、TiKVは分散型トランザクションキーバリューNoSQLデータベースです。

83
00:09:29,220 --> 00:09:36,180
TiKVは災害復旧の際にデータの一貫性を確保するためにRaftアルゴリズムを使用しています。

84
00:09:37,860 --> 00:09:42,840
クラスタの頭脳でもあるPDが、異なる TiKV ノード間の

85
00:09:42,840 --> 00:09:49,500
データ配置の負荷分散をスケジュールします。TiKVがデータを保存する方法の基本的な理解を持っていただくため、

86
00:09:49,500 --> 00:09:55,560
スライドに表示されたステップに似たひとつの例を示します。

87
00:09:56,340 --> 00:10:01,500
ローカルマシンでTiDBのプレイグラウンドサンドボックスを起動するために、TiUP コマンドラインツールを使用します。

88
00:10:02,760 --> 00:10:09,780
TiDBが稼働すると、RAW KV APIを使用して簡単なput/get操作を行い、

89
00:10:09,780 --> 00:10:17,400
TiKVがキーバリューストアであることを示します。スクリプト自体はかなり直感的で、TiUPを呼び出して、

90
00:10:17,400 --> 00:10:23,940
名前がclassroomというTiDBシステム全体を起動するようになっています。これで私たちは3つのTiDBインスタンス、3つのPDインスタンス、

91
00:10:23,940 --> 00:10:31,140
3つのTiKVインスタンス、そして1つのTiFlashインスタンスを展開しました。TiFlashのインスタンス

92
00:10:31,140 --> 00:10:36,960
はとりあえず置いておくことにします。このコースでは後でTiFlashを取り上げます。そして、今TiUPがなくても

93
00:10:36,960 --> 00:10:42,660
心配しなくても大丈夫です。このユニットの最後の実験1の後には、TiUPがインストールされています。それではやってみましょう。

94
00:10:48,960 --> 00:10:55,380
PDが起動しているのが見えます。その後、TiKVとTiDBが起動しています。現実の世界のプロダクション環境では、

95
00:10:55,380 --> 00:10:59,580
別々のノードでこれらのサーバーを起動できます。

96
00:11:00,420 --> 00:11:06,660
プレイグラウンドは、テスト目的のサンドボックスにすぎないことに注意してください。オーケー、これですべて準備の準備ができました。

97
00:11:11,640 --> 00:11:15,600
RAW クライアントを使用して、接続を構築できることがわかります。

98
00:11:18,240 --> 00:11:20,460
私たちが使用しているエンドポイントはPDから取得できます。

99
00:11:22,920 --> 00:11:26,580
私たちは単に新しいキー・バリューのペアを入れて取り出します。

100
00:11:27,720 --> 00:11:33,720
そして、存在しないキーから値を取得しようとしてみましょう。何が起こるか見てみましょう。

101
00:11:40,380 --> 00:11:46,800
期待した通りでしたか。実際に、私たちはTiKVにキーと値のペアを保存することができます。

102
00:11:46,800 --> 00:11:52,560
そして、私たちはキー1から値を取得できますが、存在しないキー0からは値を取得できません。

103
00:11:53,400 --> 00:12:00,720
これは、このコースで RAW KV インタフェースを使用する最初で最後の機会です。以降、

104
00:12:00,720 --> 00:12:06,300
このコースを通じて、コミュニケーションに使用する唯一の言語はSQLになります。