开源分布式数据库SequoiaDB在去哪儿网的实践

编者注：

中国的数据库行业也迎来了一波新的热点事件。分布式数据库这块新消息不断，也让你们开始关注中国的分布式数据库。首先是短短一周内，Pingcap和SequoiaDB巨杉数据库陆续宣布了C轮的数千万美圆融资，融资的消息在数据库和IT圈成功“刷屏”。此后，在杭州的云栖大会上，蚂蚁金服的Oceanbase也发布了 2.0。对于这些新消息，也侧面反映了国产的开源分布式数据库发展的迅速。那么这些国产分布式数据库，在互联网行业中的实践与使用上是如何呢？与传统开源数据库的对好比何？就由这篇文章做为去哪儿网这边的实践介绍。

 

引言：开源数据库百花齐放新时代

MySQL目前是全球最流行，用户最多的开源数据库这是无可非议的事实。而同时，开源数据库PostgreSQL也一直在不断发展壮大，固然还包括众多的新一代NoSQL、NewSQL数据库不断涌现。

 

此前，本人有幸参与“MariaDB/MySQL vs PostgreSQL世纪大决战”，现场火药味十足。做为为MySQL战队的一员，我我的认为，“大决战”可能并不许确，更多的应该是碰撞，由于有史以来，在数据库界，两家不一样数据库被摆到台上公开对标，他们应该是第一次走得这么近，我担忧的是，这样的现象之后还会不会出现。

 

其实技术自己都是好的，我我的认为，咱们应该本着“百花齐放、百家争鸣”的态度来学习，来使用。若是没有PostgreSQL，也许MySQL不会有如今这么好的口碑，固然反过来，若是没有了MySQL，PostgreSQL也亦由于找不到对手而感受孤独很多。一家是“The world's most advanced open source database”，另外一家是“The world's most popular open source database”，他们原本就应该相互学习，相互进步，因此这样的“碰撞”，之后应该还会再有，期待下一届“开源数据库大会”的到来。

 

MySQL是不是惟一选择？

 

如今的事实是，MySQL确实如其所述，是“most popular”的开源数据库，而PostgreSQL确实作到了“most advanced”，这点在“世纪大决战”中也体现的淋漓尽致，作为“most advanced”的数据库PostgreSQL，不免显得有点高(级)冷(清)，由于相比“most popular”的MySQL而言，用户确实少多了。MySQL在“popular”方面，作得确实不错，很是成功。由于正如你们所看到的，只要用到了数据库，绝大多数都会考虑MySQL，由于这个问题仍是和个人观念比较契合的，因此我认为，任何结果，都是有其深层次的缘由的，MySQL的popular，缘由可能有如下几点：

 

1. 开源，这个可能无需多提，这个相比PostgreSQL，他没有优点，由于PostgreSQL也是开源的。

2. 简单，MySQL入门能够说是很是简单的，这个你们应该都有感觉，只要想用数据库，除了使用access以外，MySQL可能就是不二之选了。

3. 插件式，插件式也是两面性的，一方面限制了他的发展；另外一方面，灵活，功能强大，由于有不少插件能够本身选择，应用自如，而用户看重更多的是后者。

4. 先入为主，在PostgreSQL想要流行起来的时候，MySQL已经流行起来了。

5. 互联网大公司推进，在去O大潮中，由于上面的缘由，大型互联网公司的推进，首选的是MySQL，致使了MySQL的快速发展。

 

缘由有不少，如今的结果是，MySQL确实太火了，而且再加上MGR的出现，“用MGR完事”，也许真的是这样。

 

但MySQL也有其缺点，那就是他的存储都是单点。这固然也是大型通用数据库的通病，通常都须要经过多点冗余来实现数据的高可用、高性能，但若是数据量再大了，即超出单盘容量（目前PCIe SSD卡最大容量达到12.8T）以后，MySQL可能就出现瓶颈了，固然这也是有解的。

 

咱们去哪儿的解决办法，一般都是在业务上面拆分，好比总数据量是20T，那就拆10个集群，每一个集群都是2T的数据量，这样就能够解决存储的问题了，固然这都是从业务逻辑上面解决的，须要加上路由表来控制数据的存储节点位置。这样的解决办法，虽然能够解决问题，可是当下可能更多人想要的是一个更advanced的解决方案，即如今很火的分布式数据库。

 

