<< 返回文章列表

数据库中间件详解(下)

2019年8月28日
田守枝
949


4 分库分表核心要点


从业务开发的角度来说,其不关心底层是否是分库分表了,其还是希望想操作单个数据库实例那样编写sql,那么数据库中间件就需要对其屏蔽所有底层的复杂逻辑。

下图演示了一个数据库表(user表)在分库分表情况下,数据库中间件内部是如何执行一个批量插入sql的:

图示

数据库中间件主要对应用屏蔽了以下过程:

 · sql解析:首先对sql进行解析,得到抽象语法树,从语法树中得到一些关键sql信息

 · sql路由:sql路由包括库路由和表路由。库路由用于确定这条记录应该操作哪个分库,表路由用于确定这条记录应该操作哪个分表。

 · sql改写:将sql改写成正确的执行方式。例如,对于一个批量插入sql,同时插入4条记录。但实际上用户希望4个记录分表存储到一个分表中,那么就要对sql进行改写成4条sql,每个sql都只能插入1条记录。

 · sql执行:一条sql经过改写后可能变成了多条sql,为了提升效率应该并发的去执行,而不是按照顺序逐一执行

 · 结果集合并:每个sql执行之后,都会有一个执行结果,我们需要对分库分表的结果集进行合并,从而得到一个完整的结果。

4.1 SQL解析

用户执行只是一条sql,并传入相关参数。数据库中间件内部需要通过sql解析器,对sql进行解析。可以将sql解析,类比为xml解析,xml解析的最终结果是得到一个document对象,而sql解析最终得到一个抽象语法树(AST)。通过这个语法树,我们可以很简单的获取到sql的一些执行,例如当前执行的sql类型,查询了那些字段,数据库表名,where条件,sql的参数等一系列信息。

通常来说,对于sql解析,内部需要经过词法(lex)解析和语法(Syntax)解析两个阶段,最终得到一个语法树。

图示

SQL解析器的内部实现原理对业务同学是屏蔽的,业务同学也感知不到。一些数据库中间件采用了第三方开源的sql解析器,也有一些自研sql解析器。例如mycat、zebra采用的都是druid解析器,shard-jdbc一开始也用的是druid解析器,后面自研了解析器。目前较为流行的sql解析器包括:

 · FoundationDB SQL Parser

 · Jsqlparser

 · Druid SQL Parser

        其中,其中Fdbparser和jsqlparser都是基于javacc实现的。

mycat团队曾经做过一个性能测试,druid解析器的解析性能通常能达到基于javacc生成的sql解析器10~20倍。本人也进行过类似的测试,得出的结论基本一致。

如何对比不同的sql解析器的好坏呢?主要是考虑以下两点:

解析性能:druid最好。

druid采用的是预测分析法,它只需要从字符的第一个到最后一个遍历一遍,就同时完成了词法解析和语法解析,语法树也已经构造完成。

数据库方言:druid支持的最多。

SQL-92、SQL-99等都是标准SQL,mysql/oracle/pg/sqlserver/odps等都是方言,sql-parser需要针对不同的方言进行特别处理。Druid的sql parser是目前支持各种数据语法最完备的SQL Parser。

注:这里说的仅仅是基于Java实现的SQL解析器,druid是比较好的。大部分同学可能知道druid是一个为监控而生的连接池,事实上,druid另一大特性,就是它的SQL解析器。很多开源的数据库中间件,例如zebra、sharding-jdbc等,都使用了druid解析器。(sharding-jdbc后来自研了解析器)。虽然SQL解析是druid的一大亮点,不过github上也因为SQL解析的bug,收到了不少issue。

4.2 SQL路由

路由规则是分库分表的基础,其规定了数据应该按照怎样的规则路由到不同的分库分表中。对于一个数据库中间件来说,通常是支持用户自定义任何路由规则的。路由规则本质上是一个脚本表达式,数据库中间件通过内置的脚本引擎对表达式进行计算,确定最终要操作哪些分库、分表。常见的路由规则包括哈希取模,按照日期等。

下图展示了user表进行分库分表后(2个分库,每个分库2个分表),并如何根据id进行路由的规则:

图示

路由分则分为:

 · 库规则:用于确定到哪一个分库

 · 表规则:用于确定到哪一个分表

在上例中,我们使用id来作为计算分表、分表,因此把id字段就称之为路由字段,或者分区字段。

