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.