理想中的解决方案是，咱们无需关心数据存储，咱们只须要向一个节点上写入，或者从一个节点上读取便可。不但数据量能够为任意大小，当这个节点挂了，咱们还能够随时启动另外一个节点“顶上”便可实现故障转移，这样就实现了真正的“云存储”。在这样的“云存储”中，咱们不须要关心其高可用、多副本、容量、性能等问题，也不须要关心是否是存在多点写入，读写节点能够随时扩展，也许这样才是咱们心目中的分布式。

 

因此从这点来看，MGR仍是存在单盘的问题，并不能解决数据量极大状况下的分布式问题。

 

 

分布式数据库

那有没有比较好的，相似咱们心目中的分布式数据库呢，我想是有的，至少是向这个方向在走。去哪儿网也一直在探索，因此个人要求基本有如下几点：

 

1. 要兼容MySQL，由于本人就是MySQL重度研究与使用者，高度承认MySQL这个数据库的架构及使用方式等（中毒已深）。兼容MySQL这个要求，实际上是很是高的，咱们每一个人都知道。只是MySQL的语法比较乱（说到代码实现，可能更多的是骂了），很松散，若是说作到了90%的兼容度，那是不够的，最好要作到100%，这能作到吗？我想是能够的。

2. 存储率高，使用分布式数据库的业务，大部分应该是存储分析型，若是使用了分布式数据库，还须要占用太多的硬件资源，且存储不了太多数据的话，那这个在成本上就很是高了，得不偿失。

3. 有健全的圈子，使用中不免会碰到问题，碰到问题的时候，如今处于分布式发展的初级阶段，因此社区的人比较少，而只能去求助官方，若是官方不能提供帮助（也许是没给钱），那这样的数据库，可能就不具备诱惑力了，风险太大。

4. 性可以用，在使用了分布式数据库以后，其实已经默认接受了下降性能要求的条件，因此咱们的要求只是说，性可以用便可，不会去和单点MySQL去比，由于没有意义。够用就好，固然在这方面若是足够好，那是再好不过了。

5. 少技术栈，这样的需求是很是高的，由于技术栈太长，会加剧运维人员的成本，而且在如今这样人才难找更难招的状况下，这样的愿望是更迫切的。

 

符合这样要求的分布式数据库有吗？

 

最近在开源数据库大会上向开源社区作出分享的SequoiaDB巨杉数据库，这个名称应该是比较熟悉了，他们已经作了不少年的分布式数据库，只是最近才出如今了MySQL社区。其实一个很重要的缘由就是，他们终于想清楚了，或者说意识到了MySQL的重要意义，因此他们也与MySQL保持了亲密关系，或者更准确的说，巨杉数据库，成为了MySQL圈内的一员，属于真正的MySQL体系。

 

SequoiaDB巨杉数据库

 

根据官方网站介绍，巨杉做为中国数据库产品，技术上，SequoiaDB的3.0版本采用了计算-存储分离的架构，这一架构是的SQL和存储引擎实现了松耦合，在资源分配和通用性上优化空间更大。其中，SequoiaDB的数据存储引擎是巨杉彻底自研的分布式JSON数据存储引擎，是彻底从零开始自研的。而数据库全部的数据管理、分布式控制、事务、ACID功能支持等都是在SequoiaDB的分布式存储引擎里完成的。SQL层，目前SequoiaDB经过链接器（sequoiasql-mysql）直接使用了MySQL的原生解析器，实现MySQL的完整兼容，同时目前也支持PGSQL和SparkSQL。

 

1. 为何说巨杉数据库属于MySQL体系内呢？由于他作到了一点，就是100%兼容了MySQL的语法，更准确的说，他成为了MySQL的一个插件，说到插件，我想每一个人都熟悉，由于你不会以为MySQL插件不是MySQL体系内的。因此这点彻底知足了个人第一个需求，做为一个MySQL工做者，最喜欢看到这样的场景了；

2. 存储率方面，巨杉数据库，只须要三个节点就能够了；