需要注意的是,不管执行的是INSERT、UPDATE、DELETE、SELECT语句,SQL中都应该包含这个路由字段。否则,对于插入语句来说,就不知道插入到哪个分库或者分表;对于UPDATE、DELETE、SELECT语句而言,则更为严重,因为不知道操作哪个分库分表,意味着必须要对所有分表都进行操作。SELECT聚合所有分表的内容,极容易内存溢出,UPDATE、DELETE更新、删除所有的记录,非常容易误更新、删除数据。因此,一些数据库中间件,对于SQL可能有一些限制,例如UPDATE、DELETE必须要带上分区字段,或者指定过滤条件。

4.3 SQL改写

前面已经介绍过,如一个批量插入语句,如果记录要插入到不同的分库分表中,那么就需要对SQL进行改写。 例如,将以下SQL

insert into user(id,name) values (1,”tianshouzhi”),(2,”huhuamin”), (3,”wanghanao”),(4,”luyang”)

改写为:

insert into user_1(id,name) values (1,”tianshouzhi”)insert into user_2(id,name) values (2,”huhuamin”)insert into user_3(id,name) values (3,”wanghanao”)insert into user_0(id,name) values  (4,”luyang”)


这里只是一个简单的案例,通常对于INSERT、UPDATE、DELETE等,改写相对简单。比较复杂的是SELECT语句的改写,对于一些复杂的SELECT语句,改写过程中会进行一些优化,例如将子查询改成JOIN,过滤条件下推等。因为SQL改写很复杂,所以很多数据库中间件并不支持复杂的SQL(通常有一个支持的SQL),只能支持一些简单的OLTP场景。

当然也有一些数据库中间件,不满足于只支持OLTP,在迈向OLAP的方向上进行了更多的努力。例如阿里的TDDL、蚂蚁的Zdal、大众点评的zebra,都引入了apache calcite,尝试对复杂的查询SQL(例如嵌套子查询,join等)进行支持,通过过滤条件下推,流式读取,并结合RBO(基于规则的优化)、CBO(基于代价的优化)来对一些简单的OLAP场景进行支持。


4.4 SQL执行

当经过SQL改写阶段后,会产生多个SQL,需要到不同的分片上去执行,通常我们会使用一个线程池,将每个SQL包装成一个任务,提交到线程池里面并发的去执行,以提升效率。

图示

这些执行的SQL中,如果有一个失败,则整体失败,返回异常给业务代码。

4.5 结果集合并

结果集合并,是数据库中间件的一大难点,需要case by case的分析,主要是考虑实现的复杂度,以及执行的效率问题,对于一些复杂的SQL,可能并不支持。例如:

对于查询条件:大部分中间件都支持=、IN作为查询条件,且可以作为分区字段。但是对于NIT IN、BETWEEN…AND、LIKE,NOT LIKE等,只能作为普通的查询条件,因为根据这些条件,无法记录到底是在哪个分库或者分表,只能全表扫描。

聚合函数:大部分中间件都支持MAX、MIN、COUNT、SUM,但是对于AVG可能只是部分支持。另外,如果是函数嵌套、分组(GROUP BY)聚合,可能也有一些数据库中间件不支持。

子查询:分为FROM部分的子查询和WHERE部分的子查询。大部分中对于子查询的支持都是非常有限,例如语法上兼容,但是无法识别子查询中的分区字段,或者要求子查询的表名必须与外部查询表名相同,又或者只能支持一级嵌套子查询。

JOIN:对于JOIN的支持通常很复杂,如果做不到过滤条件下推和流式读取,在中间件层面,基本无法对JOIN进行支持,因为不可能把两个表的所有分表,全部拿到内存中来进行JOIN,内存早就崩了。当然也有一些取巧的办法,一个是Binding Table,另外一个是小表广播(见后文)。

分页排序:通常中间件都是支持ORDER BY和LIMIT的。但是在分库分表的情况下,分页的效率较低。例如对于limit 100,10 ORDER BY id。表示按照id排序,从第100个位置开始取10条记录。那么,大部分数据库中间件实际上是要从每个分表都查询110(100+10)条记录,拿到内存中进行重新排序,然后取出10条。假设有10个分表,那么实际上要查询1100条记录,而最终只过滤出了10记录。因此,在分页的情况下,通常建议使用"where id > ? limit 10”的方式来进行查询,应用记住每次查询的最大的记录id。之后查询时,每个分表只需要从这个id之后,取10条记录即可,而不是取offset + rows条记录。

