分布式数据库中间件对比

原文出自： https://blog.csdn.net/jornada_/article/details/82947677

通常对于业务记录类随时间会不断增长的数据，当数据量增长到必定量（通常认为整型值为主的表达到千万级，字符串为主的表达到五百万）的时候，性能将遇到瓶颈，同时调整表结构也会变得很是困难。为了不生产遇到这样的问题，在作系统设计时须要预估可能产生的数据量：预估记录主体个数*预估记录主体产生的记录数（e.g.用户订单表预估数据量=预估用户数*单用户产生订单数），预估达到必定量时，就不得不考虑分库分表了，目前国内比较成熟的开源数据库中间件有sharding-jdbc、mycat；而drds是阿里云最近推出的商业产品，考虑到大部分公司都在使用阿里云，作一个全家桶，也是一个不错的选择。接下来将对这三款产品的优缺点及适用场景作以介绍。

 

 

 

        能够看出sharding-jdbc做为一个组件集成在应用内，而mycat则做为一个独立的应用须要单独部署，drds则是阿里云的一个独立产品，不过须要结合rds一块儿使用。从架构上看sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能须要结合具体的代码实现，理论性能能够理解为上限，经过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，因为做为组件存在，须要集成在应用内，意味着做为使用方，必需要集成到代码里，使得开发成本相对较高；另外一方面，因为须要集成在应用内，使得须要针对不一样语言（java、C、PHP……）有不一样的实现（事实上sharding-jdbc目前只支持java），这样组件自己的维护成本也会很高。最终将应用场景限定在由java开发的应用这一种场景下。

sharding-jdbc后续发展为Sharding-Sphere，包含sharding-jdbc、Sharding-Proxy、Sharding-Sidecar

 

 

 

       mycat是支持SQL92标准，遵照Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理。做为对比能够参考上表中的Sharding-Proxy，须要单独部署，因为遵照Mysql原生协议，应用时不须要特殊处理，和使用MySQL是同样的，因此应用场景不受限制；可是mycat不支持二维路由，仅支持单库多表或多库单表，同时因为自定义链接池，这样就会存在mycat自身维护一个链接池，MySQL也有一个链接池，任何一个链接池上限都会成为性能的瓶颈，而mycat的链接池设计也略显粗暴，当请求连接数大于设置链接池上限时直接抛出异常，所以在配置mycat链接池的大小是，须要结合场景作合理设置。总的来讲，mycat以逻辑表的形式屏蔽掉应用处理分库分表的复杂逻辑，遵照Mysql原生协议，跨语言，跨平台，有着更为通用的应用场景。

       DRDS 兼容 MySQL 协议和语法，支持分库分表、平滑扩容、服务升降配、透明读写分离和分布式事务等特性，具有分布式数据库全生命周期的运维管控能力。能够当作mycat的商业化产品，也就是mycat全部的优势它都有，并且做为一个商业化产品使用上更为简单透明，功能也更为丰富；若是不差钱并且正准备对数据作重构，那么drds是一个不错的选择，之因此说准备作数据重构时考虑用drds，是由于drds不是一个简单的作sharding路由，即便原来使用的是rds，也没法经过drds作路由，惟一的办法新建drds实例，定义路由规则（drds支持二维路由），导入历史数据，而后就能够开心的使用drds了。

     而后作个简单总结