UCloud分布式数据库UDDB:技术实现

云计算 分布式
在此之前,我们介绍过UDDB的功能特性和产品理念,明确了产品的发展方向——基于数据库中间件来做公有云上的分布式数据库。在刚开始选择较为简单的工程实现复杂度,然后通过公有云这种互联网服务的快速迭代能力和在线服务能力,不断的提高对业务的支持度,从而覆盖更多的业务。

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

1.UDDB的技术演进路径

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

执行路径的确定,需要回归到客户需求上,要深入到客户业务中,去寻找规律和办法。通过大量的调研,我们发现目前技术圈的热点:超大表水平拆分问题,其实并不是客户主要的痛点,读写分离和垂直分库的需求,反而是沉默的大多数。从技术演进的趋势来看,水平拆分必然是分布式数据库最终的目标。但现阶段水平拆分对SQL的支持度不高,导致为了做水平拆分,很多业务层必须要做脱胎换骨的改造。因此在数据量或性能要求还没有到这个程度的情况下,客户并不希望为了水平拆分做业务层的改造,而是倾向于更保守的读写分离和垂直分库策略。UCloud技术团队基于客户的这个诉求,最终确定了这样一条技术演进路径:

  • 基于数据库中间件,用最短的时间做到一主多从读写分离场景下100% 兼容 MySQL,让客户的业务在库表零变动、代码零改动的情况下,使用上UDDB;
  • 在垂直分库场景下对MySQL的 100%兼容,让一部分有垂直分库需求的客户,只需要调整好库表位置,即可将业务接入UDDB;
  • 逐步完善对水平拆分的支持,在产品推出初期,功能对齐业内主流数据库中间件。后续进一步完善对SQL和事务的支持,结合对存储系统(MySQL)的优化、裁减或替换,实现最终的产品目标。

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

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

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

2.UDDB的技术实现

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

2.1UDDB的系统架构

如图所示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.2SQL解析和路由模块

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原生部署和运维体验的,真正的分布式数据库。同时,引入和数据库内核同样的架构,这意味着还可以添加执行计划优化的环节,对分布式执行计划进行优化,最终不仅在功能上对齐单机数据库,在性能上也有不断优化的空间。

2.3读写分离模式100%兼容MySQL

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

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

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

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

2.4UDDB的技术创新

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

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

通过以上两步,做到读写分离模式下,SQL接近100%的兼容以及读写分离模式和水平分表模式在一个产品中***共存。 这其中的关键点在于语法解析模块:需要实现一个规范完整并且能够和MySQL官方对齐的语法解析模块,有了该模块即可做到对所有SQL都能够进行语法解析,在解析过程中进行库表提取;同时, 需要精心设计该语法解析模块,将所有SQL的库表子句,抽象为特定的几个非终结符,从而方便植入库表提取代码。

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

3.结语

本文介绍了UDDB的技术演进路径及其背后的系统架构技术实现原理,以帮助客户解决单机MySQL中的问题、让客户业务运行更顺畅为宗旨。结合UCloud高水平的数据库内核开发能力,打造了一个结构规范、实现工整的数据库中间件,具备独立完整的语法解析、语义解析、执行计划生成和计划执行模块;我们不断解决MySQL的兼容性问题,目前已经支持所有的MySQL客户端管理工具,包括PhpMyAdmin、Navicat、SequelPro等。2018年上半年,我们将实现对分布式事务和分布式Join的原生支持,从而完成对存储、事务以及SQL执行三大块的分布式化,最终成为既保留MySQL原生部署和运维体验,又彻底解决单机MYSQL容量和性能问题的真正的分布式数据库。

责任编辑:武晓燕 来源: 51CTO
相关推荐

2023-12-05 07:30:40

KlustronBa数据库

2021-12-20 15:44:28

ShardingSph分布式数据库开源

2023-12-11 09:11:14

TDSQL技术架构

2015-10-16 18:03:25

Docker分布式CoreOS

2019-06-26 09:43:13

数据库分布式技术

2023-07-28 07:56:45

分布式数据库SQL

2020-06-23 09:35:13

分布式数据库网络

2022-08-01 18:33:45

关系型数据库大数据

2023-03-07 09:49:04

分布式数据库

2022-03-10 06:36:59

分布式数据库排序

2023-07-31 08:27:55

分布式数据库架构

2024-03-11 08:57:02

国产数据库证券

2023-11-14 08:24:59

性能Scylla系统架构

2011-05-19 09:18:48

分布式数据库

2011-03-24 17:15:06

分布式数据库系统

2012-09-29 13:18:23

分布式数据库Google Span

2023-04-26 06:56:31

分布式数据库伪需求

2021-12-14 10:16:00

鸿蒙HarmonyOS应用

2024-03-15 07:33:02

分布式数据库索引数据结构

2022-06-09 10:19:10

分布式数据库
点赞
收藏

51CTO技术栈公众号