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

2
00:00:08,860 --> 00:00:10,860
このユニットでは、TiDB Cloudについて話します。

3
00:00:11,520 --> 00:00:17,040
分散化と結合した設計のため、TiDBクラスタは元々伸縮性があります。

4
00:00:17,580 --> 00:00:21,300
パブリッククラウドは、TiDBをホストするための完璧なコンテナです。

5
00:00:22,080 --> 00:00:24,600
TiDB Cloudまたはデータベースサービスは、クラウド内の

6
00:00:24,600 --> 00:00:28,560
ほぼ無制限のストレージ容量と計算能力を利用できます。

7
00:00:29,100 --> 00:00:32,880
最初のユニットでは、なぜTiDBを選択すべきかを説明しました。

8
00:00:32,880 --> 00:00:39,300
TiDBには、シームレスな水平スケーラビリティ、高可用性、

9
00:00:39,300 --> 00:00:47,100
そして災害復旧能力など、多くの利点があります。TiDBはNoSQLデータベースだけでなく標準SQLとトランザクションをサポートしています。

10
00:00:48,120 --> 00:00:52,320
TiDBの自動シャーディング機能により、アプリケーションにとって

11
00:00:52,320 --> 00:00:58,080
シャーディングが透過的になります。その上、TiDBは苦労せず利用出来るビッグデータの能力を持っています。

12
00:00:58,980 --> 00:01:04,020
苦労せずとは、SQL を使ってテラバイト単位のデータを効果的に収集できることを意味し、

13
00:01:04,740 --> 00:01:08,940
TiFlash のサポートにより、標準的な SQL を使用してリアルタイム分析クエリを数秒で提供することができます。

14
00:01:08,940 --> 00:01:13,080
ETL は不要です。

15
00:01:13,980 --> 00:01:17,220
以上が、TiDBの特徴です。

16
00:01:17,880 --> 00:01:22,020
今回はクラウド上にあるため、追加の利点があります。

17
00:01:23,100 --> 00:01:27,600
TiDB Cloudは、単にオンプレミスに展開されたTiDBをパブリッククラウドに展開するだけではありません。

18
00:01:28,380 --> 00:01:33,480
クラウド向けに特別に設計され、リプラットフォームされたデータベースサービスです。

19
00:01:34,620 --> 00:01:40,080
マネージドサービスとして、オペレーションやメンテナンスタスクの多くが削減、または自動化されます。

20
00:01:40,800 --> 00:01:44,640
データベースは、TiKVおよびTiFlashノードを水平方向にスケーリングして、

21
00:01:44,640 --> 00:01:50,940
任意のレベルのリクエストトラフィックを費用対効果よく処理するために、任意の量のデータを格納および取得できます。

22
00:01:51,780 --> 00:01:56,640
TiDB Cloudを使用することで、提供されたクラウドサービスに固定されることはありません。

23
00:01:57,180 --> 00:02:02,340
現在、私たちはAWSとGCPの両方を、基盤のクラウドプロバイダとして利用しています。

24
00:02:03,360 --> 00:02:06,180
どのプロバイダを選択しても、一貫性のある管理インターフェース

25
00:02:06,180 --> 00:02:09,240
とユーザーエクスペリエンスを提供します。

26
00:02:10,260 --> 00:02:17,880
最後に、セキュリティとコンプライアンスは常に最優先事項です。TiDB Cloudは第三者によって監査され、保証されているため、

27
00:02:17,880 --> 00:02:22,860
ビジネスを迅速かつ安全に開始することができます。

28
00:02:25,080 --> 00:02:29,940
この図は、TiDB Cloud のサービスアーキテクチャの概要を示しています。

29
00:02:31,020 --> 00:02:32,760
クラウドプロバイダのリージョンに、

30
00:02:32,760 --> 00:02:38,640
TiDB バーチャルプライベートクラウドまたは VPC があり、そこにすべての TiDB ノードがあります。

31
00:02:39,720 --> 00:02:43,980
TiDBセントラルサービスは、ダッシュボードと独立してデプロイされ、

32
00:02:43,980 --> 00:02:49,800
認証と認可の後にインターネットを介してこれらのサービスにアクセスできるようになっています。

33
00:02:51,660 --> 00:02:57,240
TiDBサーバーは多くのバランシングサービスによって切り離されています。クラウド上のロードバランシングサービスは、

34
00:02:57,240 --> 00:03:00,000
デフォルトで高可用性を備えており、災害復旧機能も備えています。

35
00:03:01,200 --> 00:03:07,200
あなたのアプリケーションは別のVPCに展開されています。クラウドプロバイダが提供するVPCピアリング接続を利用すれば

36
00:03:07,200 --> 00:03:12,060
、わざわざインターネットを経由して往復する必要はありません。

37
00:03:13,200 --> 00:03:17,940
さらに、クラウドプロバイダーのリージョンには3つのAZが見えます。

38
00:03:18,840 --> 00:03:21,300
AZはアベイラビリティーゾーンの略です。

39
00:03:22,200 --> 00:03:24,960
各AZは少なくとも1つのデータセンターで構成されています。

40
00:03:24,960 --> 00:03:29,940
平均的な2つのAZの間の距離は約20〜30キロメートルです。

41
00:03:30,720 --> 00:03:37,200
SQLレイヤーとストレージレイヤーノード、

42
00:03:37,200 --> 00:03:42,960
すなわちAZ全体にまたがるTiDBとTiKVノードを起動することで、簡単にHAと災害復旧能力を実現できます。

43
00:03:44,520 --> 00:03:49,260
パフォーマンス管理のためには、クラスタ管理コンソール上のボタンをクリックするか、

44
00:03:49,260 --> 00:03:53,280
WebサービスAPIを呼び出すことにより、コンポーネントノードをスケールインまたはスケールアウトすることができます。

45
00:03:53,880 --> 00:03:58,440
ところで、ホットスポットの問題を考慮する必要があることについて話しておきましょう。

46
00:03:59,760 --> 00:04:03,360
私たちは、TiDBパフォーマンスチューニングという名前のコースでこのトピックを扱っています。

47
00:04:04,260 --> 00:04:06,360
ホットスポットによって引き起こされるパフォーマンスの問題は、

48
00:04:06,360 --> 00:04:09,960
クラスタの拡張だけでは解決できないことを覚えておいてください。

49
00:04:11,820 --> 00:04:14,520
これでTiDBのアーキテクチャの基礎が終わります。

50
00:04:15,180 --> 00:04:16,380
次のクラスで会いましょう。