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.