分布式数据库 UDDB 技术解读

“

结合 UDDB 的功能特性和产品理念，我们明确了它的发展方向——基于数据库中间件来做公有云上的分布式数据库。在刚开始选择较为简单的工程实现复杂度，然后通过公有云这种互联网服务的快速迭代能力和在线服务能力，不断的提高对业务的支持度，从而覆盖更多的业务。最终演进为大数据时代的分布式数据库解决方案，为互联网、物联网、传统行业的转型提供海量数据存储、处理的在线服务。

”

UDDB的技术演进路径

虽然技术服务于产品，而产品的发展方向体现了根据客户和市场所做的战略思考，但是在执行层面上，还只是一个模糊的目标。因此，在技术实现上，需要把执行的路径想清楚，才能将目标清晰地落地。互联网创业，强调的是树目标、定路径、滚雪球式发展。其中，定路径是关键的一环：向上，必须与战略规划很好地对接；往前，每一步都要踩到点上。如此，才能在每一个阶段创造价值，吸收资源，发展壮大。

执行路径的确定，需要回归到客户需求上，要深入到客户业务中，去寻找规律和办法。通过大量的调研，我们发现目前技术圈的热点：超大表水平拆分问题，其实并不是客户主要的痛点，读写分离和垂直分库的需求，反而是沉默的大多数。从技术演进的趋势来看，水平拆分必然是分布式数据库最终的目标。

但现阶段水平拆分对 SQL 的支持度不高，导致为了做水平拆分，很多业务层必须要做脱胎换骨的改造。因此在数据量或性能要求还没有到这个程度的情况下，客户并不希望为了水平拆分做业务层的改造，而是倾向于更保守的读写分离和垂直分库策略。UCloud 技术团队基于客户的这个诉求，最终确定了这样一条技术演进路径：

￭ 基于数据库中间件，用最短的时间做到一主多从读写分离场景下100% 兼容 MySQL，让客户的业务在库表零变动、代码零改动的情况下，使用上 UDDB；

￭ 在垂直分库场景下对 MySQL 的 100%兼容，让一部分有垂直分库需求的客户，只需要调整好库表位置，即可将业务接入UDDB；

￭逐步完善对水平拆分的支持，在产品推出初期，功能对齐业内主流数据库中间件。后续进一步完善对 SQL 和事务的支持，结合对存储系统（MySQL）的优化、裁减或替换，实现最终的产品目标。

在技术演进上，三个阶段并非割裂，每一个阶段目标的达成，都为下一个阶段的目标做好铺垫。在读写分离和垂直分库场景下，实现对 MySQL 的100%兼容，核心在于构建一个完全对齐 MySQL 的语法解析器，解析完成后识别 SQL 的操作类型，即可进行读写分离；识别 SQL 的作用对象（库/表/视图），即可在垂直分库场景下，将 SQL 进行有效路由和透传；语法解析器的完善和成熟，又为水平拆分场景下，完善语义分析、分布式执行计划的生成、优化和执行打下了基础。

总之，UDDB 的最终目标就是通过该技术演进路径，成为一款基于 Shared-Nothing 架构的分布式数据库。

在系统架构和计算模型上，数据库中间件+MySQL节点的分布式数据库解决方案和NewSQL 产品本质上是一回事。限于本文的主题，关于数据库中间件和 NewSQL 讨论，在此不作展开。

UDDB的技术实现

技术路径的确定是将产品目标进行落地，而技术实现则是将技术路径进行落地。到了技术实现的层面，重点有两个：第一是把基础打好，让产品的生长有一个牢靠的地基；第二是要进行大胆创新，在时间和人力资源有限的情况下，通过灵活巧妙的办法满足客户的需求或解决客户的问题。

1

UDDB的系统架构

如图所示 UDDB 的整个架构主要有三大模块：

￭UDB资源池：等同于 UDB 产品的资源池， UDDB 存储节点和只读实例直接复用处于同一可用区的UDB资源。

￭分布式数据库中间件系统：基于数据库中间件技术构建的分布式、多租户数据库中间件系统由以下几个模块构成：Routerd、 Mgrd、高可用UDB实例（负责元数据和配置存储）、Zookeeper集群（负责决策和调度）。

￭ UDDB 管理控制台：提供 UDDB 创建、管理、释放等操作的 Web 界面。

我们可以从以下两个方面理解该系统架构：

一、从左往右，以业务访问的视角来看待该架构，可以看到：

