TiDB：支持 MySQL 协议的分布式数据库解决方案

【编者按】TiDB 是国内 PingCAP 团队开发的一个分布式 SQL 数据库。其灵感来自于 Google 的 F1，TiDB 支持包括传统 RDBMS 和 NoSQL 的特性。在国内 ITOM 管理平台 OneAPM 举办的技术公开课中，TiDB 的高级工程师刘奇从 HBase 特性、TiDB 的优点和系统架构等方面进行了详细阐述。如下为演讲整理：

HBase 简介

众所周知，在 SQL 方面处于顶级的有两个公司，一个是 Oracle，他们已经积累了大量的经验，另外一个是谷歌，谷歌 F1 在2012年发布了一篇论文，我的认为它是全球最优秀的 SQL OLTP 数据库。

1978年左右，数据库刚刚发展时出现了SQL RDBMS。2000年左右，国内开始流行互联网，互联网对 Oracle 数据库也产生较大的冲击。如今，传统的数据库大部分是集中在传统领域，互联网方面用得比较多的是 MySQL ，其次 HBase 等 NoSQL 也吸引了大量的用户。

为何会出现 NoSQL？最开始全部人都用 SQL Database，那时比较高端有 Oracle，开源的还有 MySQL、PostgreSQL。但是随着业务的迅速发展，数据库成为了瓶颈，因而促使了 NoSQL 的诞生，NoSQL 将 Scale 放在第一位。若是业务快速发展，扩容会成为亟待解决的首要问题。这时，大多数人会选择放弃事务一致性。什么是一致性？好比使用微信时，若是我加你为好友，这是一个双向关系，对应到数据库中至少是两个操做，第一是在好友列表里把你加进来，第二个是你的好友列表里把我加进去。若是这两个列表的数据库放在不一样的机器上，就须要保证一致性。不然可能会出现我是你的好友，但你的好友中却找不到个人这种状况。但这中间可能会出现多种状况，好比我把你加为好友，而后修改数据的时候 Crush 掉了，这个时候传统方案是会引入一个消息队列，有的还须要作一些补偿，这些问题在 NoSQL 里处理起来相对麻烦。

国内最大的 HBase 使用者是小米公司，有几个 HBase 的 Committer ，因此通过一些修改后能够支持分布式事务，因而可以解决以前的问题。为何在面临诸多选择时，小米会选择 HBase 呢？就目前状况来讲，主要仍是技术选型和人才储备上的考虑。 MongoDB 你们应该不陌生，但用到必定程度后，总会出现各类问题，甚至有文章呼吁你们放弃 MongoDB 。但全部数据库都不是“十全十美”的，没有最好，选择最适合的尤其重要。

不少时候产品都有其特性，在知足其特性或者规格的状况下，使用起来可能很是顺手，不然十之八九都遇到各类麻烦。好比小米使用 HBase 就很是顺手，但其余的公司则不必定。道理很简单，若是不熟悉其使用场景，也不知道在相应场景下配什么参数，因此会出现各类各样的问题。

事实上，HBase 有很是好的特性，目前在小米公司能够每秒跑一百万 OPS ，最近 Pinterest 公布他们的 HBase 每秒能够跑三百万个 OPS ，这个数量级能够远超不少互联网公司。 HBase 在读写一致性方面很是出色，有很好的自动 Scale 的能力，经过Block Cache 和 Bloom Filters能够很好的解决查询问题，是否在磁盘上也能够经过Bloom Filters来断定。

另外一方面，Oracle 把一部分逻辑会放在 CPU/硬件里，对应的 HBase 也会把一部分逻辑下推到对应的 RegionServer 上。对于一个分布系统来讲，若是须要查询一个条件，能够直接把这个简单调节推到对应的 RegionServer 上执行。再好比求和运算，如今有一百亿数据，甚至一千亿条数据，分布在10个节点上，最快的求和方法是让全部节点同时运算，将这个条件下推获得全部对应数据的和，最后收集到10个数据的和便可。其实还能够继续往下推，这是比较复杂的数据库优化技术，实际状况还会更复杂。这在 HBase 里面依赖 Coprocessor 来实现。

