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

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

*** 简介

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

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

国内最大的 *** 使用者是小米公司，有几个 *** 的 Committer ，所以经过一些修改后可以支持分布式事务，于是能够解决之前的问题。为什么在面临诸多选择时，小米会选择 *** 呢？就目前情况来说，主要还是技术选型和人才储备上的考虑。 *** 大家应该不陌生，但用到一定程度后，总会出现各种问题，甚至有文章呼吁大家放弃 *** 。但所有数据库都不是“十全十美”的，没有最好，选择最适合的尤为重要。

很多时候产品都有其特性，在满足其特性或者规格的情况下，使用起来可能非常顺手，否则十之八九都遇到各种麻烦。比如小米使用 *** 就非常顺手，但其他的公司则不一定。道理很简单，如果不熟悉其使用场景，也不知道在相应场景下配什么参数，所以会出现各种各样的问题。

另一方面，*** 把一部分逻辑会放在 CPU/硬件里，对应的 *** 也会把一部分逻辑下推到对应的 RegionServer 上。对于一个分布系统来说，如果需要查询一个条件，可以直接把这个简单调节推到对应的 RegionServer 上执行。再比如求和运算，现在有一百亿数据，甚至一千亿条数据，分布在10个节点上，最快的求和方法是让所有节点同时运算，将这个条件下推得到所有对应数据的和，最后收集到10个数据的和即可。其实还可以继续往下推，这是比较复杂的数据库优化技术，实际情况还会更复杂。这在 *** 里面依赖 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 语言开发的，其代码简单、易于理解，而且性能非常高。

假设Bob要转4美金给 Joe。第一步，要先转出去4美金，10美金变成6美金，由于被扣掉4美金，然后会标注一下自己是主锁。

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

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 做成中国第一个世界顶级的开源项目，实现共赢。

好的项目可以由社区进行推动，就比如 ***，*** 不属于任何一个公司，但是社区一直推动它进步。目前我们在 GitHub 状态是有 3200+的 Star，有 32个 Contributors，算是开了一个好头，非常感谢大家，希望大家都能参与进来。

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