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