3. 在健全的圈子方面，我想，巨杉作为一个MySQL的插件，这个圈子够大了，由于MySQL Server层的问题，咱们本身就能够解决，仅剩下的巨杉数据库自己，那可能就须要去不断的学习与分享了，但至少少了不少问题；

4. 性能方面，咱们已经测试过，在只向一个IP端口读写（数据没有分区，sdb只有一个节点）的状况下，性能基本是MySQL单点的三分之二，这是能够接受的，由于作为分布式数据库，这样的使用方式，必然是比不上单点MySQL的，这里重点在测试性能损失多少，若是想提高性能，则能够增长分区，或者增长协调节点等方式来实现，从而能够作到最大限度的发挥他的分布式优点；

5. 技术栈方面，这个和MySQL仍是脱不了关系，对于Server层，轻车熟路，巨杉存储引擎，也只是几个独立进程，架构清楚简单，维护起来不会有太大困难。

 

巨杉数据库架构设计详解

 

上面是巨杉数据库的架构图。这里涉及到多个模块，下面分别作一个解释：

1. 协调节点：用来作数据的路由的，他的做用更像一个中间件，他会根据数据访问的KEY，以及编目节点，来肯定数据的存储位置。能够有多个协调节点，用来提供更高的性能；

2. 编目节点：用来存储路由信息的，与数据节点配合，能够最终定位数据；

3. 数据节点：用来存储数据的；

4. sdb plugin：这就是MySQL插件，巨杉数据库，自己与MySQL没有任何关系，但MySQL经过这个插件，实现了全部访问数据的接口，两者这才创建了关系，因此sdb plugin更多的是一个适配器。MySQL Server与巨杉数据库的协议转换器。

 

 

从架构上来看，这真正的实现了MySQL的云化存储方案。此时的MySQL Server，自身不会存储任何内容，其做用更多的被转化为一个中间件了。

 

作为一个存储引擎，在建立一个表的时候，还须要遵照MySQL自己的规则，好比还须要建立一个frm文件。其实我的认为，这个frm文件，和巨杉数据库中对应的表没有强关联，它只是为了“骗过”MySQL Server，让其知道，这个表是存在的，能够正常访问这个数据库，那么在骗过MySQL Server以后，就会走到存储引擎层的访问。

 

在顺利经过了MySQL Server的各类考验以后，就到了存储引擎的访问，由于巨杉实现了全部的存储引擎与Server层的接口，因此存储引擎的访问，就会顺利访问到巨杉的sdb plugin，好比取一条数据、写一条数据、带条件的取数据（MySQL5.6中新增的condition push down特性）等，只要能顺利将Server请求的接口返回正确的数据，那Server层就会正常的处理这些数据，最终返回给客户端。

MySQL+SequoiaDB总体架构示意

 

 

在将数据或者请求传给巨杉存储引擎以前，或者将数据从存储引擎返回给Server层的时候，这些全部的操做，与巨杉是没有关系的，这彻底是MySQL Server层的工做，这些工做包括语法分析、语义分析、查询优化、MDL锁、数据库权限、若是开了复制，则还会包括主从复制等等，固然还包括咱们常常运维的一些命令，好比show processlist; information schema; MySQL库信息的查询。基于这些熟悉的特征，这样的实现方式，给咱们很是大的诱惑力。

 

从上面实现原理来看，从MySQL Server，到巨杉数据库，架构应该是如上图所示的，sdb plugin自己没有存储数据，因此其角色转换为一个轻量级的中间件了，由sdb plugin来转发应用的请求到协调节点，到这里，就是巨杉数据库的天地了，我就再也不赘述了，我这里重点要讲的是自己架构的问题。

 

如今把MySQL Server理解为中间层，最好的架构方式就是，有多套MySQL server在运行着，应用能够随便访问任意一套，这样有如下几点好处：

 

1. 能够加强读写性能。

2. 能够实现读写分离。

3. 能够实现故障转移

4. 支持多点写入功能，在故障切换时，随便切换无影响。

 

