对话 DDM 华为云 PAAS 分布式数据库中间件全解析

阅读数:53 2019 年 10 月 21 日 10:59

对话DDM 华为云PAAS分布式数据库中间件全解析

进入云计算时代,传统的数据库在性能和容量等方面已无法满足企业的要求,随着数据量的不断骤增,易于扩展、拆分的数据库解决方案对于企业的云化转型更是显得尤为重要。

华为云 PaaS 为使企业应用上云更简单,近期推出的分布式数据库中间件 DDM(Distributed DatabaseMiddleware)专注解决企业在上云过程中面临的的数据库瓶颈难题,不但更能轻松满足水平拆分、扩容、读写分离等业务需求,同时也比传统方案更具性价比。在公测期间,受到了用户广泛的关注,以下小编特别邀请华为的技术专家,为大家带来一手新鲜的技术干货,一起零距离解密华为云 DDM。

小编: 大神,你好,能否给大家简单介绍一下 DDM?

DDM 华为专家(以下简称 DDM): DDM 专注于解决数据库分布式扩展问题,它突破了传统数据库的容量和性能瓶颈,实现海量数据高并发访问。DDM 提供了对应用透明的数据库读写分离、自动的数据分片、灵活的弹性伸缩等分布式数据库能力。

小编: 读写分离是各种分布式数据库中间件的重要特性,DDM 是如何定义它的呢?

DDM: 从数据库的角度来说,对于大多数应用来说,从集中到分布,最基本的一个需求不是数据存储的瓶颈,而是在于计算的瓶颈,即 SQL 查询的瓶颈,在没有读写分离的系统上,很可能高峰时段的一些复杂 SQL 查询就导致数据库系统陷入瘫痪,从保护数据库的角度来说,我们应该尽量避免没有主从复制机制的单节点数据库。传统读写分离解决方案耦合应用代码,扩容读节点或修改读写分离策略等需要修改应用代码,升级应用程序,非常复杂。DDM 实现了透明读写分离,应用实现读写分离不需要修改代码,为了保证读一致性, 默认情况在事务中的读全部分发到主节点。事务外的读分发从节点。写分发主节点。在应用程序需求复杂时,DDM 提供了 hint 可由程序自主控制 sql 的读写分离逻辑。此外,后端 DB 如果部分节点故障了,DDM 会自动摘除故障节点,自动进行主从切换,对应用无感知。

对话DDM 华为云PAAS分布式数据库中间件全解析

( 附改造前后构架对比图)

小编: 那么应用在微服务架构下,服务会拆分的比原来更多,与数据库的连接数也会增加很多,这是否同样是分布式数据库中间件需要解决的一个重要问题?

DDM: 你说的很对,举个栗子,比如某应用的最大连接数是 2000,未做服务化拆分前,应用程序独享 2000 个数据连接,假设拆分成 100 个微服务,那么为了保证总的连接数不超过 MySQL 的最大连接数,那么每个

微服务能配置的最大连接数就是 20. 这对应用几乎是不可接受。市面上很多分库分表中间件如 Cobar、Atlas 等,对后端 MySQL 的连接池管理是基于分片来实现的,而不具备整个 MySQL 实例的共享互通,抗并发能力被严重削弱。而 DDM 是真正基于 MySQL 实例模式实现的,一个 MySQL 实例下的所有数据库共享一个连接池。这个对于分片来讲,能避免有些库的连接很空闲,有些库的连接不够用的情况,最大限度提高并行性。其中涉及到 session 级别的属性由 DDM 自动维护,应用程序无感知。

小编: 感觉很棒的样子,在这种共享模式下连接数是没有上限的吗?

DDM: DDM 的前端连接与 MySQL 连接对比起来相对轻量级,可以相对轻松支持上万的连接。当然,为了防止单个用户滥用资源,支持设置前端最大连接数限制。

对话DDM 华为云PAAS分布式数据库中间件全解析

( 附改造前后构架对比图)

小编:以上我们聊了一些 DDM 的关键技术,在应用场景上,是否一定要用 DDM 的方式去解决,这里同样也有硬件升级,数据库自身的分区方案,用户该如何选择?

DDM:硬件方案由于成本高和扩展性差的问题在这里就不谈了,而数据库自身的分区表方案,只能局限在一个库内,数据无法跨库跨实例,扩展方案有限,DB 故障和调整都需要应用同步调整,运维难度剧增,升级维护工作量大,小型系统还好,对于大型系统不可接受,长期来看采用分布式数据库中间件是解决之道。

小编:那么我们就来聊聊 DDM 是如何解决的吧,关于上面提到的分片设计,DDM 是如何做的,有没有参考一些业界的做法?

DDM:对于分布式数据库中间件,业内普遍有以下两种做法,第一种,认为分片算法的选择对用户来说是一种心智负担,应该对用户完全隐藏,另外一种观点认为应该给用户完全自由去选择,比如一些开源软件,提供了十几种分片算法。DDM 认为如果完全隐藏分片字段和分片算法的选择,可能会造成不必要的全表扫描,浪费资源,无法做到线性扩展。因为最了解业务的还是用户自己。分片算法过多的确会带来选择上的负担,有些算法存在主要是因为缺少平滑扩容存在的不得已而为之。DDM 设计了三种标准分片算法,hash、range、list,后续酌情开放自定义算法。

