0 00:00:00,000 --> 00:00:08,860 [Music] 1 00:00:08,860 --> 00:00:10,860 In this unit, we will talk about TiDB Cloud. 2 00:00:11,520 --> 00:00:17,040 Because of the distributed and the coupled design, TiDB cluster is elastic in nature. 3 00:00:17,580 --> 00:00:21,300 So the public cloud is a perfect container to host TiDB. 4 00:00:22,080 --> 00:00:24,600 TiDB cloud or database as a service can use almost 5 00:00:24,600 --> 00:00:28,560 unlimited storage capacities and computing powers in the cloud. 6 00:00:29,100 --> 00:00:32,880 In the first unit, we explained why we should choose TiDB. 7 00:00:32,880 --> 00:00:39,300 TiDB has many advantages, including seamless horizontal scalability, high availability and 8 00:00:39,300 --> 00:00:47,100 the disaster recovery ability. TiDB also supports standard SQL and transactions as a NoSQL database. 9 00:00:48,120 --> 00:00:52,320 TiDB's auto sharding feature makes sharding transparent to 10 00:00:52,320 --> 00:00:58,080 your application. In addition to that, TiDB has big data capability with zero efforts. 11 00:00:58,980 --> 00:01:04,020 Zero efforts means you can ingest terabytes of data effectively by using SQL, 12 00:01:04,740 --> 00:01:08,940 you can serve real-time analytic query in seconds by using standard 13 00:01:08,940 --> 00:01:13,080 SQL with the help of TiFlash and no ETL is required. 14 00:01:13,980 --> 00:01:17,220 What I just pointed out are TiDB characteristics 15 00:01:17,880 --> 00:01:22,020 now we add additional advantages because we are in the cloud this time. 16 00:01:23,100 --> 00:01:27,600 TiDB cloud is not just an on-premises TiDB deployed into the public cloud. 17 00:01:28,380 --> 00:01:33,480 It is a re-platformed database as a service, designed specifically for the cloud. 18 00:01:34,620 --> 00:01:40,080 As a managed service many ops and maintenance tasks are eliminated or automated. 19 00:01:40,800 --> 00:01:44,640 The database can store and retrieve any amount of data by horizontally 20 00:01:44,640 --> 00:01:50,940 scaling TiKV and TiFlash nodes, to serve any level of request traffic cost effectively. 21 00:01:51,780 --> 00:01:56,640 By using TiDB Cloud, you are not locked in by the cloud service provided. 22 00:01:57,180 --> 00:02:02,340 We support both AWS and gcp as the underlying cloud providers right now. 23 00:02:03,360 --> 00:02:06,180 We provide consistent management interface and 24 00:02:06,180 --> 00:02:09,240 user experiences no matter which provider you choose. 25 00:02:10,260 --> 00:02:17,880 Last, but not least, security and compliance are always priority zero. TiDB cloud is audited and 26 00:02:17,880 --> 00:02:22,860 certified by third parties so you can get your business started quickly and safely. 27 00:02:25,080 --> 00:02:29,940 THis diagram shows you the high level overview of the service architecture of TiDB Cloud. 28 00:02:31,020 --> 00:02:32,760 In the cloud provider region, 29 00:02:32,760 --> 00:02:38,640 there is a TiDB virtual private cloud or VPC, where all TiDB nodes reside. 30 00:02:39,720 --> 00:02:43,980 TiDB central services are deployed independently along with the dashboard, 31 00:02:43,980 --> 00:02:49,800 which allows you to access those services via the internet after authentication and authorization. 32 00:02:51,660 --> 00:02:57,240 TiDB servers are decoupled by a lot of balancing service. Load balancing 33 00:02:57,240 --> 00:03:00,000 service in the cloud are highly available and the disaster recovery capable by default. 34 00:03:01,200 --> 00:03:07,200 Your application is deployed in another VPC. Through VPC peering connection provided by 35 00:03:07,200 --> 00:03:12,060 the cloud provider, there is no need to go all the way around to the internet and back again. 36 00:03:13,200 --> 00:03:17,940 In addition to that, you can see three AZs in the cloud provider region. 37 00:03:18,840 --> 00:03:21,300 AZ stands for availability zone. 38 00:03:22,200 --> 00:03:24,960 Each AZ is comprised of at least one data center. 39 00:03:24,960 --> 00:03:29,940 The average distance between two AZs is about 20 to 30 kilometers. 40 00:03:30,720 --> 00:03:37,200 So you can easily achieve HA and the disaster recovery capability, by spinning up the SQL 41 00:03:37,200 --> 00:03:42,960 layer and a storage layer nodes, which are the TiDB and the TiKV nodes across AZs. 42 00:03:44,520 --> 00:03:49,260 For performance management, you can scale in or scale out components nodes by clicking 43 00:03:49,260 --> 00:03:53,280 the button on the cluster management console or calling the web service API. 44 00:03:53,880 --> 00:03:58,440 By the way I have to mention that you have to take hotspot problems into considerations. 45 00:03:59,760 --> 00:04:03,360 We cover this topic in the course named TiDB Performance tuning. 46 00:04:04,260 --> 00:04:06,360 Remember that performance issues caused 47 00:04:06,360 --> 00:04:09,960 by hotspots can not be solved by simply scaling out your cluster. 48 00:04:11,820 --> 00:04:14,520 This concludes TiDB architecture basics. 49 00:04:15,180 --> 00:04:16,380 See you in next class.