数据库(分库分表)中间件对比

分区:对作业透明,分区只不过把存放数据的文本分为了广大小块,例如mysql中的同等张表对诺三只文件.MYD,MYI,frm。

冲早晚之条条框框把数据文件(MYD)和目录文件(MYI)进行了分,分区后底表呢,还是一样张表。分区可以把表分到不同之硬盘上,但未克分红到不同服务器上。

  • 优点:数据不存在多只副本,不必进行数据复制,性能再强。
  • 缺点:分区策略要经过充分考虑,避免多独分区之间的多寡在涉嫌关系,每个分区都是只点,如果有分区宕机,就见面潜移默化到网的利用。

 

分片:对事情透明,在情理实现上分为多单服务器,不同之分片在不同服务器上

个人感觉跟分库没啥区别,只是叫法不雷同只要曾,值得一提的凡关系项目数据库暨nosql数据库分片的概念与处理方式是千篇一律的也?

请求各位看官自行检索有关材料给解答

 

分表:当数据量大至一定水准之时光,都见面招致处理性能的阙如,这个时便不曾法了,只能进行分表处理。也便是将数据库中数据因本分库原则分到差不多独数据表当中,

然,就得把大表变成多只小表,不同之分表中多少不重复,从而加强处理效率。

分表也出星星点点种植方案:

1.
同库分表:所有的分表都当一个数据库中,由于数据库中表名不克再次,因此需要将多少表名起成不同之讳。

  • 瑜:由于还以一个数据库中,公共表,不必进行复制,处理又简短
  • 短:由于还当一个数据库中,CPU、内存、文件IO、网络IO等瓶颈还是无法解决,只能落单表中之数记录数。

      表名不一致,会导后续之拍卖复杂(参照mysql
meage存储引擎来处理)

  1. 差库分表:由于分表在不同之数据库中,这个时节便足以以同一的表名。

  2. 可取:CPU、内存、文件IO、网络IO等瓶颈可以获中解决,表名相同,处理起来相对简便易行

  3. 短:公共表由于在拥有的分表都使运用,因此而开展复制、同步。

    一些凑合的操作,join,group by,order等麻烦顺利进行

参考博客:http://www.cnblogs.com/langtianya/p/4997768.html,http://blog.51yip.com/mysql/949.html

 

分库:分表和分区都是冲同一个数据库里的多寡分离技巧,对数据库性能有早晚提升,但是趁工作数据量的增多,

原本有所的数码都是以一个数据库及的,网络IO及文件IO都汇集在一个数据库及的,因此CPU、内存、文件IO、网络IO都可能会见化系统瓶颈。

当事情体系的数目容量接近或者超单台服务器的容量、QPS/TPS接近或跳单个数据库实例的拍卖极限等

这时候,往往是利用垂直和程度结合的数据拆分方法,把数据服务和多少存储分布及大半令数据库服务器上。

分库只是一个初步说法,更专业号是数额分片,采用类似分布式数据库理论指导的主意实现,对应用程序达到数据服务的通通透明与数量存储的都透明

 

诵读写分离方案

海量数据的囤和走访,通过对数据库进行读写分离,来提升数据的拍卖能力。读写分离它的方案特点是数据库来多单副本,

数据库的描绘操作都集中到一个数据库及,而有的朗诵之操作为,可以说到外数据库及。这样,只要提交多少复制的资金,

哪怕足以让数据库的拍卖压力分解到大半只数据库及,从而大大升级数据处理能力。

 

 

 

图片 1

图片 2

 

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, DB2,
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的盘算。

TDDL源码:https://github.com/alibaba/tb_tddl 
TDDL复杂度相对较高。当前揭晓的文档较少,只开源动态数据源,分表分库有还非开始源,还得依赖diamond,不引进用。

 

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、从库流量配置、动态加载配置起

项目的Github地址是https://github.com/Meituan-Dianping/DBProxy

 

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的分库分表脚论进行打定义分库表,相当的利落。

https://github.com/brucexx/heisenberg(开源版已终止维护)

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公司发布出去的一个中路件。

网站地图xml地图