EN: |+| [Music] In this unit, we will talk about TiDB Cloud. EN: |+| Because of the distributed and the coupled design, TiDB cluster is elastic in nature. EN: |+| So the public cloud is a perfect container to host TiDB. EN: |+| TiDB cloud or database as a service can use almost |+| unlimited storage capacities and computing powers in the cloud. EN: |+| In the first unit, we explained why we should choose TiDB. EN: |+| TiDB has many advantages, including seamless horizontal scalability, high availability and |+| the disaster recovery ability. EN: TiDB also supports standard SQL and transactions as a NoSQL database. EN: |+| TiDB's auto sharding feature makes sharding transparent to |+| your application. EN: In addition to that, TiDB has big data capability with zero efforts. EN: |+| Zero efforts means you can ingest terabytes of data effectively by using SQL, |+| you can serve real-time analytic query in seconds by using standard |+| SQL with the help of TiFlash and no ETL is required. EN: |+| What I just pointed out are TiDB characteristics |+| now we add additional advantages because we are in the cloud this time. EN: |+| TiDB cloud is not just an on-premises TiDB deployed into the public cloud. EN: |+| It is a re-platformed database as a service, designed specifically for the cloud. EN: |+| As a managed service many ops and maintenance tasks are eliminated or automated. EN: |+| The database can store and retrieve any amount of data by horizontally |+| scaling TiKV and TiFlash nodes, to serve any level of request traffic cost effectively. EN: |+| By using TiDB Cloud, you are not locked in by the cloud service provided. EN: |+| We support both AWS and gcp as the underlying cloud providers right now. EN: |+| We provide consistent management interface and |+| user experiences no matter which provider you choose. EN: |+| Last, but not least, security and compliance are always priority zero. EN: TiDB cloud is audited and |+| certified by third parties so you can get your business started quickly and safely. EN: |+| THis diagram shows you the highlevel overview of the service architecture of TiDB Cloud. EN: |+| In the cloud provider region, |+| there is a TiDB virtual private cloud or VPC, where all TiDB nodes reside. EN: |+| TiDB central services are deployed independently along with the dashboard, |+| which allows you to access those services via the internet after authentication and authorization. EN: |+| TiDB servers are decoupled by a lot of balancing service. EN: Load balancing |+| service in the cloud are highly available and the disaster recovery capable by default. EN: |+| Your application is deployed in another VPC. EN: Through VPC peering connection provided by |+| the cloud provider, there is no need to go all the way around to the internet and back again. EN: |+| In addition to that, you can see three AZs in the cloud provider region. EN: |+| AZ stands for availability zone. EN: |+| Each AZ is comprised of at least one data center. EN: |+| The average distance between two AZs is about 20 to 30 kilometers. EN: |+| So you can easily achieve HA and the disaster recovery capability, by spinning up the SQL |+| layer and a storage layer nodes, which are the TiDB and the TiKV nodes across AZs. EN: |+| For performance management, you can scale in or scale out components nodes by clicking |+| the button on the cluster management console or calling the web service API. EN: |+| By the way I have to mention that you have to take hotspot problems into considerations. EN: |+| We cover this topic in the course named TiDB Performance tuning. EN: |+| Remember that performance issues caused |+| by hotspots can not be solved by simply scaling out your cluster. EN: |+| This concludes TiDB architecture basics. EN: |+| See you in next class.