关于JOIN的特属说明:

Binding Table:

适用于两个表之间存在关联关系,路由规则相同。例如,有user表和user_account表,由于user_account与user表强关联,我们可以将这两个表的路由规则设置为完全一样,那么对于某个特定用户的信息,其所在的user分表和user_account分表必然唯一同一个分库下,后缀名相同的分表中。在join时,某一个分库内的join,就可以拿到这个用户以及账号的完整信息,而不需要进行跨库join,这样就不需要把用户的数据库拿到内存中来进行join。

图示

小表广播:

小表广播通常是某一个表的数据量比较少, 例如部门表department。另外一个表数据量比较大,例如user。此时user需要进行分库分表,但是department不需要进行分库分表。为了达到JOIN的目的,我们可以将 department表在每个分库内都实时同步一份完整的数据。这样,在JOIN的时候,数据库中间件只需要将分库JOIN的结果进行简单合并即可。

下图演示了小表广播的流程,用户在更新department表时,总是更新分库db0的department表,同步组件将变更信息同步到其他分库中。

图示

注:图中的同步组件指的是一般是伪装成数据库的从库,解析源库binlog,插入目标库。有一些开源的组件,如canal、puma可以实现这个功能,当然这些组件的应用场景非常广泛,不仅限于此。笔者曾写过一个系列的canal源码解析文章,目前完成了大部分。

4.6 二级索引

通常情况下,分库分表的时候,分区字段只有一个。例如对于用户表user,按照user_id字段进行分区,那么之后查询某个用户的信息,只能根据user_id作为分区字段。使用其他字段,则需要扫描所有分表,效率很低。但是又有根据其他字段查询某个用户信息的需求,例如根据手机号phone_id。

此时,我们可以将按照user_id插入的数据,进行一份全量拷贝。通过同步组件,重新按照phone_id插入到另一个分库分表集群中,这个集群就成为二级索引,或者叫辅维度同步。此后,对于根据user_id的操作,就在原来的分库分表集群中进行操作;根据phone_id的操作,就到二级索引集群中去进行操作。

需要注意的是,对于更新操作,只能操作原集群,二级索引集群只能执行查询操作。原集群的增量数据变更信息,实时的通过同步组件,同步到二级索引集群中。

图示

注:这是一个很常见的面试题。阿里的一些面试官,比较喜欢问。一些面试者,可能自己想到了这个方案,因为考虑到这样比较浪费资源,就自行排除了。事实上,这点资源相对于满足业务需求来说,都不是事。

4.7 分布式id生成器

在分库分表的情况下,数据库的自增主键已经无法使用。所以要使用一个分布式的id生成器。分布式事务id生成器要满足以下条件:唯一、趋势递增(减少落库时的索引开销)、高性能、高可用。

目前主流的分布式id生成方案都有第三方组件依赖,如:

 · 基于zk

 · 基于mysql

 · 基于缓存

twitter的snowflake算法是一个完全去中心化的分布式id算法,但是限制workid最多能有1024,也就是说,应用规模不能超过1024。虽然可以进行细微的调整,但是总是有数量的限制。

另外,美团之前在github开源了一个leaf组件,是用于生成分布式id的,感兴趣的读者可以研究一下。

这里提出一种支持动态扩容的去中心化分布式id生成方案,此方案的优势,除了保证唯一、趋势递增,没有第三方依赖,支持存储的动态扩容之外,还具有以下优势:

 · 支持按照时间范围查询,或者 时间范围+ip查询,可以直接走主键索引;

 · 每秒的最大序列id就是某个ip的qps等

 12位日期+10位IP+6位序列ID+4位数据库扩展位

其中:

12位日期:格式为yyMMddHHmmss,意味着本方案的id生成策略可以使用到2099年,把时间部分前置,从而保证趋势递增。

10位ip:利用ip to decimal算法将12位的ip转为10进制数字。通过ip地址,来保证全局唯一。如果ip地址被回收重复利用了,也不用担心id的唯一性,因为日期部分还在变化。

6位序列id:意味着每秒最多支持生成100百万个id(0~999999)。不足6位前置补0,如000123。

