分布式数据库中间件DDM的示例分析-成都快上网建站

分布式数据库中间件DDM的示例分析

分布式数据库中间件DDM的示例分析,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。

创新互联公司专注于宁海网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供宁海营销型网站建设,宁海网站制作、宁海网页设计、宁海网站官网定制、微信小程序开发服务,打造宁海网络公司原创品牌,更为您提供宁海网站排名全网营销落地服务。

进入云计算时代,传统的数据库在性能和容量等方面已无法满足企业的要求,随着数据量的不断骤增,易于扩展、拆分的数据库解决方案对于企业的云化转型更是显得尤为重要。为使企业应用上云更简单,分布式数据库中间件DDM(Distributed Database Middleware)专注解决企业在上云过程中面临的的数据库瓶颈难题,不但更能轻松满足水平拆分、扩容、读写分离等业务需求,同时也比传统方案更具性价比。接下来让我们一起零距离解密DDM。

DDM是什么?

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

DDM如何定义读写分离?

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

 分布式数据库中间件DDM的示例分析

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

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

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

在这种共享模式下连接数有上限吗?

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

分布式数据库中间件DDM的示例分析

( 附迁移流程图)

 

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

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

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

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

 

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

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

DDM在运维监控方面的优势?

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

 

未来DDM会往什么方向发展?

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

看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。


网页名称:分布式数据库中间件DDM的示例分析
标题网址:http://kswjz.com/article/pdppje.html
扫二维码与项目经理沟通

我们在微信上24小时期待你的声音

解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流