￭客户可以通过标准的 MySQL API 或者客户端来访问 UDDB， 客户的请求均发往ULB，由ULB转发到某个中间件节点的 Routerd 模块。

￭ Routerd 模块将对客户请求进行分析：

>>如果是DML请求，则在进行处理后，直接转发到相关的 UDB 节点，然后将各 UDB 节点的返回结果进行聚合并返回给客户端；

>>如果是 DDL请求，则通过 Zookeeper 集群，将该 DDL 任务通知到 Mgrd 模块。 由Mgrd 模块将该 DDL 任务取出、处理并广播到 UDDB下 所有 UDB 节点。广播完成后，将返回结果按原路经 Zookeeper 集群递交到 Routerd ，最后返回给客户端。

二、从右往左，以系统管理的视角来看待该架构，可以看到：

UDDB 的创建过程基本等同于目前利用数据库中间件软件+ MySQL 实例+负载均衡组件来搭建一个分布式数据库解决方案的过程。这个过程为众多开发团队的研发或者 DBA 所熟悉， 而 UDDB 的管理平台无非是对这些流程做了一个完整的封装，把这些烦琐的操作替换为点击鼠标即可搞定。

2

SQL解析和路由模块

UDDB 在架构上注重稳健务实，而在 SQL 的解析和路由模块（Routerd）的设计和实现上，则注重规范和专业。

Routerd 的核心是一个 SQL 解释器。它接收 SQL 语句，解析其语法和语义，确定该SQL 影响哪些 UDB 节点，然后将 SQL 转换成子 SQL 并下推到相关 UDB 节点。待 UDB 节点将结果返回后，可能需要根据原始 SQL 的语义将结果进行过滤聚合，最终返回到客户端。

该 SQL 解释器的完善程度是 Routerd 的一个重要设计指标。SQL 解释器越完善，则对业务的支持越好，能够支持的客户端就越多，从而具备更好的通用性。公有云产品不能限制客户类型和使用场景，因此通用性是非常重要的指标。

业内不少历史悠久的数据库中间件，虽然稳定可靠支撑了不少实际项目，但是其 SQL 解释器，却一直做得不够好。考察业内各种数据库中间件的源码实现，我们可以看到， 不少中间件的实现存在两个问题：

有的中间件没有独立的 SQL 语法解析模块，而是直接复用其他数据库（如 SqlLite）的语法解析器，或者开源 SQL 解析库（如 alibaba druid）。短期内，这种做法的确能够让项目迅速得以推进，但是后续功能的扩展却往往受制于该 SQL 语法解析器，因此不利于产品的长期发展。

有的数据库中间件有独立、规范的语法解析器，但是在语义解析上做的不够专业，这些中间件一般的解析流程如图：

这样虽然也能够让中间件工作，但是 SQL 的生成和结果的过滤聚合，都依赖抽象语法树（AST）来完成。然而 AST 结构复杂，携带信息也有限，使用 AST 来做 SQL 的生成和结果的过滤聚合，一方面会带来编程上的复杂度；另一方面也不能执行一些复杂的操作，比如 group by、order by、distinct、limit 和集函数同时存在的 SQL 语句的聚合操作，因此很难实现通用性和可扩展性。

如何做好 Routerd 的通用性？ 可以从两个方面着手：

第一是基于 Lex&Yacc 构建一个独立、规范的语法解析模块。让研发团队做到对 SQL 语法图和 SQL 语法解析实现，做到了如指掌。这样才能在有 Bug 时迅速修复，需要添加新功能时能够立即支持。

第二是采用类似数据库系统实现的方式，来实现 Routerd 的语义解析。如大家所知，通用的数据库系统，执行一条 SQL 有规范的流程如图：

流程可以概括为语法解析、生成执行计划、执行计划优化（查询优化）和执行4个步骤。每一个步骤能够很好地解耦，步骤之间通过约定的数据结构来交互。这些数据结构中，执行计划是最核心的，它详细描述了 SQL 的语义、涉及到哪些数据库内部对象以及对这些内部对象操作的顺序。

参考数据库系统的 SQL 解释流程，UDDB 的 Routerd 模块的流程是：

Routerd 中的分布式执行计划：一方面是对抽象与语法树结构更加精简、扁平的描述，让子 SQL 的生成更方便；另一方面，加入 SQL 结果过滤聚合的控制信息，方便对 UDB 节点返回结果的提取、过滤和聚合。

