数据库（分库分表）中间件对⽐
分区：对业务透明，分区只不过把存放数据的⽂件分成了许多⼩块，例如mysql中的⼀张表对应三个⽂件.MYD,MYI,frm。
根据⼀定的规则把数据⽂件(MYD)和索引⽂件（MYI）进⾏了分割，分区后的表呢，还是⼀张表。分区可以把表分到不同的硬盘上，但不能分配到不同服务器上。
优点：数据不存在多个副本，不必进⾏数据复制，性能更⾼。
缺点：分区策略必须经过充分考虑，避免多个分区之间的数据存在关联关系，每个分区都是单点，如果某个分区宕机，就会影响到系统的使⽤。
分⽚：对业务透明，在物理实现上分成多个服务器，不同的分⽚在不同服务器上
个⼈感觉跟分库没啥区别，只是叫法不⼀样⽽已，值得⼀提的是关系型数据库和nosql数据库分⽚的概念以及处理⽅式是⼀样的吗？
请各位看官⾃⾏查相关资料予以解答
分表：当数据量⼤到⼀定程度的时候，都会导致处理性能的不⾜，这个时候就没有办法了，只能进⾏分表处理。也就是把数据库当中数据根据按照分库原则分到多个数据表当中，
这样，就可以把⼤表变成多个⼩表，不同的分表中数据不重复，从⽽提⾼处理效率。
分表也有两种⽅案：
1. 同库分表：所有的分表都在⼀个数据库中，由于数据库中表名不能重复，因此需要把数据表名起成不同的名字。
优点：由于都在⼀个数据库中，公共表，不必进⾏复制，处理更简单
缺点：由于还在⼀个数据库中，CPU、内存、⽂件IO、⽹络IO等瓶颈还是⽆法解决，只能降低单表中的数据记录数。
      表名不⼀致，会导后续的处理复杂（参照mysql meage存储引擎来处理）
2. 不同库分表：由于分表在不同的数据库中，这个时候就可以使⽤同样的表名。
优点：CPU、内存、⽂件IO、⽹络IO等瓶颈可以得到有效解决，表名相同，处理起来相对简单
缺点：公共表由于在所有的分表都要使⽤，因此要进⾏复制、同步。
    ⼀些聚合的操作，join,group by,order等难以顺利进⾏
