0 00:00:00,000 --> 00:00:08,740 [音楽] 1 00:00:08,740 --> 00:00:10,740 We have briefly gone through TiDB server. 2 00:00:10,740 --> 00:00:14,760 We have introduced its server modules and its stateless nature. 3 00:00:15,480 --> 00:00:19,020 Now let's proceed to the architecture of TiKV cluster. 4 00:00:19,020 --> 00:00:22,440 Let's dig a little deeper into key value pair domain. 5 00:00:23,340 --> 00:00:26,340 We already learned TiKV is a key value model. 6 00:00:27,060 --> 00:00:29,340 TiKV provides an order traverse method. 7 00:00:30,180 --> 00:00:35,280 Key value pairs in the map are ordered according to the binary order of the key, meaning you 8 00:00:35,280 --> 00:00:39,840 can seek the position of the key and then continuously call the next() method to get 9 00:00:39,840 --> 00:00:41,820 the larger key in increasing order. 10 00:00:42,960 --> 00:00:47,760 In order to implement horizontal scaling, storage data will be spread across multiple 11 00:00:47,760 --> 00:00:48,120 nodes. 12 00:00:49,560 --> 00:00:54,240 TiKV divides the entire KV space into many segments according to the key range. 13 00:00:54,780 --> 00:00:58,140 Each segment is a series of consecutive keys. 14 00:00:59,400 --> 00:01:01,380 A region has several segments. 15 00:01:01,380 --> 00:01:05,400 The default size of one region is 96 megabytes. 16 00:01:06,660 --> 00:01:12,600 Each region can be described as the start key and end key with left close and right 17 00:01:12,600 --> 00:01:13,560 open interval. 18 00:01:14,640 --> 00:01:16,980 Region is also a replication unit. 19 00:01:16,980 --> 00:01:20,100 Each region has its own Raft replication group. 20 00:01:20,700 --> 00:01:23,400 Just like the region 1 shown in the slide. 21 00:01:25,080 --> 00:01:27,720 Each region has its own leader and follower nodes. 22 00:01:27,720 --> 00:01:30,180 Raft is a consensus protocol. 23 00:01:31,140 --> 00:01:36,240 Raft provides several important functions, such as leader election and member change 24 00:01:36,240 --> 00:01:36,600 management. 25 00:01:38,100 --> 00:01:43,980 Concretely, Raft is responsible for adding replicas, deleting replicas, transferring 26 00:01:43,980 --> 00:01:46,380 leaders, log replication, etc. 27 00:01:47,880 --> 00:01:52,545 When TiKV uses Raft data replication, each data changed will be placed in a Raft log. 28 00:01:52,545 --> 00:01:59,220 Following Raft log replication function, the data is securely and reliably synchronized 29 00:01:59,220 --> 00:02:01,620 to each node of the replication group. 30 00:02:02,460 --> 00:02:07,380 According to the Raft protocol, it is only necessary to synchronously replicate to majority 31 00:02:07,380 --> 00:02:12,600 nodes within the Raft group to safely affirm that data has been written successfully. 32 00:02:13,160 --> 00:02:19,680 TiKV does not write a data directly to the disk, but saves the data in RocksDB, which 33 00:02:19,680 --> 00:02:21,900 is responsible for the data landing. 34 00:02:21,900 --> 00:02:26,100 RocksDB is a single instance KV storage engine, open-sourced by Facebook. 35 00:02:27,180 --> 00:02:29,940 It was forked from Google's LevelDB originally. 36 00:02:31,080 --> 00:02:36,060 RocksDB can meet various requirements from TiKV as a single instance persistent engine. 37 00:02:37,380 --> 00:02:42,720 By distributing and replicating data by region, TiKV has become a distributed key value system 38 00:02:42,720 --> 00:02:48,660 with a certain disaster recovery capability as long as the majority TiKV nodes are alive. 39 00:02:49,620 --> 00:02:53,520 Any minority node failure does not break the data consistency. 40 00:02:54,060 --> 00:02:55,740 Now it's demo time again. 41 00:02:55,740 --> 00:03:00,180 I'm going to kill my TiKV server instance in the playground and see what happens. 42 00:03:01,260 --> 00:03:03,300 Let's check the status of the playground. 43 00:03:11,580 --> 00:03:14,940 This time my target is the TiKV instance. 44 00:03:16,500 --> 00:03:19,740 Please be noted my simple applications are still running. 45 00:03:20,760 --> 00:03:24,180 Just a headsup, there are two roles in my simple applcation. 46 00:03:24,180 --> 00:03:29,940 One keeps inserting randomly generated planet data into the planet table, while the other 47 00:03:29,940 --> 00:03:32,640 keeps reading the data and does some simple calculation. 48 00:03:33,600 --> 00:03:37,740 Detailed descriptions of my simple applcation can be found in the previous lecture. 49 00:03:39,000 --> 00:03:40,860 Let me kill one TiKV instance. 50 00:03:56,040 --> 00:03:58,800 Looks like nothing happened from the application side. 51 00:03:59,520 --> 00:04:04,860 Based on this result we can tell that killing one TiKV node does not affect my application. 52 00:04:06,120 --> 00:04:08,880 This behavior benefits from two facts. 53 00:04:08,880 --> 00:04:15,480 Firstly, the default count for reading replicas in my example is three, with one TiKV node 54 00:04:15,480 --> 00:04:16,740 gone, two are still alive. 55 00:04:16,740 --> 00:04:19,080 Thus, the majority is still alive. 56 00:04:19,980 --> 00:04:24,900 According to Raft protocol, the leader is there, no matter whether it was a newly elected 57 00:04:24,900 --> 00:04:29,040 leader or not, the leader is working so the system is open for read and write. 58 00:04:29,700 --> 00:04:34,560 Secondly, because the TiDB servers decoupled communication between the client application 59 00:04:34,560 --> 00:04:36,300 and the TiKV server. 60 00:04:36,300 --> 00:04:38,580 The SQL layer in the middle actually hides 61 00:04:38,580 --> 00:04:41,640 the TiKV node failure for the front-end application. 62 00:04:42,780 --> 00:04:48,180 However, from the operation point of view, if this is a production environment you already 63 00:04:48,180 --> 00:04:54,000 received an alarm about the unfortunate change in the back end, which is one TiKV node was 64 00:04:54,000 --> 00:04:54,120 down. 65 00:04:54,900 --> 00:04:58,140 You can config to react automatically or manually. 66 00:04:58,140 --> 00:05:01,620 The most important thing is that your application feels nothing. 67 00:05:02,580 --> 00:05:08,520 I am not going to kill one more TiKV instance again, similar to what I did on TiDB instance 68 00:05:08,520 --> 00:05:08,760 before. 69 00:05:09,480 --> 00:05:13,020 Because by doing this, it will break the majority rule in Raft protocol. 70 00:05:13,020 --> 00:05:16,500 You will need database operation skills to recover the cluster. 71 00:05:17,160 --> 00:05:19,260 Remember TiKV cluster is a stateful. 72 00:05:19,260 --> 00:05:24,720 We cover TiKV cluster recovery skills in TiDB administration course in database operation 73 00:05:24,720 --> 00:05:25,440 learning path. 74 00:05:26,820 --> 00:05:30,900 Please check the training catalog on education portal website for details. 75 00:05:32,100 --> 00:05:34,440 Let's go up one level from Raft protocol. 76 00:05:34,440 --> 00:05:38,460 Let's talk about MVCC which means multiversion concurrency control. 77 00:05:40,020 --> 00:05:42,900 The version number comes from timestamp oracle. 78 00:05:42,900 --> 00:05:48,000 When a row or a key value pair is updated, both old and the new entries are stored in 79 00:05:48,000 --> 00:05:48,240 TiKV. 80 00:05:49,440 --> 00:05:53,100 Essentially it is implemented by adding the version number after the key. 81 00:05:54,000 --> 00:06:00,180 The older version entries can be used to support various scenarios like flashback query, flashback 82 00:06:00,180 --> 00:06:03,360 table, and most importantly, the concurrent operations. 83 00:06:04,560 --> 00:06:09,000 Imagine there are two sessions updating the value of a key at almost the same time. 84 00:06:10,020 --> 00:06:15,480 Please note that for timestamp oracle or TSO, there is never a concept call the same time. 85 00:06:16,560 --> 00:06:19,500 The different two changes always have different version numbers. 86 00:06:20,520 --> 00:06:23,940 However in SQL layer TiDB still has the flexibility 87 00:06:23,940 --> 00:06:27,120 to implement the pessimistic and the optimistic 88 00:06:27,120 --> 00:06:27,960 transaction lock. 89 00:06:29,040 --> 00:06:32,640 We will cover these two locks in TiDB specific features course. 90 00:06:33,900 --> 00:06:39,540 Another key feature provided by TiKV is the operator push down and the distributed SQL. 91 00:06:41,520 --> 00:06:46,200 Because of the parallel execution nature, it can improve query performance. 92 00:06:48,480 --> 00:06:53,460 As we mentioned before, TiKV nodes are workhorses for distributed SQL. 93 00:06:54,240 --> 00:06:59,520 As shown on the slide the query needs to fetch the count from all planets that are in category 94 00:06:59,520 --> 00:07:00,120 1. 95 00:07:00,120 --> 00:07:06,240 To avoid a large number of RPC calls between the TiDB and the TiKV servers, the predicate 96 00:07:06,240 --> 00:07:12,000 condition category ID equals 1 in the query will be pushed down to the storage node for 97 00:07:12,000 --> 00:07:12,600 processing. 98 00:07:13,440 --> 00:07:18,060 In addition to that, aggregate function count can also be pushed down to the storage nodes 99 00:07:18,060 --> 00:07:19,080 for pre-aggregation. 100 00:07:20,040 --> 00:07:23,400 Thus, each TiKV node only needs to return one count. 101 00:07:24,420 --> 00:07:29,940 Then, total counts are summed up by the SQL layer which is the TiDB server, so that only 102 00:07:29,940 --> 00:07:34,320 valid rows are returned and the meaningless network transfers are avoid. 103 00:07:36,000 --> 00:07:40,140 Let’s now compare TiDB's architecture with the ones of traditional databases. 104 00:07:40,140 --> 00:07:46,380 Both TiDB and many traditional monolithic, or non distributed, databases support ACID 105 00:07:46,380 --> 00:07:47,940 and strong consistency. 106 00:07:48,720 --> 00:07:51,300 However, TiDB has a distributed architecture. 107 00:07:51,300 --> 00:07:55,920 It decouples the SQL layer, storage layer and the management layer. 108 00:07:56,700 --> 00:08:01,980 Thus, TiDB is able to elastically scale in and scale out, with almost zero impact on 109 00:08:01,980 --> 00:08:02,340 your business. 110 00:08:02,340 --> 00:08:03,180 TiDB is also highly available. 111 00:08:03,180 --> 00:08:04,980 It supports automatic fail-over. 112 00:08:06,420 --> 00:08:09,840 A few failed replicas will be totally transparent to your business. 113 00:08:10,920 --> 00:08:13,140 Scaling up TiDB is also very convenient. 114 00:08:13,140 --> 00:08:17,280 There is no need to change your business logic or add sharding keys. 115 00:08:17,280 --> 00:08:21,420 TiDB is also designed to deal with highly concurrent situations. 116 00:08:21,420 --> 00:08:26,340 It can handle more concurrent reading and writing requests than traditional databases. 117 00:08:28,320 --> 00:08:31,800 Traditional databases also have some attempts to scale out. 118 00:08:32,400 --> 00:08:37,320 This slide shows one of those attempts: Multi Nodes Shared Storage Architecture. 119 00:08:38,280 --> 00:08:42,960 The high level idea of this architecture is to put existing hardwares together to act, 120 00:08:42,960 --> 00:08:45,060 as if it is a better hardware. 121 00:08:45,900 --> 00:08:47,520 It is actually not scaling out. 122 00:08:47,520 --> 00:08:49,980 It is still a means of scaling up. 123 00:08:50,940 --> 00:08:56,040 However, no matter how many nodes are configured for the cluster, the data is stored on the 124 00:08:56,040 --> 00:09:00,540 shared storage and the heartbeat in the middle is responsible for transmitting memory-level 125 00:09:00,540 --> 00:09:03,600 buffer cache as well, which is an obvious bottleneck. 126 00:09:03,600 --> 00:09:09,120 Moreover, this solution is very expensive, due to some special hardwares, such as network 127 00:09:09,120 --> 00:09:10,620 connections, are needed. 128 00:09:12,360 --> 00:09:15,000 Another more popular way is to use sharding. 129 00:09:15,600 --> 00:09:20,460 Data is put into multiple traditional databases according to the shard key. 130 00:09:21,120 --> 00:09:25,200 It is not uncommon in the real-world to have more than 50 shards of a database. 131 00:09:26,880 --> 00:09:31,860 By doing this, the database management system can no longer provide ACID properties for 132 00:09:31,860 --> 00:09:33,300 cross sharding transactions. 133 00:09:34,440 --> 00:09:39,540 The application has to implement ACID logic for cross sharding transactions by themselves. 134 00:09:40,560 --> 00:09:43,320 It is a nightmare for operations and management.