[Music] In this unit, we will be talking about the overall architecture of TiDB. The core components of TiDB database, in short TiDB, is composed of three server clusters. All of which communicate with each other to form a database cluster. The components include TiDB server cluster TiKV server cluster and the placement driver or PD cluster. All three sub-clusters are decoupled with each other. The number of TiDB servers does not have to be equal to the number of TiKV servers and does not have to be equal to the number of PD servers. For example, you can have two TiDB servers, three PD servers, and six TiKV servers. The first server cluster I would like to discuss about is TiDB server cluster. Do not be confused between TiDB and TiDB server cluster. The TiDB server cluster is a component, a sub-cluster of TiDB. The TiDB sub-cluster which represents SQL layer exposes the connection endpoint of MySQL protocol. TiDB server instance was in the cluster that are responsible for accepting connections from the database clients. The TiDB server cluster is stateless, and in practice multiple instances of TiDB server can be launched. And an unified DNS name can be provided through a load balancing component such as LVS, HAProxy or F5 BIG-IP. If you are in the public cloud, the Elastic Load Balancing service provided by the cloud service providers also works. Thus, client connections can be evenly distributed across multiple TiDB server instances without explicit efforts in your application. The TiDB servers do not actually store the table data, it only parses SQL statements and forwards a data request to the storage layer which is TiKV cluster. The second sub-cluster I would like to discuss about is PD or placement driver server cluster. It is the metadata management module for the entire TiDB which stores the real-time data distribution of each TiKV node and the overall topology configuration of TiDB. It generates the transaction ID for distributed transactions which is based on the TSO or timestamp Oracle. TSO is a timestamp to guarantee that two changes happen within a database in a temporal sequential order even though the database is a distributed database. PD not only stores metadata, it also issues data scheduling commands to specific TiKV nodes based on data distribution that is reported in real-time by TiKV nodes. PD is considered to be the brain of the entire cluster. As the cluster is backed by Raft algorithm, PD needs to be deployed to an odd number nodes. It is usually recommended to deploy three nodes at least. As long as the majority nodes are alive your cluster is open for reads and write operations. The last sub-cluster, the TiKV cluster, is responsible for storing table data. From an external view, TiKV is a distributed transactional key-value NoSQL database. TiKV also uses Raft algorithm for replication to ensure data consistency and disaster recovery. The load balancing of the data placement among different TiKV nodes is scheduled by PD, the brain of the cluster. I'm going to show you a single example similar to the steps shown on the slides so that you can have a basic understanding of how TiKV stores data. I'm going to use the TiUP command line tool to launch a Playground sandbox on my local machine. Once the TiDB is up and running, I will use the Raw KV API to do simple put/get operations to show you that TiKV is a key-value store. The script itself is pretty intuitive, it calls TiUP to spin up a whole TiDB system tagged with the name classroom. We deployed three TiDB instances, three PD instances and three TiKV instances and one TiFlash instance. Let's set aside the TiFlash instance for now. We'll cover TiFlash later in this course. And, no worries if you don't have TiUP right now. You will have TiUP installed after lab 1 at the end of this course. So, let's do it. You can see that PD is up, then TiKV and TiDB are getting up. In a real world production environment, you can spin up these servers on different nodes. Please note that the Playground is just a sandbox for testing purposes only. Okay, it's all ready by now. You can see that we use a Raw client to build a connection. The endpoints we are using are from PD. We simply put and get a new key-value pair. And then, let's try to get a value from a non-existing key. Let's see what happens. That is what we expected, right? We can actually put key-value pairs into TiKV. And, we can get value from key 1, but not from non-existing key, key 0. So, this is the first time and the last time we use Raw KV interface for this course. After that, throughout this course the only language you will use to communicate with TiDB will be SQL.