分库：分表和分区都是基于同⼀个数据库⾥的数据分离技巧，对数据库性能有⼀定提升，但是随着业务数据量的增加，
原来所有的数据都是在⼀个数据库上的，⽹络IO及⽂件IO都集中在⼀个数据库上的，因此CPU、内存、⽂件IO、⽹络IO都可能会成为系统瓶颈。
当业务系统的数据容量接近或超过单台服务器的容量、QPS/TPS接近或超过单个数据库实例的处理极限等
此时，往往是采⽤垂直和⽔平结合的数据拆分⽅法，把数据服务和数据存储分布到多台数据库服务器上。
分库只是⼀个通俗说法，更标准名称是数据分⽚，采⽤类似分布式数据库理论指导的⽅法实现，对应⽤程序达到数据服务的全透明和数据存储的全透明
读写分离⽅案
海量数据的存储及访问，通过对数据库进⾏读写分离，来提升数据的处理能⼒。读写分离它的⽅案特点是数据库产⽣多个副本，
数据库的写操作都集中到⼀个数据库上，⽽⼀些读的操作呢，可以分解到其它数据库上。这样，只要付出数据复制的成本，
就可以使得数据库的处理压⼒分解到多个数据库上，从⽽⼤⼤提升数据处理能⼒。
1>Cobar 是提供关系型数据库（MySQL）分布式服务的中间件，它可以让传统的数据库得到良好的线性扩展，并看上去还是⼀个数据库，对应⽤保持透明。
Cobar以Proxy的形式位于前台应⽤和实际数据库之间，对前台的开放的接⼝是MySQL通信协议，将前
台SQL语句变更并按照数据分布规则发到合适的后台数据分库，再合并返回结果，模拟单库下的数据库⾏为。
Cobar属于中间层⽅案，在应⽤程序和MySQL之间搭建⼀层Proxy。中间层介于应⽤程序与数据库间，需要做⼀次转发，⽽基于JDBC协议并⽆额外转发，直接由应⽤程序连接数据库，
性能上有些许优势。这⾥并⾮说明中间层⼀定不如客户端直连，除了性能，需要考虑的因素还有很多，中间层更便于实现监控、数据迁移、连接管理等功能。
Cobar属于阿⾥B2B事业，始于2008年，在阿⾥服役3年多，接管3000+个MySQL数据库的schema，集⽇处理在线SQL请求50亿次以上。
由于Cobar发起⼈的离职，Cobar停⽌维护。后续的类似中间件，⽐如MyCAT建⽴于Cobar之上，包括现在阿⾥服役的RDRS其中也复⽤了Cobar-Proxy的相关代码。
2>MyCAT是社区爱好者在阿⾥cobar基础上进⾏⼆次开发，解决了cobar当时存在的⼀些问题，并且加⼊了许多新的功能在其中。⽬前MyCAT社区活跃度很⾼，
⽬前已经有⼀些公司在使⽤MyCAT。总体来说⽀持度⽐较⾼，也会⼀直维护下去，发展到⽬前的版本，已经不是⼀个单纯的MySQL代理了，
它的后端可以⽀持MySQL, SQL Server, Oracle, , PostgreSQL等主流数据库，也⽀持MongoDB这种新型NoSQL⽅式的存储，未来还会⽀持更多类型的存储。
MyCAT是⼀个强⼤的数据库中间件，不仅仅可以⽤作读写分离，以及分表分库、容灾管理，⽽且可以⽤于多租户应⽤开发、云平台基础设施，让你的架构具备很强的适应性和灵活性，
借助于即将发布的MyCAT只能优化模块，系统的数据访问瓶颈和热点⼀⽬了然，根据这些统计分析数据，你可以⾃动或⼿⼯调整后端存储，将不同的表隐射到不同存储引擎上，⽽整个应⽤的代码⼀⾏也不⽤改变。
MyCAT是在Cobar基础上发展的版本，两个显著提⾼：后端由BIO改为NIO，并发量有⼤幅提⾼；增加了对Order By, Group By, Limit等聚合功能
（虽然Cobar也可以⽀持Order By, Group By, Limit语法，但是结果没有进⾏聚合，只是简单返回给前端，聚合功能还是需要业务系统⾃⼰完成）
3>TDDL是Tabao根据⾃⼰的业务特点开发了(Tabao Distributed Data Layer, 外号：头都⼤了)。主要解决了分库分表对应⽤的透明化以及异构数据库之间的数据复制，
它是⼀个基于集中式配置的jdbc datasourcce实现，具有主备，读写分离，动态数据库配置等功能。
TDDL并⾮独⽴的中间件，只能算作中间层，处于业务层和JDBC层中间，是以Jar包⽅式提供给应⽤调⽤，属于JDBC Shard的思想。mysql数据库迁移命令
4>DRDS是阿⾥巴巴⾃主研发的分布式数据库服务（此项⽬不开源）,DRDS脱胎于阿⾥巴巴开源的Cobar分布式数据库引擎，吸收了Cobar 核⼼的Cobar-Proxy，
实现了⼀套独⽴的类似MySQL-Proxy协议的解析端，能够对传⼊的SQL进⾏解析和处理，对应⽤程序屏蔽各种复杂的底层DB拓扑结构，获得单机数据库⼀样的使⽤体验，
同时借鉴了淘宝TDDL丰富的分布式数据库实践经验，实现了对分布式Join⽀持，SUM/MAX/COUNT/AVG等聚合函数⽀持以及排序等函数⽀持，
通过异构索引、⼩表⼴播等解决分布式数据库使⽤场景下衍⽣出的⼀系列问题，最终形成了完整的分布式数据库⽅案。
5>Atlas是⼀个位于应⽤程序与MySQL之间的基于MySQL协议的数据中间层项⽬，它是在mysql-proxy 0.8.2版本上对其进⾏优化，360团队基于mysql proxy 把lua⽤C改写，
它实现了MySQL的客户端和服务端协议，作为服务端与应⽤程序通讯，同时作为客户端与MySQL通讯。它对应⽤程序屏蔽了DB的细节。Altas不能实现分布式分表，所有的字表必须在同⼀台DB的同⼀个
DataBase⾥且所有的字表必须实现建好，Altas没有⾃动建表的功能。
原有版本是不⽀持分库分表，⽬前已经放出了分库分表版本。在⽹上看到⼀些朋友经常说在⾼并发下会经常挂掉，如果⼤家要使⽤需要提前做好测试。
6>DBProxy是美团点评DBA团队针对公司内部需求，在奇虎360公司开源的Atlas做了很多改进⼯作，形成了新的⾼可靠、⾼可⽤企业级数据库中间件
其特性主要有：读写分离、负载均衡、⽀持分表、IP过滤、sql语句⿊名单、DBA平滑下线DB、从库流量配置、动态加载配置项
7>sharding-JDBC是当当应⽤框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库⽔平分⽚框架，实现透明化数据库分库分表访问。
Sharding-JDBC是继dubbox和elastic-job之后，ddframe系列开源的第3个项⽬。
Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本⼏乎为零：
可适⽤于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使⽤JDBC。
可基于任何第三⽅的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
理论上可⽀持任意实现JDBC规范的数据库。虽然⽬前仅⽀持MySQL，但已有⽀持Oracle、SQLServer等数据库的计划。
Sharding-JDBC定位为轻量Java框架，使⽤客户端直连数据库，以jar包形式提供服务，⽆proxy代理层，⽆需额外部署，⽆其他依赖，DBA 也⽆需改变原有的运维⽅式。
Sharding-JDBC分⽚策略灵活，可⽀持等号、between、in等多维度分⽚，也可⽀持多分⽚键。
SQL解析功能完善，⽀持聚合、分组、排序、limit、or等查询，并⽀持Binding Table以及笛卡尔积表查询。
知名度较低的：
Heisenberg
Baidu.
其优点：分库分表与应⽤脱离，分库表如同使⽤单库表⼀样，减少db连接数压⼒，热重启配置，可⽔平扩容，遵守MySQL原⽣协议，读写分离，⽆语⾔限制，
mysqlclient, c, java都可以使⽤Heisenberg服务器通过管理命令可以查看，如连接数，线程池，结点等，并可以调整采⽤velocity的分库分表脚本进⾏⾃定义分库表，相当的灵活。
CDS
JD. Completed Database Sharding.
CDS是⼀款基于客户端开发的分库分表中间件产品，实现了JDBC标准API，⽀持分库分表，读写分离和数据运维等诸多共，提供⾼性能，⾼并发和⾼可靠的海量数据路由存取服务，
业务系统可近乎零成本进⾏介⼊，⽬前⽀持MySQL, Oracle和SQL Server.
(架构上和Cobar，MyCAT相似，直接采⽤jdbc对接，没有实现类似MySQL协议，没有NIO,AIO，SQL Parser模块采⽤JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)
DDB
⽹易. Distributed DataBase.
DDB经历了三次服务模式的重⼤更迭：Driver模式->Proxy模式->云模式。
Driver模式：基于JDBC驱动访问，提供⼀个db.jar, 和TDDL类似，位于应⽤层和JDBC之间. Proxy模式：在DDB中搭建了⼀组代理服务器来提供标准的MySQL服务，
在代理服务器内部实现分库分表的逻辑。应⽤通过标准数据库驱动访问DDB Proxy, Proxy内部通过MySQL解码器将请求还原为SQL, 并由DDB Driver执⾏得到结果。
私有云模式：基于⽹易私有云开发的⼀套平台化管理⼯具Cloudadmin, 将DDB原先Master的功能打散，⼀部分分库相关功能集成到proxy 中，
如分库管理、表管理、⽤户管理等，⼀部分中⼼化功能集成到Cloudadmin中，如报警监控，此外，Cloudadmin中提供了⼀键部署、⾃动和⼿动备份，版本管理等平台化功能。
OneProxy:
数据库界⼤⽜，前⽀付宝数据库团队领导楼⽅鑫开发，基于mysql官⽅的proxy思想利⽤c进⾏开发的，OneProxy是⼀款商业收费的中间件，楼总舍去了⼀些功能点，
专注在性能和稳定性上。有朋友测试过说在⾼并发下很稳定。
Oceanus(58同城数据库中间件)
Oceanus致⼒于打造⼀个功能简单、可依赖、易于上⼿、易于扩展、易于集成的解决⽅案，甚⾄是平台化系统。拥抱开源，提供各类插件机制集成其他开源项⽬，
新⼿可以在⼏分钟内上⼿编程，分库分表逻辑不再与业务紧密耦合，扩容有标准模式，减少意外错误的发⽣。
Vitess:
这个中间件是Youtube⽣产在使⽤的，但是架构很复杂。与以往中间件不同，使⽤Vitess应⽤改动⽐较⼤要使⽤他提供语⾔的API接⼝，我们可以借鉴他其中的⼀些设计思想。
Kingshard:
Kingshard是前360Atlas中间件开发团队的陈菲利⽤业务时间⽤go语⾔开发的，⽬前参与开发的⼈员有3个左右，⽬前来看还不是成熟可以使⽤的产品，需要在不断完善。
MaxScale与MySQL Route:
这两个中间件都算是官⽅的吧，MaxScale是mariadb (MySQL原作者维护的⼀个版本)研发的，⽬前版本不⽀持分库分表。
MySQL Route是现在MySQL 官⽅Oracle公司发布出来的⼀个中间件。
作者：
出处：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。