你们应该对 MVCC 比较熟悉，也就是多版本，它的优势在于能够屡次读取而不会 block。而后还有一个很好的特性，假设你用的 Database ，MVCC 在你没有作 compaction 以前能够回到任什么时候间的数据。如今云服务上也能够每隔半小时作一次快照，实际上若是使用 MVCC 回到任意一秒的话，能够彻底不须要快照。

TiDB的优点

下面再介绍一下咱们的产品 TiDB，Ti 是元素周期表里的元素。你们若是了解咱们团队的程序员，就知道他们都比较 Geek，取名字要么在希腊神话里选一个神的名字，或者在数学里找一个希腊字母， 可是看了一圈，好坑都已经被占上了。因而，咱们在化学元素周期表里找了一个金属做为项目名称，对于 Database 而言，它必须是高速稳定的，恰好钛金属有很强的防腐蚀性，因此选择了钛（Ti）。

由于 TiDB 的目标是谷歌 F1，因此天然会知足以上特性。首先是能够知足分布式一致，也就是说对于应用来讲，不用关心后面分红多少个机器，事务的一致性是必须保证的，好比咱们以前提到的 A 关注 B，两个互相加好友或者转账，能够直接利用一条 SQL 搞定，而无需担忧中间过程。另一个特性是兼容 MySQL 协议，国内大概有70% 的互联网公司都在使用 MySQL，为了考虑你们的迁移成本，咱们会兼容 MySQL 协议。同时，因为已经不少 APP 在 MySQL 上运行，为咱们提供了充足的测试样本。 TiDB 的测试有五百多万个，每次提交一行代码时，后面大概有6个机器并行地跑 Test ，五百多万 Test 所需时间大约是十分钟。为了照顾各类引擎爱好者，咱们还支持了 LevelDB 、RocksDB、LMDB、BoltDB 等。TiDB 主要是采用 Go 语言开发的，其代码简单、易于理解，并且性能很是高。

系统架构

任何用 MySQL 协议写的程序均可以直接使用 TiDB ，其中间是 MySQL 协议相关的内容，再往下是 SQL Layer。其次是事务 KV 层，这正是 F1 和 Spanner 构造得最为精密的地方。最底层的构造是从 KV 开始，在 KV 基础上架一个分布式的 KV 层用于支持事务，而后再让 SQL 语句直接映射到 KV 层上。

接下来，向你们介绍 现阶段 TiDB 使用的分布式事务是如何在 HBase 上实现的，早期版本中，咱们参考的是 Google 的 Percolator 的模型。首先假设有一个 Client，先为其分配一个 Timestamp，在 Google 论文中叫作Time Oracle，用来分配时间戳。分配以后能够作读写操做，根据时间戳进行快照读。最后提交以前要先 Prepare ，Prepare的时候会检测是否冲突，最后提交时会获得 Commit ，若是整个过程没有任何冲突就能够提交。

上图表明了一个实例，最初账户状况是 Bob 有10美金，而 Joe 有5美金。前面的数字表明其版本，当前是第6个版本，指向的是第5个版本，为10美金，Joe 是2美金。

假设Bob要转4美金给 Joe。第一步，要先转出去4美金，10美金变成6美金，因为被扣掉4美金，而后会标注一下本身是主锁。

Joe当前是第7个版本，由于他获得了4美金，因此余额变成了6美金，同时标记本身指向另一个主锁 Bob。

到第八个版本时，主锁会指向如今的7，这时能够把主锁删掉。若是访问的时候发现主锁被删除，那么主锁冲突已不存在，能够进行提交。同时，它会把本身的锁删掉，中间还有一些其它的清理过程。

整个事务模型中会有单点，从 Time Oracle 分配一个时间戳，单点决定了整个系统的性能。Google 论文里有一个对应描述，能够跑到两百万每秒。由于事务开始和结束的时候都须要取一个 Timestamp ，因此他们最快读写事务的速度是一百万每秒，他们已经在论文中实现。实际上，如今有更好的方式能够提升速度，如 HLC 和一些 Time Oracle的改进算法。

