1、Mycat 应用场景
Mycat 发展到现在,适用的场景已经很丰富,而且不断有新用户给出新的创新性的方案,以下是几个典型的应用场景:
- 1. 单纯的读写分离,此时配置最为简单,支持读写分离,主从切换
- 2. 分表分库,对于超过 1000 万的表进行分片,最大支持 1000 亿的单表分片
- 3. 多租户应用,每个应用一个库,但应用程序只连接 Mycat,从而不改造程序本身,实现多租户化
- 4. 报表系统,借助于 Mycat 的分表能力,处理大规模报表的统计
- 5. 替代 Hbase,分析大数据
- 6. 作为海量数据实时查询的一种简单有效方案,比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果,除了基于主键的查询,还可能存在范围查询或其他属性查询,此时 Mycat 可能是最简单有效的选择。
MYCAT可以实现读写分离下的读 *** 作负,mycat载均衡,将大量的读 *** 作均衡到不同的从库上,主要出现在一主多从情形下。
MYCAT可实现数据库的高可用,在数据库主节点可用的情况下,配置一台可写从节点,这两个节点都配置在MYCAT中,当主节点宕机时,MyCAT会自动将写 *** 作路由到备用节点上,但并不支持在切换之后的继续主从同步。
当读写分离已经不能满足持续增加的访问量时,MYCAT可实现数据库的垂直拆分,将所有的数据库表按照模块划分,不同类型的表拆分到不同的数据库服务器。
随着业务量的增长,垂直拆分之后如果又出现了数据库性能问题,则需要进行水平切分,这就是俗称的分库分表。将数据量很大的表数据切分到不同的服务器库中,表结构是一样的,而使用MYCAT实现水平切分,对前端应用是完全透明的,不用调整前台逻辑。
从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。
MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。而在最终用户看来,无论是那种存储方式,在MyCat里,都是一个传统的数据库表,支持标准的SQL语句进行数据的 *** 作,这样一来,对前端业务系统来说,可以大幅降低开发难度,提升开发速度
2.传统关系型数据库局限性
传统关系型数据库由于缺乏扩展性在面对大数据时存在巨大的缺陷,但是关系模型、事务机制对于大部分系统又不必不可少,目前业界主流的做法就是将传统数据库进行切分(包括垂直切分、水平切分等),提高数据库的可扩展性。但是切分之后又带来了新的问题,比如多数据源管理问题、跨节点join问题、分布式事务问题等。下面探讨Mycat如何解决这些问题。
多数据源管理问题
针对多数据源管理问题,主要有两种解决思路,第一:客户端模式,在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,直接访问各个数据库,在模块内完成数据的整合。第二:通过中间代理层来统一管理所有的数据源,后端数据库集群对前端应用程序透明。第一种方式不具备通用性,每个应用程序都需要自行开发数据整合功能,且对于已经建设完成的系统需要进行代码重构,不适宜推广。目前主要使用的是第二种方式,Mycat 的原理如下: Mycat 的原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。
Mycat的原理与其他分布式数据库中间件很类似,但是在架构上还是有区别,Mycat来源于Cobar,但在其基础上进行了很大改进,Mycat的架构如下:
目前主流的分布式数据库中间件还有TDDL、 Amoeba、 Coba等,TDDL不同于其它几款产品,并非独立的中间件,只能算作中间层,是以Jar包方式提供给应用调用。属于JDBC Shard 的思想,网上也有很多其它类似产品。Amoeba是作为一个真正的独立中间件提供服务,即应用去连接Amoeba *** 作MySQL集群,就像 *** 作单MySQL一样,从架构中可以看来,Amoeba算中间件中的早期产品,后端还在使用JDBC Driver. Cobar 是Amoeba基础上进化的版本,一个显著变化是把后端JDBC Driver改为原生的MySQL通信协议层,这就意味着不能支持Oracle、ProstgreSQL 等主流数据库。MyCat 又是在Cobar基础上发展的版本,后端由BI0改为NIO,并发量有大幅提高,增加了对Order By、GroupBy、limit 等聚合功能的支持,支持目前主流的大部分数据库。
跨节点join问题
Mycat支持inner join、leaf/right join、cross join、 Full join等方式跨节点join,主要是通过全局表,ER分片,Share Join 和catlet(人工智能)四种方式实现:
1、全局表
一个真实的业务系统中,往往存在大量的类似字典表的表格,它们与业务表之间可能有关系,这种关系,可以理解为“标签”,而不应理解为通常的“主从关系”,这些表基本上很少变动,可以根据主键ID进行缓存,下面这张图说明了一个典型的“标签关系”图:
在分片的情况下,当业务表因为规模而进行分片以后,业务表与这些附属的字典表之间的关联,就成了比较棘手的问题,考虑到字典表具有以下几个特性:
- 1.变动不频繁
- 2.数据量总体变化不大
- 3.数据规模不大,很少有超过数十万条记录。
鉴于此,MyCAT定义了一种特殊的表,称之为“全局表”,全局表具有以下特性:
- 1.全局表的插入、更新 *** 作会实时在所有节点上执行,保持各个分片的数据一致性
- 2.全局表的查询 *** 作,只从一个节点获取
- 3.全局表可以跟任何一个表进行J0IN *** 作
将字典表或者符合字典表特性的一些表定义为全局表,则从另外一个方面,很好的解决了数据J0IN的难题。通过全局表+基于ER关系的分片策略,MyCAT可以满足80%以上的企业应用开发。
全局表配置方式如下(全局表会存储于所以节点) :
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对脚本之家的支持。如果你想了解更多相关内容请查看下面相关链接
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)