经过一年多的演进和迭代，UDDB 的分布式执行计划和计划执行在逐步完善。从最初实现对单表 SQL，以及落到同一节点 的 JOIN SQL 的100%支持，到支持多表跨节点Join、分布式事务这两个核心功能（分布式事务功能目前内测中，跨节点 JOIN 计划于2018年上半年推出）。

实践证明，通过合理的架构，能够让 UDDB 从一款简单的中间件出发，走向更开阔的未来，成为基于 MySQL 并保留 MySQL 原生部署和运维体验的，真正的分布式数据库。同时，引入和数据库内核同样的架构，这意味着还可以添加执行计划优化的环节，对分布式执行计划进行优化，最终不仅在功能上对齐单机数据库，在性能上也有不断优化的空间。

3

读写分离模式100%兼容MySQL

接下来我们将给出读写分离 100% 兼容 MySQL 的一个创新性的技术实现供业内参考。垂直分库实现对 MySQL DDL、DML 语法的 100% 支持，其原理也类似，在本文中不做赘述。

如果做一款单纯的读写分离中间件， 在这款中间件中做到 100% SQL 兼容并不难。 只需要对 SQL 做轻量的解析，识别 SQL 的是读 SQL 还是写 SQL，然后使用透传的方法透传到主从节点即可：

作为一种描述性语言，SQL 的语法有一个非常明显的规律：最前面的单词必然是操作行为（动词）， 后面是操作对象（名词）和限制条件。而从操作行为即可完全判断出该SQL 的读/写类型（call 存储过程除外，因为存储过程可写可读）。因此只需要提取前面几个单词，即可做正确的路由。

通过这两个流程可以看到读写分离和水平分表两种模式，在技术实现上的一个矛盾：读写分离假定所有的表都是不拆分的普通表， 需要提取 SQL 中的动作语义来识别读写 SQL，继而将 SQL 进行透传； 而水平分表模式下，则需要提取 SQL 中的作用对象，识别到底是哪几张表，然后进行表名的改写（必要时也进行其他子句的改写）。两者提取信息的逻辑没有交集，导致两种模式无法有机结合。

4

UDDB的技术创新

1.修改语法解析模块：在解析 SQL 生成抽象语法树的同时，将 SQL 中的库表名称提出到一个链表中。 假如语法解析器足够规范，那么必然会有一个或几个非终结符用于归约 SQL 中的库表名称。此时，可以在这些非终结符对应的语义动作代码中，增加将库表名称保存到链表的操作：

2.在语法解析之后获得抽象语法树以及链表，然后扫描链表，依次取出该 SQL 涉及的库表名称，结合中间件的元数据信息，判断这些表是普通表还是水平分表。如果都是普通表，则将该 SQL 按照读写类型透传到主节点或从节点；如果是水平分表，则再进行语义分析、执行计划生成和计划执行。

通过以上两步，做到读写分离模式下，SQL 接近 100% 的兼容以及读写分离模式和水平分表模式在一个产品中和谐共存。

这其中的关键点在于语法解析模块：需要实现一个规范完整并且能够和 MySQL 官方对齐的语法解析模块，有了该模块即可做到对所有 SQL 都能够进行语法解析，在解析过程中进行库表提取；同时， 需要精心设计该语法解析模块，将所有 SQL 的库表子句，抽象为特定的几个非终结符，从而方便植入库表提取代码。

该方法的优点在于性能和实现上的简单：库表的提取，充分复用了语法解析过程，没有额外的开销；库表类型（普通表/水平拆分的大表）的判断，则只需要扫描提取出的库表链表即可完成，性能开销几乎可以忽略不计；实现上也非常简单，总共不超过 150 行代码。

结语

本文介绍了 UDDB 的技术演进路径及其背后的系统架构技术实现原理，以帮助客户解决单机 MySQL 中的问题、让客户业务运行更顺畅为宗旨。结合 UCloud 高水平的数据库内核开发能力，打造了一个结构规范、实现工整的数据库中间件，具备独立完整的语法解析、语义解析、执行计划生成和计划执行模块；我们不断解决 MySQL 的兼容性问题，目前已经支持所有的 MySQL 客户端管理工具，包括 PhpMyAdmin、Navicat、SequelPro 等。

2018 年上半年，我们将实现对分布式事务和分布式 Join 的原生支持，从而完成对存储、事务以及 SQL 执行三大块的分布式化，最终成为既保留 MySQL 原生部署和运维体验，又彻底解决单机 MYSQL 容量和性能问题的真正的分布式数据库。

— END —