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.