TiDB是什么，tidb数据库优缺点，TiDB 数据库的存储

本文讲述了TiDB是什么，tidb数据库优缺点，TiDB 数据库的存储

TiDB 是一款结合了传统的关系型数据库和 NoSQL 数据库特性的新型分布式数据库。

TiDB 是基于 Google 公司的 Google Spanner / F1 论文设计的开源分布式数据库，而 Spanner/F1 是 Google 公司研发的可扩展的、多版本、全球分布式、可同步复制的数据库。

TiDB 是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。因此，TiDB 在设计时也追求无限的水平扩展，具备强一致性和高可用性，支持分布式事务的处理。

同时，TiDE 的目标是为在线交易处理（OnlineTransactional Processing, OLTP）和在线分析处理（Online Analytical Processing, OLAP）场景提供一站式的解决方案，支持 MySQL 数据库的数据轻松地向 TiDB 迁移，包括分库、分表后的 MySQL 集群也可通过工具进行实时迁移。

TiDB作为分布式数据库的优点

对于现有得应用非常透明化。Tidb的原理是解析sql语句，进入自己的key-value存储单元获取数据，使得现有得应用可以平滑过渡，挂的是关系型数据库的皮，做的是NOSQL数据库的事，我们叫他不是个东...new SQL。他借用了mysql引擎，所以你直接在NAVICAT上就可以直接界面化操作啦。 可以非常快捷的伸缩，实现冷热数据的均衡。例如使用sharding-jdbc，要实现热点数据的分布存储，抛开复杂的分库分表算法不说，每次扩容对于运维人员非常繁琐。但是TIDB就不存在啦，只要扩展TiDB Server 节点增加计算能力，扩展TIKV节点增加存储能力就可以。这是一场战争，号角吹响，补兵不行补兵，传话的不够加传话的，指挥官挂了选新的。男人不能说自己不xing. 支持分布式事务，数据强一致性，百亿级存储。根据官网吹牛（shihua）逼(shishuo)说,金融级高可用。

TiDB作为分布式数据库的缺点

存储过程、触发器、事件、外键约束不支持，但是这个是人家谦（chenqie）虚的说法(zuobudao)，分布式数据库谁还用这些鸡肋玩意儿,特别是触发器。

硬件要求高，不多说的，反正就是高，你想想人家这么快肯定IO轻松不了，人家大神都说了，最好全换成***。

本文主要介绍 TiKV 的一些设计思想和关键概念

