1
00:00:00,000 --> 00:00:06,540
Music

2
00:00:07,980 --> 00:00:12,900
In this unit, we are going to talk about two real world use cases.

3
00:00:14,040 --> 00:00:19,260
Let's first look at company A. Company A is one of the most famous social media companies


4
00:00:19,260 --> 00:00:25,500
in the world. Company A has more than 1.2 million QPS and more than 9 billion accounts.


5
00:00:26,700 --> 00:00:30,900
HBase was used to support more than 100 business use cases.


6
00:00:31,860 --> 00:00:35,360
Company A's HBase clusters have 9,000 VMs,


7
00:00:35,360 --> 00:00:39,980
50 production clusters, and 6 PBs of data.


8
00:00:41,060 --> 00:00:46,340
One of the most typical HBase use cases is to record the administration history.


9
00:00:47,060 --> 00:00:50,120
The administration history records user rule violations,


10
00:00:50,120 --> 00:00:55,640
the subsequent actions taken against the user and the timelines for each action.


11
00:00:56,540 --> 00:01:00,560
The support for transaction is necessary to prevent repetitive


12
00:01:00,560 --> 00:01:05,300
punishments and guarantee the accuracy of the publicly available transparent report.


13
00:01:07,340 --> 00:01:10,100
The first generation of solution was to use HBase,


14
00:01:10,100 --> 00:01:15,080
as well as many in-house systems, such as index service and transaction service,


15
00:01:15,080 --> 00:01:21,320
which provides the functionalities unavailable in HBase. However, this leads to high costs,


16
00:01:21,320 --> 00:01:26,540
including high maintenance cost and high infra cost for complicated systems.


17
00:01:26,540 --> 00:01:29,840
Moreover, not all of the missing functionalities can be addressed


18
00:01:29,840 --> 00:01:33,920
with a workaround, such as cross table strong consistency transaction.


19
00:01:33,820 --> 00:01:38,480
In addition to that, it is very hard to upgrade HBase to the latest versions.


20
00:01:40,640 --> 00:01:45,080
In the second generation solutions, Company A uses TiDB to replace HBase.


21
00:01:46,340 --> 00:01:49,400
TiDB natively supports index management and transaction control.


22
00:01:50,300 --> 00:01:56,480
After switching to TiDB, Company A is thrilled to find out that there is 3 to 5 times 99-percentile


23
00:01:56,480 --> 00:02:03,380
query latency reduction. TiDB also provides standard SQL interface with native support of


24
00:02:03,380 --> 00:02:09,260
cross-table strong consistency transactions. The operation tasks have also been greatly simplified.


25
00:02:09,260 --> 00:02:15,320
Let's now look at company B. Company B is a mobile gaming and internet service provider,


26
00:02:15,320 --> 00:02:18,260
which offers gaming services to multiple regions around the world.


27
00:02:19,160 --> 00:02:22,040
Company B has more than 50 million users worldwide.


28
00:02:22,880 --> 00:02:28,160
In Company B, various independent databases serve specific business modules respectively,


29
00:02:28,160 --> 00:02:35,480
for example, audience, rewards and user tags management. Those data are used for gaming


30
00:02:35,480 --> 00:02:40,820
campaigns and user conversions, which is of great importance for Company B.


31
00:02:40,820 --> 00:02:43,520
Currently, analytics across multiple databases is


32
00:02:43,520 --> 00:02:47,480
necessary to effectively manage advertising and conversions.


33
00:02:47,480 --> 00:02:52,700
In the first generation of the solution, multiple Amazon Aurora RDS instances are


34
00:02:52,700 --> 00:02:58,400
used for conducting transactional queries: one Amazon Aurora instance for each business module.


35
00:02:58,940 --> 00:03:03,560
There is also a single Amazon Redshift database used to perform analytical queries.


36
00:03:03,560 --> 00:03:07,340
As the data volume increases, when the data volume of a single table


37
00:03:07,340 --> 00:03:12,680
increases to 100 million rows, maintenance becomes difficult.


38
00:03:12,680 --> 00:03:14,720
There are three main challenges.


39
00:03:14,720 --> 00:03:18,980
The first one is that, additional ETL jobs are needed, and Amazon Redshift


40
00:03:18,980 --> 00:03:24,380
is not effective in handling data updates in real-time. Due to the increase in data volume,


41
00:03:24,380 --> 00:03:28,160
the solution was unable to meet the real-time advertising requirements.


42
00:03:29,000 --> 00:03:33,500
Secondly, updating and maintaining Aurora RDS is hard. The ops team


43
00:03:33,500 --> 00:03:35,960
could only do maintenance in the middle of the night.


44
00:03:37,700 --> 00:03:42,920
Thirdly, Online Data Definition Language (DDL) operations with Aurora are inefficient. Online


45
00:03:42,920 --> 00:03:48,200
DDL with Aurora usually took hours and sometimes failed due to lack of resources.


46
00:03:49,280 --> 00:03:54,620
After switching to TiDB Cloud, one TiDB cluster is enough to replace


47
00:03:54,620 --> 00:03:59,420
multiple Amazon Aurora clusters, as well as the Amazon Redshift cluster.


48
00:03:59,420 --> 00:04:02,720
The throughput is three times more than that of Aurora,


49
00:04:02,720 --> 00:04:05,960
with query and write capabilities both improved.


50
00:04:07,400 --> 00:04:12,560
TiDB Cloud also supports horizontal scalability, strong consistency, and high availability.


51
00:04:13,640 --> 00:04:20,060
There is no data latency issue with the gaming platform. At the same time, TiDB's built-in


52
00:04:20,060 --> 00:04:25,280
columnar storage, TiFlash, improves analytics performance without changing the application.


53
00:04:26,840 --> 00:04:31,940
The operation task has been significantly simplified, and there is no application changes


54
00:04:32,780 --> 00:04:37,880
That marks the end of the Introduction to TiDB course. Thanks for staying with me.


55
00:04:38,420 --> 00:04:43,220
If you would like to learn more, please visit the PingCAP Training and Certification home page.


56
00:04:43,880 --> 00:04:47,480
I am sure you can find a course or workshop that suits you.