小编: 能不能给大家详细介绍下这三种算法?

DDM: 1. hash:hash 算法的特点的数据分布比较均匀,无热点问题,缺点是如果有针对部分范围的查询,需要全分片扫描。hash 类数据扩容需要迁移数据,DDM 有平滑扩容功能,所以这块不用担心。
2. range:数据按数字范围或者日期范围进行分片,针对范围的查询可以并行,但是缺点范围是单个范围可能会有热点问题,比如按日期最近一个月的数据操作会比较多,按范围就只其中一台或少量几台机器可以负担操作。范围分片在扩容时不需要迁移数据,只需要将新范围配置到新加的 RDS 即可。
3. list:枚举分片可以看做 range 的一个特例,在此不再赘述。

小编: 能否再讲一下 hash 算法的设计?

DDM: hash 算法的设计,主要考虑到与平滑扩容的配合,采用二级映射分片规则,主要为了方便控制 slot 到实际 dataNode 的映射关系,而一致性哈希这里是算法固定。

小编: 那么与传统方案相比,DDM 在扩容上有什么独特的优势?

DDM: 传统做法 DBA 手工迁移数据,要停机,影响业务,迁移过程可能会出错。业内很多中间件的实现扩容方式一般是按照整库迁移的方案,比如原先有 8 个分库,迁移只是将部分库整库迁移到新的 RDS 上,这样的弊端是分片个数并没有增加。DDM 的做法是真正实现了数据重分布,按 slot 为单位迁移数据,迁移完成后保证数据的大致分布均匀。分片个数随着新增 RDS 而自动增加。DDM 在操作上真正做到了自动化,实现了一键式迁移,迁移过程中切换路由、清理数据均是自动化完成,不需要用户时刻盯着再去操作。即使迁移中出现异常,也会自动回滚,保证迁移数据的一致性。迁移过程中不阻塞业务,只在切换路由时短暂中断写入操作,读操作正常,而且只影响到被迁移的那部分数据的写入,对其他数据完全没有影响。

对话DDM 华为云PAAS分布式数据库中间件全解析

( 附迁移流程图)

小编: 在路由切换速度和内容准确性上 DDM 有哪些考虑?

DDM: 关于切换路由速度,虽然业内很多号称毫秒级,一般是省略了数据校验,或者只校验条数。号称是算法精巧已经测试比较充分了。DDM 认为即使测试已经充分了也难以保证百分之一百保证不出问题。所以 DDM 通过设计了快速的校验算法,对数据的内容进行校验,即使数据有一点点不一样,算法也能校验出来,同时充分利用了 RDS 的计算能力提高校验的速度。

小编: 我们知道在一般的大型应用里,有的表数据量很大,有的表数据量少且不怎么更新,那么 DDM 是如何做到不同类型场景的支持?

针对业务会遇到的实际场景,DDM 设计了三种表类型:分片表:针对那些数据量很大的表,需要切分到多个分片库的表,这样每个分片都有一部分数据,所有分片构成了完整的数据;单表:针对数据量相对比较少,没有和其他分片表 join 查询的需求。单表数据保存在默认当一个分片上,这种设计可以尽量兼容单表自身的复杂查询;全局表:针对数据量和更新都比较少,但是和其它分片表有 join 的需求。全局表每个分片上保存一份完全一样的数据,这样可以解决与分片表的 join 直接下推到 RDS 上执行。

小编: 看来真是很难问倒你,在分布式条件下,原有数据库中的主键约束将无法使用,是不是需要引入外部机制保证数据唯一性标识,那么这种全局唯一序列 DDM 是如何保证的呢?

DDM: DDM 全局唯一序列,使用方法与 MySQL 的 AUTO_INCREMENT 类似。目前 DDM 可以保证该字段全局唯一和有序递增,但不保证连续性。目前 DDM 设计了 2 种类型的序列机制,DB 和 TIME。DB 方式的序列是指通过 DB 来实现,需要注意步长的设置,步长直接关系到序列的性能,步长的大小决定了一次批量取序列的大小。TIME 序列使用了时间戳加机器编号的生成方式,好处是无需通讯即可保证唯一性。

小编: 好吧,运维监控方面呢,给大家带来哪些惊喜没有?

DDM: 采用传统中间件运维完全需要自己运维,一般中间件专注核心功能,较少考虑运维和图形化界面的操作。DDM 充分利用云化的优势,提供了对实例、逻辑库、逻辑表、分片算法等的全面图形化界面操作。同时可以在线查看慢 SQL 等监控内容,方便对系统进行针对性的性能调优。

小编: 最后能不能给大家爆一些小料,未来 DDM 会往什么方向发展,后面准备给大家带来哪些新特性。

DDM: 感谢大家的关注,DDM 未来方向对分布式事务、分布式查询能力增强、性能的优化等,考虑到有些特性实现如果只从中间件层面实现会限制比较多。DDM 会通过与数据库底层的修改进行配合,一起提供更优秀的特性来满足大家业务的需求。

本文转载自公众号中间件小哥(ID:huawei_kevin)。

原文链接:

https://mp.weixin.qq.com/s/21XsmoQ3GNqD3c5yvcICSQ

评论

发布