阿里云DRDS的“分”之道

从使用者的角度理解DRDS分的原理。

项目业务需要,将一个数据量较大的产品搬到阿里云上去。数据存储的选择,通过比较OTS、OCS等产品的比较,最终选择了DRDS。

关于DRDS的介绍,在这里官方文档:分布式关系型数据库服务DRDS中有详细完整的说明,其实只能说是比较详细,比较完整吧,很多东西还是需要在使用中摸索。文章中只是简单记录下主要的使用过程和自己使用中对DRDS的一点理解。

开始需要明确下DRDS和RDS这两个产品的关系。

DRDS是分布式关系型数据库服务(Distribute Relational Database Service)是一种水平拆分、可平滑扩缩容、读写分离的在线分布式数据库服务。RDS是号称云数据库,其实就是一个Relational Database Service,能兼容MySQL,SQLServer,PostgreSQ协议的关系型数据库服务。

虽然官方的产品说明中看到两个都是**数据库服务。但是真的此服务非彼服务。RDS其实就是用云计算的概念把我们天天在用的这几种关系数据库给托管了,交了租费选择CPU、内存、网络等这些硬件指标和数据库自身的软件指标即可分分钟内快速构建一个可用的数据库。而DRDS其实不是数据库,从其在阿里云产品的归类中即可看到端倪,DRDS是出现在中间件的大分类下面。即DRDS不是存储数据的数据库,是一个数据服务,是一个数据代理,作为后端真正存数据的数据服务的反向代理。这后端正在存数据的数据服务就是RDS。听着形式上有点像nginx和后端的web server的关心,内容上其实更像Hbase的master和RegionServer的关系。

正如官方文档中声明的那样DRDS是一种水平拆分的关系数据库。和其他的分布式系统一样,希望可以通过加机器的方式来理论上无限增加系统的处理能力。不同于其他的采用了同样水平拆分的的Nosql的分布式系统,DRDS看上去尽量保留了关系数据库的功能。底层的存储采用是RDS,其实就是mysql,DRDS作为前端的代理自己应该有个SQL解析层,向应用程序或者数据库客户端提供类mysql的sql语法。对于应用程序或者数据库客户端来说,我们可以像使用一个普通的mysql数据库服务器一样来使用一个DRDS,可以再上面创建数据库,可以在上面创建表。像DRDS操作中描述的一样。

分而治之的思路,DRDS和HBase、MongoDB等没有太多差别。但因为内部存储用的mysql,对外也以近似mysql的语法向外提供功能,因此“分”字上面还有挺多细节,可能可以认为是DRDS核心细节,无论是对于他的原理,还是对于使用。

尤其是DRDS的DDL部分,因为其自身的对数据的水平拆分包含分库和分表两个级别,和我们一般数据库上只做表的分区不太一样,会有自身的一些语法。因为思路和普通数据库的分区类似,语法也和一般数据库中建表时候分区语法类似。

总体来说DRDS的分之道在思路上还是和传统的数据库的partition更像一点,对于分区键的选择,对于分区的使用,引擎对分区的解释,甚至综合的查询计划。看逻辑模型,和普通的数据库分区其实没有差别,就是把普通数据库的一级分区(当然oracle等很多数据库现在也支持多级分区,但还是一样的分区)扩展到数据库实例和数据表两个级别。连创建表的脚本也很普通的分区方式创建数据库表没有太大差别:

就是把partition关键字扩展到dbpartition和tbpartion分别表示分库和分表。

这是逻辑结构,但是看物理结构,又是一个中心节点,带一组可以扩展的数据节点,而且数据节点是按照partion方式存储数据库,并且支持扩展。物理上看有何很多Nosql的数据集群有点像,如Hbase的Hmaster和RegionServer。

为了稍微再描述的清楚些,下面一个表将DRDS和传统的数据库(拿来比较的是msyql,其实mssql,oracle也都类似),Hbase这样的Nosql进行比较。

比较观点 DRDS Mysql Hbase
partition方式 在rds实例上分库分表 表的partition 按照RowKey在RegionServer分区
partion元数据存储 一个rds上存储partion的元数据 数据库元数据 分级Hmaster上存储Rowkey范围和每个rowKey范围对应的RegionServer。
partion的优点(之于检索) 查询裁剪 查询裁剪 查询裁剪
partion的优点(之于写数据) 多个分库分表并行写,写均衡,效率高 多个分区并行写,写均衡,效率高 多个regionserver并行写,写均衡,效率高
partition key 在一个(一组)key上分库,在另外一个(一组)上分表 在一个(一组)key上分区 只能在rowKey来partition
动态扩展分区数 理论上可以,实际上在加入新分区后,需要rehash,代价较大,早期(2015年10月前)在用版本不支持 不容易支持 非常方便,加regionserver即可,会动态的平衡。
query引擎当检索条件是分区键 根据分区Key裁剪,在指定分区上检索,当检索条件跨分区后,需要在中心节点merge(根据需要可能还要进行排序),数据量大小会影响在内存还是磁盘上完成merge的操作,进而决定性能。 根据分区Key裁剪,在指定分区上检索,当检索条件跨分区后,需要进行merge(根据需要可能还要进行排序),数据量大小会影响在内存还是磁盘上完成merge的操作,进而决定性能。 根据分区Key裁剪,在指定分区上检索
query引擎当检索条件不是分区键 在多个(所有)分库分表上执行,需要在中心节点merge(根据需要可能还要进行排序),数据量大小会影响在内存还是磁盘上完成merge的操作,进而决定性能。 在多个(所有)分区上执行,需要在中心节点merge(根据需要可能还要进行排序),数据量大小会影响在内存还是磁盘上完成merge的操作,进而决定性能。 不支持
是否支持join 支持,根据业务配置小表广播,性能很好 关系数据库,天然支持 不支持

只是从使者的使用体会上整理下理解,不是很严谨。。

完。

原创文章。为了维护文章的版本一致、最新、可追溯,转载请注明: 转载自idouba

本文链接地址: 阿里云DRDS的“分”之道


, , , , ,

No comments yet.

发表评论