1
00:00:00,000 --> 00:00:06,540
[音楽]

2
00:00:07,980 --> 00:00:12,900
このユニットでは、2つの実世界のユースケースについて話す予定です。

3
00:00:14,040 --> 00:00:19,260
まず、A社を見てみましょう。A社は世界で最も有名な

4
00:00:19,260 --> 00:00:25,500
ソーシャルメディア企業の一つです。 A社は120万以上のQPSと90億以上のアカウントを持っています。

5
00:00:26,700 --> 00:00:30,900
HBaseは100以上のビジネスユースケースをサポートするために使用されました。

6
00:00:31,860 --> 00:00:35,360
A社のHBaseクラスタには9,000個のVMがあり、

7
00:00:35,360 --> 00:00:39,980
50個のプロダクションクラスタと6 PBのデータがあります。

8
00:00:41,060 --> 00:00:46,340
最も典型的なHBaseのユースケースの一つは管理履歴を記録することです。

9
00:00:47,060 --> 00:00:50,120
管理履歴は、ユーザールールの違反記録、

10
00:00:50,120 --> 00:00:55,640
ユーザーに対して行われたその後のアクション、および各アクションのタイムラインを記録します。

11
00:00:56,540 --> 00:01:00,560
トランザクションのサポートは、繰り返しの懲罰を防止し、

12
00:01:00,560 --> 00:01:05,300
公開可能で透明な報告の正確性を保証するために必要です。

13
00:01:07,340 --> 00:01:10,100
最初の世代のソリューションは、HBaseを使用することでした。

14
00:01:10,100 --> 00:01:15,080
また、インデックスサービスやトランザクションサービスなど、

15
00:01:15,080 --> 00:01:21,320
HBaseで利用できない機能を提供する多くの内製のシステムもありました。 しかしながら、これは高コストとなりました。

16
00:01:21,320 --> 00:01:26,540
それは複雑なシステムに対する高いメンテナンスコストや高いインフラコストを含みます。

17
00:01:26,540 --> 00:01:29,840
その上、複数のテーブルの強い整合性トランザクションのように、

18
00:01:29,840 --> 00:01:33,920
全ての不足している機能が回避策で提供できるわけではありません。

19
00:01:33,820 --> 00:01:38,480
それに加えて、最新バージョンへのHBaseのアップグレードは非常に困難です。

20
00:01:40,640 --> 00:01:45,080
第2世代のソリューションでは、企業AはHBaseを置き換えるためにTiDBを使用しています。

21
00:01:46,340 --> 00:01:49,400
TiDBはインデックス管理およびトランザクション制御をネイティブサポートしています。

22
00:01:50,300 --> 00:01:56,480
TiDBに切り替えた後、A社は、99パーセンタイルのクエリレイテンシが3倍から5倍低減したことを知り、

23
00:01:56,480 --> 00:02:03,380
大喜びです。 TiDBは複数のテーブルで強い一貫性トランザクションをネイティブでサポートする

24
00:02:03,380 --> 00:02:09,260
標準SQLインターフェースも提供しています。 運用タスクも大幅に簡略化されました。

25
00:02:09,260 --> 00:02:15,320
さあ、B社を見てみましょう。B社は、世界中の多くの地域にゲームサービスを提供する

26
00:02:15,320 --> 00:02:18,260
モバイルゲームおよびインターネットサービスプロバイダーです。

27
00:02:19,160 --> 00:02:22,040
B社には世界中で5,000万人以上のユーザーがいます。

28
00:02:22,880 --> 00:02:28,160
B社では、それぞれ特定のビジネスモジュールに対応する複数の独立したデータベースがあります。

29
00:02:28,160 --> 00:02:35,480
たとえば、オーディエンス、報酬、およびユーザータグの管理が挙げられます。そのデータは

30
00:02:35,480 --> 00:02:40,820
ゲームのキャンペーンやユーザーコンバージョンに使用され、それらはB社にとって非常に重要です。

31
00:02:40,820 --> 00:02:43,520
現在、広告とコンバージョンを効果的に管理するために、

32
00:02:43,520 --> 00:02:47,480
複数のデータベースをまたいで分析を行う必要があります。

33
00:02:47,480 --> 00:02:52,700
最初の世代のソリューションでは、複数のAmazon Aurora RDSインスタンスがトランザクションクエリを実行するために使用されます。

34
00:02:52,700 --> 00:02:58,400
各ビジネスモジュールに対して1つのAmazon Auroraインスタンスが利用されます。

35
00:02:58,940 --> 00:03:03,560
分析クエリの実行に使用される単一のAmazon Redshiftデータベースもあります。

36
00:03:03,560 --> 00:03:07,340
データのボリュームが増加し、単一のテーブルのデータボリュームが1億行にまで増加すると、

37
00:03:07,340 --> 00:03:12,680
メンテナンスが困難になります。

38
00:03:12,680 --> 00:03:14,720
三つの主要な課題があります。

39
00:03:14,720 --> 00:03:18,980
最初の課題は、追加のETLジョブが必要であることと、

40
00:03:18,980 --> 00:03:24,380
Amazon Redshiftはリアルタイムでのデータ更新を処理するには効果的ではないことです。データ量が増加したため、

41
00:03:24,380 --> 00:03:28,160
そのソリューションはリアルタイム広告の要件を満たすことができなくなりました。

42
00:03:29,000 --> 00:03:33,500
次に、Aurora RDSの更新とメンテナンスは困難です。ops チームは

43
00:03:33,500 --> 00:03:35,960
深夜しかメンテナンスできませんでした。

44
00:03:37,700 --> 00:03:42,920
最後に、Auroraでのオンラインのデータ定義言語(DDL)操作は効率的ではありません。AuroraでのオンラインのDDL操作は通常時間がかかり、

45
00:03:42,920 --> 00:03:48,200
場合によってはリソース不足のために失敗することがあります。

46
00:03:49,280 --> 00:03:54,620
TiDB Cloudへの切り替え後、

47
00:03:54,620 --> 00:03:59,420
複数のAmazon AuroraクラスタやAmazon Redshiftクラスタを使用する必要はなく、1つのTiDBクラスタで十分です。

48
00:03:59,420 --> 00:04:02,720
スループットは、 Auroraの3倍以上であり、

49
00:04:02,720 --> 00:04:05,960
クエリと書き込みの両方の機能が改善されています。

50
00:04:07,400 --> 00:04:12,560
TiDB Cloudは水平スケーラビリティ、強い一貫性、高可用性をサポートしています。

51
00:04:13,640 --> 00:04:20,060
ゲームプラットフォームでのデータレイテンシも問題ありません。同時に、TiDBのビルトイン

52
00:04:20,060 --> 00:04:25,280
列指向ストレージであるTiFlashは、アプリケーションを変更することなく解析パフォーマンスを向上させます。

53
00:04:26,840 --> 00:04:31,940
運用タスクが大幅に簡素化され、アプリケーションの変更は必要ありません。

54
00:04:32,780 --> 00:04:37,880
これで、TiDBコースの紹介は終了です。最後までお付き合いいただき、ありがとうございました。

55
00:04:38,420 --> 00:04:43,220
もっと学びたい場合は、PingCAPトレーニングおよび認定試験のホームページをご覧ください。

56
00:04:43,880 --> 00:04:47,480
あなたに合ったコースやワークショップを見つけることができると確信しています。