0 00:00:06,960 --> 00:00:08,840 [Music] 1 00:00:08,960 --> 00:00:12,840 In this unit, we will be talking about the overall architecture of TiDB. 2 00:00:14,340 --> 00:00:21,180 The core components of TiDB database, in short TiDB, is composed of three server clusters. 3 00:00:21,900 --> 00:00:29,820 All of which communicate with each other to form a database cluster. The components include 4 00:00:29,820 --> 00:00:36,060 TiDB server cluster TiKV server cluster and the placement driver or PD cluster. 5 00:00:36,660 --> 00:00:43,860 All three sub-clusters are decoupled with each other. The number of TiDB servers does not have 6 00:00:43,860 --> 00:00:50,760 to be equal to the number of TiKV servers and does not have to be equal to the number of PD servers. 7 00:00:51,360 --> 00:00:58,920 For example, you can have two TiDB servers, three PD servers, and six TiKV servers. The 8 00:00:58,920 --> 00:01:06,180 first server cluster I would like to discuss about is TiDB server cluster. Do not be confused between 9 00:01:06,180 --> 00:01:12,720 TiDB and TiDB server cluster. The TiDB server cluster is a component, a sub-cluster of TiDB. 10 00:01:13,860 --> 00:01:20,100 The TiDB sub-cluster which represents SQL layer exposes the connection endpoint of MySQL protocol. 11 00:01:21,060 --> 00:01:25,800 TiDB server instance was in the cluster that are responsible for accepting connections from the 12 00:01:25,800 --> 00:01:31,320 database clients. The TiDB server cluster is stateless, and in practice multiple 13 00:01:31,320 --> 00:01:37,380 instances of TiDB server can be launched. And an unified DNS name can be provided through a 14 00:01:37,380 --> 00:01:46,020 load balancing component such as LVS, HAProxy or F5 BIG-IP. If you are in the public cloud, 15 00:01:46,020 --> 00:01:53,940 the Elastic Load Balancing service provided by the cloud service providers also works. Thus, client 16 00:01:53,940 --> 00:01:59,340 connections can be evenly distributed across multiple TiDB server instances without explicit 17 00:01:59,340 --> 00:02:06,900 efforts in your application. The TiDB servers do not actually store the table data, it only parses 18 00:02:06,900 --> 00:02:12,480 SQL statements and forwards a data request to the storage layer which is TiKV cluster. 19 00:02:12,480 --> 00:02:19,860 The second sub-cluster I would like to discuss about is PD or placement driver server cluster. 20 00:02:20,700 --> 00:02:25,800 It is the metadata management module for the entire TiDB which stores the real-time data 21 00:02:25,800 --> 00:02:31,500 distribution of each TiKV node and the overall topology configuration of TiDB. 22 00:02:32,340 --> 00:02:38,040 It generates the transaction ID for distributed transactions which is based on the TSO or 23 00:02:38,040 --> 00:02:43,920 timestamp Oracle. TSO is a timestamp to guarantee that two changes happen within 24 00:02:43,920 --> 00:02:49,620 a database in a temporal sequential order even though the database is a distributed database. 25 00:02:51,120 --> 00:02:58,500 PD not only stores metadata, it also issues data scheduling commands to specific TiKV nodes based 26 00:02:58,500 --> 00:03:06,960 on data distribution that is reported in real-time by TiKV nodes. PD is considered to be the brain of 27 00:03:06,960 --> 00:03:13,140 the entire cluster. As the cluster is backed by Raft algorithm, PD needs to be deployed 28 00:03:13,140 --> 00:03:18,120 to an odd number nodes. It is usually recommended to deploy three nodes at least. 29 00:03:19,020 --> 00:03:24,960 As long as the majority nodes are alive your cluster is open for reads and write operations. 30 00:03:28,260 --> 00:03:33,420 The last sub-cluster, the TiKV cluster, is responsible for storing table data. 31 00:03:33,960 --> 00:03:39,360 From an external view, TiKV is a distributed transactional key-value NoSQL database. 32 00:03:40,800 --> 00:03:47,640 TiKV also uses Raft algorithm for replication to ensure data consistency and disaster recovery. 33 00:03:49,380 --> 00:03:54,900 The load balancing of the data placement among different TiKV nodes is scheduled by PD, 34 00:03:54,900 --> 00:04:01,380 the brain of the cluster. I'm going to show you a single example similar to the steps 35 00:04:01,380 --> 00:04:07,020 shown on the slides so that you can have a basic understanding of how TiKV stores data. 36 00:04:07,920 --> 00:04:13,020 I'm going to use the TiUP command line tool to launch a Playground sandbox on my local machine. 37 00:04:14,280 --> 00:04:20,220 Once the TiDB is up and running, I will use the Raw KV API to do simple put/get operations 38 00:04:20,220 --> 00:04:28,380 to show you that TiKV is a key-value store. The script itself is pretty intuitive, it calls TiUP 39 00:04:28,380 --> 00:04:34,980 to spin up a whole TiDB system tagged with the name classroom. We deployed three TiDB instances, 40 00:04:35,700 --> 00:04:42,660 three PD instances and three TiKV instances and one TiFlash instance. Let's set aside the TiFlash 41 00:04:42,660 --> 00:04:48,540 instance for now. We'll cover TiFlash later in this course. And, no worries if you don't have 42 00:04:48,540 --> 00:04:54,180 TiUP right now. You will have TiUP installed after lab 1 at the end of this course. So, let's do it. 43 00:05:00,540 --> 00:05:06,960 You can see that PD is up, then TiKV and TiDB are getting up. In a real 44 00:05:06,960 --> 00:05:12,720 world production environment, you can spin up these servers on different nodes. Please note 45 00:05:12,720 --> 00:05:18,240 that the Playground is just a sandbox for testing purposes only. Okay, it's all ready by now. 46 00:05:23,880 --> 00:05:28,120 You can see that we use a Raw client to build a connection. The 47 00:05:29,760 --> 00:05:38,160 endpoints we are using are from PD. We simply put and get a new key-value pair. 48 00:05:39,300 --> 00:05:45,180 And then, let's try to get a value from a non-existing key. Let's see what happens. 49 00:05:51,420 --> 00:05:58,260 That is what we expected, right? We can actually put key-value pairs into TiKV. 50 00:05:58,260 --> 00:06:04,080 And, we can get value from key 1, but not from non-existing key, key 0. 51 00:06:04,980 --> 00:06:12,240 So, this is the first time and the last time we use Raw KV interface for this course. After that, 52 00:06:12,240 --> 00:06:18,000 throughout this course the only language you will use to communicate with TiDB will be SQL.