EN: |+| [Music] We have briefly gone through TiDB server. EN: |+| We have introduced its server modules and its stateless nature. EN: |+| Now let's proceed to the architecture of TiKV cluster. EN: |+| Let's dig a little deeper into key value pair domain. EN: |+| We already learned TiKV is a key value model. EN: |+| TiKV provides an order traverse method. EN: |+| Key value pairs in the map are ordered according to the binary order of the key, meaning you |+| can seek the position of the key and then continuously call the next() method to get |+| the largest key in increasing order. EN: |+| In order to implement horizontal scaling, storage data will be spread across multiple |+| nodes. EN: |+| TiKV divides the entire KV space into many segments according to the key range. EN: |+| Each segment is a series of consecutive keys. EN: |+| A region has several segments. EN: |+| The default size of one region is 96 megabytes. EN: |+| Each region can be described as the start key and end key with left close and right |+| open interval. EN: |+| Region is also a replication unit. EN: |+| Each region has its own Raft replication group. EN: |+| Just like the region 1 shown in the slide. EN: |+| Each region has its own leader and follower nodes. EN: |+| Raft is a consistency protocol. EN: |+| Raft provides several important functions, such as leader election and member change |+| management. EN: |+| Concretely, Raft is responsible for adding replicas, deleting replicas, transferring |+| leaders, log replication, etc. EN: |+| When TiKV uses Raft data replication, each data changed will be placed in a Raft log. EN: |+| Following Raft log replication function, the data is securely and reliably synchronized |+| to each node of the replication group. EN: |+| According to the Raft protocol, it is only necessary to synchronously replicate to majority |+| nodes within the Raft group to safely affirm that data has been written successfully. EN: |+| TiKV does not write a data directly to the disk, but saves the data in RocksDB, which |+| is responsible for the data landing. EN: |+| RocksDB is a single instance KV storage engine, open-sourced by Facebook. EN: |+| It was folked from Google's LevelDB originally. EN: |+| RocksDB can meet various requirements from TiKV as a single instance persistent engine. EN: |+| By distributing and replicating data by region, TiKV has become a distributed key value system |+| with a certain disaster recovery capability as long as the majority TiKV nodes are alive. EN: |+| Any minority node failure does not break the data consistency. EN: |+| Now it's demo time again. EN: |+| I'm going to kill my TiKV server instance in the playground and see what happens. EN: |+| Let's check the status of the playground. EN: |+| This time my target is the TiKV instance. EN: |+| Please be noted my simple applications are still running. EN: |+| Just a headsup, there are two roles in my simple applcation. EN: |+| One keeps inserting randomly generated planet data into the planet table, while the other |+| keeps reading the data and does some simple calculation. EN: |+| Detailed descriptions of my simple applcation can be found in the previous lecture. EN: |+| Let me kill one TiKV instance. EN: |+| Looks like nothing happened from the application side. EN: |+| Based on this result we can tell that killing one TiKV node does not affect my application. EN: |+| This behavior benefits from two facts. EN: |+| Firstly, the default count for reading replicas in my example is three, with one TiKV node |+| gone, two are still alive. EN: |+| Thus, the majority is still alive. EN: |+| According to Raft protocol, the leader is there, no matter whether it was a newly elected |+| leader or not, the leader is working so the system is open for read and write. EN: |+| Secondly, because the TiDB servers decoupled communication between the client application |+| and the TiKV server. EN: |+| The SQL layer in the middle actually hides |+| the TiKV node failure for the front-end application. EN: |+| However, from the operation point of view, if this is a production environment you already |+| received an alarm about the unfortunate change in the back end, which is one TiKV node was |+| down. EN: |+| You can config to react automatically or manually. EN: |+| The most important thing is that your application feels nothing. EN: |+| I am not going to kill one more TiKV instance again, similar to what I did on TiDB instance |+| before. EN: |+| Because by doing this, it will break the majority rule in Raft protocol. EN: |+| You will need database operation skills to recover the cluster. EN: |+| Remember TiKV cluster is a stateful. EN: |+| We cover TiKV cluster recovery skills in TiDB administration course in database operation |+| learning path. EN: |+| Please check the training catalog on education portal website for details. EN: |+| Let's go up one level from Raft protocol. EN: |+| Let's talk about MVCC which means multiversion concurrency control. EN: |+| The version number comes from timestamp oracle. EN: |+| When a row or a key value pair is updated, both old and the new entries are stored in |+| TiKV. EN: |+| Essentially it is implemented by adding the version number after the key. EN: |+| The older version entries can be used to support various scenarios like flashback query, flashback |+| table, and most importantly, the concurrent operations. EN: |+| Imagine there are two sessions updating the value of a key at almost the same time. EN: |+| Please note that for timestamp oracle or TSO, there is never a concept call the same time. EN: |+| The different two changes always have different version numbers. EN: |+| However in SQL layer TiDB still has the flexibility |+| to implement the pessimistic and the optimistic |+| transaction lock. EN: |+| We will cover these two locks in TiDB specific features course. EN: |+| Another key feature provided by TiKV is the operator push down and the distributed SQL. EN: |+| Because of the parallel execution nature, it can improve query performance. EN: |+| As we mentioned before, TiKV nodes are workhorses for distributed SQL. EN: |+| As shown on the slide the query needs to fetch the count from all planets that are in category |+| 1. EN: |+| To avoid a large number of RPC calls between the TiDB and the TiKV servers, the predicate |+| condition category ID equals 1 in the query will be pushed down to the storage node for |+| processing. EN: |+| In addition to that, aggregate function count can also be pushed down to the storage nodes |+| for pre-aggregation. EN: |+| Thus, each TiKV node only needs to return one count. EN: |+| Then, total counts are summed up by the SQL layer which is the TiDB server, so that only |+| valid rows are returned and the meaningless network transfers are avoid. EN: |+| Let’s now compare TiDB's architecture with the ones of traditional databases. EN: |+| Both TiDB and many traditional monolithic, or non distributed, databases support ACID |+| and strong consistency. EN: |+| However, TiDB has a distributed architecture. EN: |+| It decouples the SQL layer, storage layer and the management layer. EN: |+| Thus, TiDB is able to elastically scale in and scale out, with almost zero impact on |+| your business. EN: |+| TiDB is also highly available. EN: |+| It supports automatic fail-over. EN: |+| A few failed replicas will be totally transparent to your business. EN: |+| Scaling up TiDB is also very convenient. EN: |+| There is no need to change your business logic or add sharding keys. EN: |+| TiDB is also designed to deal with highly concurrent situations. EN: |+| It can handle more concurrent reading and writing requests than traditional databases. EN: |+| Traditional databases also have some attempts to scale out. EN: |+| This slide shows one of those attempts: Multi Nodes Shared Storage Architecture. EN: |+| The high level idea of this architecture is to put existing hardwares together to act, |+| as if it is a better hardware. EN: |+| It is actually not scaling out. EN: |+| It is still a means of scaling up. EN: |+| However, no matter how many nodes are configured for the cluster, the data is stored on the |+| shared storage and the heartbeat in the middle is responsible for transmitting memory-level |+| buffer cache as well, which is an obvious bottleneck. EN: |+| Moreover, this solution is very expensive, due to some special hardwares, such as network |+| connections, are needed. EN: |+| Another more popular way is to use sharding. EN: |+| Data is put into multiple traditional databases according to the shard key. EN: |+| It is not uncommon in the real-world to have more than 50 shards of a database. EN: |+| By doing this, the database management system can no longer provide ACID properties for |+| cross sharding transactions. EN: |+| The application has to implement ACID logic for cross sharding transactions by themselves. EN: |+| It is a nightmare for operations and management.