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

    分布式数据库中间件对比 - 图1

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

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

    分布式数据库中间件对比 - 图2
    来源:https://github.com/sharding-sphere/sharding-sphere

    1. mycat是支持SQL92标准,遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理。作为对比可以参考上表中的Sharding-Proxy,需要单独部署,由于遵守Mysql原生协议,应用时不需要特殊处理,和使用MySQL是一样的,所以应用场景不受限制;但是mycat不支持二维路由,仅支持单库多表或多库单表,同时由于自定义连接池,这样就会存在mycat自身维护一个连接池,MySQL也有一个连接池,任何一个连接池上限都会成为性能的瓶颈,而mycat的连接池设计也略显粗暴,当请求链接数大于设置连接池上限时直接抛出异常,因此在配置mycat连接池的大小是,需要结合场景做合理设置。总的来说,mycat以逻辑表的形式屏蔽掉应用处理分库分表的复杂逻辑,遵守Mysql原生协议,跨语言,跨平台,有着更为通用的应用场景。
    2. DRDS 兼容 MySQL 协议和语法,支持分库分表、平滑扩容、服务升降配、透明读写分离和分布式事务等特性,具备分布式数据库全生命周期的运维管控能力。可以看成mycat的商业化产品,也就是mycat所有的优点它都有,而且作为一个商业化产品使用上更为简单透明,功能也更为丰富;如果不差钱而且正准备对数据做重构,那么drds是一个不错的选择,之所以说准备做数据重构时考虑用drds,是因为drds不是一个简单的做sharding路由,即使原来使用的是rds,也无法通过drds做路由,唯一的办法新建drds实例,定义路由规则(drds支持二维路由),导入历史数据,然后就可以开心的使用drds了。

    然后做个简单总结

    分布式数据库中间件对比 - 图3