4位数据库扩展位:为了实现不迁移数据的情况下,实现动态扩容,其中2位表示DB,2位表示TB,最多可扩容到10000张表。假设每张表存储1000万数据,则总共可以支持存储1000亿条数据。

关于数据库扩展位实现动态扩容图解:

图示

首先明确一点,路由策略始终根据数据库最后四位,确定某一条记录要到哪个分库的哪个分表中。例如xxxx0001,意味着这条记录肯定是在00分库的01分表上。

接着,就要在id的生成策略上做文章。

假设初始状态为两个分库db_00,db_01,每个分库里面有10张分表,tb_00~tb_09。此时,业务要保证生成id的时候,始终保证db的两位在00~01之间,tb的两位始终在00~09之间。路由策略根据这些id,可以找到正确的分库分表。

现在需要扩容到10个分库,每个分表10个分表。那么DBA首先将新增的分库:db_02~db_09创建好,每个分库里面再创建10个分表:tb_01~tb_09。业务同学在此基础上,将id生成策略改成:db的两位在00~09之间,tb的两位规则维持不变(只是分库数变了,每个分库的分表数没变)。而由于路由从策略是根据最后四位确定到哪个分库,哪个分表,当这些新的分库分表扩展位id出现时,自然可以插入到新的分库分表中。也就实现了动态扩容,而无需迁移数据。

当然,新的分库分表中,一开始数据是没有数据的,所以数据是不均匀的,可以调整id扩展位中db和tb生成某个值的概率,使得落到新的分库分表中的概率相对大一点点(不宜太大),等到数据均匀后,再重新调整成完全随机。

此方案的核心思想是,预分配未来的可能使用到的最大资源数量。通常,100个分库,每个分库100张分表,能满足绝大部分应用的数据存储。如果100个分库都在不同的mysql实例上,假设每个mysql实例都是4T的磁盘,那么可以存储400T的数据,基本上可以满足绝大部分业务的需求。

当然,这个方案不完美。如果超过这个值,这种方案可能就不可行了。然而,通常一个技术方案,可以保证在5~10年之间不需要在架构上做变动,应该就算的上一个好方案了。如果你追求的是完美的方案,可能类似于TIDB这种可以实现自动扩容的数据库产品更适合,不过目前来说,TIDB等类似产品还是无法取代传统的关系型数据库的。说不定等到5~10年后,这些产品更成熟了,你再迁移过去也不迟。

4.7 分布式事务

在分库分表的情况下,由于操作多个分库,此时就涉及到分布式事务。例如执行一个批量插入SQL,如果记录要插入到不同的分库中,就无法保证一致性。因此,通常情况下,数据库中间件,只会保证单个分库的事务,也就是说,业务方在创建一个事务的时候,必须要保证事务中的所有操作,必须最终都在一个分库中执行。

事实上,在微服务的架构下,事务的问题更加复杂,如下图

图示

Service A在执行某个操作时,需要操作数据库,同时调用Service B和Service C,Service B底层操作的数据库是分库分表的,Service C也要操作数据库。

这种场景下,保证事务的一致性就非常麻烦。一些常用的一致性算法如:paxios协议、raft协议也无法解决这个问题,因为这些协议都是资源层面的一致性。在微服务架构下,已经将事务的一致性上升到了业务的层面。

如果仅仅考虑分库分表,一些同学可能会想到XA,但是性能很差,对数据库的版本也有要求,例如必须使用mysql 5.7,官方还建议将事务隔离级别设置为串行化,这是无法容忍的。

由于分布式事务的应用场景,并不是仅仅分库分表,因此通常都是会有一个专门的团队来做分布式事务,并不一定是数据库中间件团队来做。例如,sharding-jdbc就使用了华为开源的一套微服务架构解决方案service comb中的saga组件,来实现分布式事务最终一致性。阿里也有类似的组件,在内部叫TXC,在阿里云上叫GTS,最近开源到了GitHub上叫fescar(Fast & Easy Commit And Rollback)。蚂蚁金服也有类似的组件,叫DTX,支持FMT模式和TCC模式。其中FMT模式就类似于TXC。

总体来说,实际上TCC更能满足业务的需求,虽然接入更加复杂。关于fescar,最近比较火,这是java写的,具体可以参考:https://github.com/alibaba/fescar。