但多套中间层的状况下，就存在一个问题，即配置的同步问题，在这套架构中，配置指的更多的是其元数据，好比表结构，也就是用来“骗过”MySQL Server的表结构，由于若是这些信息在多个节点之间不能同步，首先MySQL Server这层就不能顺利经过，也就没法访问巨杉了。

 

这个问题目前的解决方案是，巨杉提供了一个脚本，经过MySQL Server的审计功能，订阅MySQL Server层的DDL操做，这样在有元数据变动的时候，自动同步到其它MySQL Server中，这样也就实现了元数据的同步功能。这样实现，既熟悉，又无奈，由于这是MySQL，插件没有办法提供这样的接口来同步元数据，只好这样实现了。不过对于MySQL足够熟悉时，这样的实现也不失为一个好办法。

 

咱们进一步将这个架构完善一下，以下图：

 

 

在多个MySQL Server（中间层）前面加上一个Keepalived，将VIP绑定在Server上，若是有一个down了，Keepalived会自动切换到活着的Server上面，实现了自动故障转移。固然也能够不加这层，由业务自行去轮循环判断死活来访问MySQL Server也是能够的，由于使用Keepalived的话，存在一个问题就是VIP切换，在正常维护的时候，也会影响到业务，因此可能会产生这么一点点的不友好。

 

固然，若是想作到在正常维护时对业务无任何影响的话，仍是再次演进，方案以下：

 

 

这种状况下，若是MySQL Server正常维护，只须要在通用中间层中作配置，让维护节点下线，这样流量就不会再路由到这个维护节点了，等全部操做执行完以后，就能够正常维护了。或者若是挂了，哨兵会发现其状态变化，哨兵会链接到通用中间层上面，作配置更改，而后就能够实现故障转移。

 

不过这种架构其实没有什么太大必要，由于这个时候，MySQL Server很是轻量级，而且其做用已经成为了一个中间层的角色，只有在其所在机器须要关机的时候，或者某些MySQL的参数是只读的状况，但又不得不修改的时候才会去维护，影响并不会太大。

 

至于巨杉自己架构中，不少节点的高可用如何实现故障转移，我想这能够更多的参考他们的实现原理，拒我所知，其内容使用了raft相似的算法，作选举判断状态等，这些都是目前主流的分布式实现方法，应该是足够可靠了，这里再也不作过多赘述了。

 

测试状况

 

小结

 

1. 不支持自增列，自增列在MySQL中用得比较多，但实际被使用时，都是一个无心义的列，并无在业务逻辑中使用，但因为他的自增属性，致使不少业务程序在写SQL的时候，都不会指定这个列的数据，因此对自增列作了强依赖，因此目前巨杉尚未支持这个属性的列，在新业务上面问题不大，对于老业务的迁移，可能在兼容性上面还不够好。不过交流以后，官方声称在几个月以内能够上线。

 

2. 元数据同步
，以前已经提到过了，只能说是不完美，功能是有了。

 

在通过功能和性能的测评以后，SequoiaDB已经知足了咱们的要求，咱们也将会在近期在合适的场景进行上线使用。

 

MySQL的将来确定是光明的，我但愿有更多的开源软件能加入到MySQL这个圈子里来，一块儿碰撞，一块儿共享，一块儿成长。咱们也但愿巨杉数据库能够很快的创建起一个分享技术的圈子，可让更多人在开源的社区内受益。

 

王竹峰：去哪儿网数据库总监，中国计算机行业协会开源数据库专业委员会常务理事。擅长数据库开发、数据库管理及维护，一直致力于MySQL数据库源码的研究与探索，对数据库原理及实现有深入的理解。曾就任于达梦数据库，从事多年数据库内核开发工做，后转战人人网，任职高级数据库工程师，目前在去哪儿网负责MySQL源码研究与运维、数据库管理和自动化运维平台设计开发及实践工做，是Inception开源项目及《MySQL运维内参》的做者，也是国内少数几个MySQL方向的Oracle  ACE之一。

 

SequoiaDB下载地址：download.sequoiadb.com/cn/

SequoiaDB GitHub开源地址：github.com/SequoiaDB/SequoiaDB

SequoiaDB MySQL兼容项目GitHub开源地址：github.com/SequoiaDB/sequoiasql-mysql