[Music] In this unit, we will talk about TiDB Cloud.

Because of the distributed and the coupled design, TiDB cluster is elastic in nature.

So the public cloud is a perfect container to host TiDB.

TiDB cloud or database as a service can use almost unlimited storage capacities and computing powers in the cloud.

In the first unit, we explained why we should choose TiDB.

TiDB has many advantages, including seamless horizontal scalability, high availability and the disaster recovery ability.

TiDB also supports standard SQL and transactions as a NoSQL database.

TiDB's auto sharding feature makes sharding transparent to your application.

In addition to that, TiDB has big data capability with zero efforts.

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.

What I just pointed out are TiDB characteristics now we add additional advantages because we are in the cloud this time.

TiDB cloud is not just an on-premises TiDB deployed into the public cloud.

It is a re-platformed database as a service, designed specifically for the cloud.

As a managed service many ops and maintenance tasks are eliminated or automated.

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.

By using TiDB Cloud, you are not locked in by the cloud service provided.

We support both AWS and gcp as the underlying cloud providers right now.

We provide consistent management interface and user experiences no matter which provider you choose.

Last, but not least, security and compliance are always priority zero.

TiDB cloud is audited and certified by third parties so you can get your business started quickly and safely.

THis diagram shows you the highlevel overview of the service architecture of TiDB Cloud.

In the cloud provider region, there is a TiDB virtual private cloud or VPC, where all TiDB nodes reside.

TiDB central services are deployed independently along with the dashboard, which allows you to access those services via the internet after authentication and authorization.

TiDB servers are decoupled by a lot of balancing service.

Load balancing service in the cloud are highly available and the disaster recovery capable by default.

Your application is deployed in another VPC.

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.

In addition to that, you can see three AZs in the cloud provider region.

AZ stands for availability zone.

Each AZ is comprised of at least one data center.

The average distance between two AZs is about 20 to 30 kilometers.

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.

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.

By the way I have to mention that you have to take hotspot problems into considerations.

We cover this topic in the course named TiDB Performance tuning.

Remember that performance issues caused by hotspots can not be solved by simply scaling out your cluster.

This concludes TiDB architecture basics.

See you in next class.