Key-Value Pairs (键值对

作为保存数据的系统，首先要决定的是数据的存储模型，也就是数据以什么样的形式保存下来。TIKV 的选择是 Key-value 模型，并且提供有序遍历方法

TikV 数据存储的两个关键点:

1.这是一个巨大的 Map (可以类比一下 C++ 的 std:map) ，也就是存储的是 Key-Value Pairs (键值对)2.这 Map 中的 Key-Value pair 按照 Key 的二进制顺序有序，也就是可以 Seek 到某一个 Key 的位置，然后不断地调用 Next 方法以涕增的顺序获取比这个 Key 大的 Key-Value。

注意，本文所说的 TKV 的 KV 存储模和 SQL 中的 Table 无关，本文不讨论 SQL 中的任何概念，专注于讨论如何实现 TIKV 这样一高性能、高可靠性、分布式的 Kev-Value 存储。

本地存储 (RocksDB

任何持久化的存情引警Q，数据终归要保存在磁盘上，TIKV 也不例外。但是 TKV 没有选择直接向磁盘上写数据，而是把数据保存在RocksDB 中，具体的数据落地由 RocksDB 负责，这个选择的原因是开发一个单机存引警工作量很大，特别是要做一个高性能的单机引，需要做各种细致的优化，而 RocksDB 是由 Facebook 开源的一个非常优秀的单机 KV 存，可以满足 TIKV 对单机引警的种要求。这里可以简单的认为 RocksDB 是一个单机的持久化 Key-Value Map.

Raft只 协议

接下来 TiKV 的实现面临一件更难的事情: 如何保证单机失效的情况下，数据不丢失，不出错?

简单来说，需要想办法把数据复制到多合机器上，这样一台机器无法服务了，其他的机器上的副本还能提供服务，复杂来说，还需要这个数据复制方案是可靠和高效的，并且处理副本失效的情况。TIKV 选择了 Rat 算法。Rat 是一人一致性协议，本文只会对 Rat做一人简要的个绍，细节问题可以参考它的论文。Raft 提供几个重要的功能:

Leader (主副本) 选举

成员变更(如添加副本、删除副本、转移 Leader 等操作)

日志复制

TIKV 利用 Rat 来做数据复制，每个数据变更都会落地为一条 Rat 日志，通过 Ra 的日志复制功能，将教据安全可靠地同步到复制组的每一个节点中。不过在实际写入中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。

总结一下，通过单机的 RocksDB，TKV 可以将数据快速地存储在磁盘上;通过 Raft，将数据复制到多台机器上，以防单机失效。数据的写入是通过 Rat 这一层的接口写入，而不是直接写 RocksDB，通过实现 Raft，TIKV 变成了一个分布式的 Key-Value 存储，少数几合机器宕机也能通过原生的 Raft 协议自动把副本补全，可以做到对业务无感知。

Region

首先，为了便于理解，在此节，假设所有的数据都只有一个副本。前面提到，TIKV 可以看做是一个巨大的有序的 KV Map，那么为了实现存储的水平扩展，数据将被分散在多台机器上。对于一个KV 系统，将数据分散在多台机器上有两种比较典型的方案:

Hash: 按照 Key 做 Hash，根据 Hash 值选择对应的存储节点

Range: 按照 Key 分 Range，某一段连续的 Key 都保存在一个存储节点上

TKkV选择了第二种方式，将整个Key-Value 空间分成很多段，每一段是一系列连续的 Key，将每一段叫做一 Region，并且会尽量保持每Redion 中保存的数据不超过一定的大小，目前在 TkV 中认是 96MB，每一个 Region 都可以用Startkey,EndKey) 这样一个左闭右开区间来描述。

注意，这里的 Region 还是和 SQL 中的表没什么关系。这里的讨论依然不涉及 SQL，只和 KV有关

将数据划分成 Region 后，TikV 将会做两件重要的事情:

以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每人节点上服务的 Region 数量差不多。以 Region 为单位做 Raft 的复制和成员管理

这两点非常重要

先看第一点，数据按照 Key 切分成很多 egion，每 Regin 的数据只会保存在一人节点上面(暂不考虑多副本)。TIDB 系统会有个组件(PD)来负责将 Region 尽可能均匀的散布在集群中所有的节点上，这样一方面实现了存储容量的水平扩展(增加新的节点后，会自动将其他节点上的 Region 调度过来)，另一方面也实现了负载均衡(不会出现某个节点有很多数据，其他节点上没什么数据的情况》。同时为了保证上层客户端能够访问所需要的数据，系统中也会有一个组件 PD)记录 Region 在节点上面的分布情况也就是通过任意一个 Key 就能查询到这个 Key 在哪个 Region 中，以及这 Redion 目前在哪个节点上(即 Key 的位置路由信息)。至于负责这两项重要工作的组件(PD)，会在后续介绍。

对于第二点，TIKV是以 Region 为单位做数据的复制，也就是一个 Reion 的数据会保存多个副本，TIKV 将每一个副本叫做一个Replica。Redlica 之间是时 Raf 来保持数据的一致，一Redion 的多人 Redlica 会保存在不同的节点上，构成一人Rat Grou其中一人 Replica 会作为这 Group 的Leader,其他的 Replica 作为 Follower，默认情况下，所有的读和写都是通过 Leader进行，读操作在 Leader 上即可完成，而写操作再由 Leader 复制给 Follower.

大家理解了 Region 之后，应该可以理解下面这张图!

以 Region 为单位做数据的分散和复制，TIKV 就成为了一个分布式的具备一定容灾能力的 KeValue 系统，不用再担心数据存不下，或者是磁盘故障丢失数据的问题

MVCC

很多教据库都会实现多版本并发控制 (MVCC)，TIKV 也不例外。设想这样的场景:两个客户端同时去修改一个 Key 的 Value，如果没有数据的多版本控制，就需要对数据上锁，在分布式场景下，可能会带来性能以及死锁问题。TIKV 的 MVCC 实现是通过在 Key 后面添加版本号来实现，简单来说，没有 MVCC 之前，可以把 TiKV 看做这样的:

注意，对于同一个 Key 的多个版本，版本号较大的会被放在前面，版本号小的会被放在后面(见 KeyValue 一节，Key 是有序的排列)，这样当用户通过一个 Key + Version 来获取 Value 的时候，可以通过 Key 和 Version 构造出 MVCC 的 Key,也就是Key Version，然后可以直接通过 RocksDB 的 SeekPrefix(Key Version)APl，定位到第-人大于等于这 Key Version 的位置。

上文就是小编为大家整理的TiDB是什么，tidb数据库优缺点，TiDB 数据库的存储。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。