关于 Spanner ，咱们重点参考对象是谷歌 Spanner 和 F1 。因为 Spanner 高度依赖于时钟，因此谷歌有一套原子钟和 GPS 时钟，GPS 信号能够给出地理位置和时间。为何须要原子钟呢？因为 GPS 时钟特别容易受到干扰，好比天气恶劣时 GPS 时钟就不能运行，而原子钟仍然适用。

上图是谷歌 F1 的一些信息，其中单独标记了谷歌 F1 的这篇论文，你们有兴趣的话不妨细读一番，目前整个 TiDB 所作的都是在实现这篇论文。假设有一千亿数据，你如今要给某一列加索引时，在传统数据库上应该如何操做？好比说在分布式环境下，你用MySQL 给一列添加一个索引，这几乎很难实现，并且还必须保证 index 的一致性。更多细节请参考论文。

TiDB 是如何从 SQL 迁移到 KV 上的呢？由基础知识可知，传统的 RDBMS 数据库底下通常是一个 B-Tree。对于分布式关系型数据库，站在更上层一点看，好比谷歌的F1，数据库底层都是 KV 层，都在 KV 层逻辑下操做。若是有一个 User Table，在 TiDB 里假设你的Table的结构是由 uid、name和 email 构成。在 TiDB 里有一个隐藏列叫作 RowID ，全部的操做包括行锁都是锁的 RowID 。假设 RowID 是1， uid 是XX，Name 是 Bob，Email 是 bob@Email.com，这都属于元信息。即使你的 Column name 很长，但最后在数据库里存储的是原信息。在 TiDB 中， 每一列都有惟一的UID。

假设 Table 的 ID 是1，uid 的 ID 是2，name 的ID是3，email 的 ID 是4。在数据库中存储为一个 KV 结构，而后对 TableID、RowID 、ColumnID 进行从新编码，直接将这个表的一行切成4个 KV 。这时候若是进行 select ， Email 等于某一个值的话，因而能够直接取出来相应的值，速度很是快。

兼容 MySQL

TiDB 对 MySQL 协议有很好的兼容性。有一些比较知名的 MySQL 应用和管理工具，好比WordPress、PhpMyAdmin， MySQL Workbench，均可以直接基于 TiDB 运行。并且数据能够无限扩展，再也不是单机数据库。其次，TiDB 还兼容各类 ORM ，好比 XORM 、Beego ORM 等，可以支持不少 MySQL 的应用。每一次代码更新，这些 ORM Test 会自动运行一次，从而保证与 MySQL 的兼容性，虽然还有一些比较细微的特性暂时没有支持。如今已经支持异步的 Schema 变动，对于 DDL 操做，不会阻塞线上的业务。

关于社区

目前 TiDB 彻底开源在 Github 上面。开源和开放的概念是两回事，不少大公司，所谓的开源只是把代码上传一下，国内比较知名的案例也挺多的，你们知道不少项目都已经放弃了维护。可是咱们是打算彻底以一个开放的心态来作整个事情，所有的代码，所有的讨论， Code Review，Bug Tracking，Roadmap 都是开源的，毕竟通用的分布式 OLTP 关系型数据库是一个很是前沿并且极端重要的领域，将来是云上的 DBaaS 的重要组成部分，可是在这块目前整个技术社区，即便全球来看都没有一个太成熟开源解决方案，TiDB也目前也处于早期，从架构上来看，咱们将 SQL 层和 KV 层作了很完全的分离，这也是咱们但愿更多开发者能根据本身的须要更方便的进行定制，咱们也想得很清楚，依靠某一家公司，或者某几我的的力量是不够的，咱们 PingCAP 只是将这一把火点起来，将框架搭好，制定好透明和公平的规则，吸引更多的合做公司和独立开发者，一块儿将 TiDB 作成中国第一个世界顶级的开源项目，实现双赢。

好的项目能够由社区进行推进，就好比 HBase，HBase 不属于任何一个公司，可是社区一直推进它进步。目前咱们在 GitHub 状态是有 3200+的 Star，有 32个 Contributors，算是开了一个好头，很是感谢你们，但愿你们都能参与进来。

本文系国内 ITOM 行业领军企业 OneAPM 工程师整理。OneAPM 致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，经过一个探针就可以完成日志分析、安全防御、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多技术文章，请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客