8620-84511745

Blog Post

基于mycat分布式数据库解决方案的学习汇总

(转发)2016-03-18 数据库集中营

最近公司推荐了mycat分布式中间件解决数据库分布式方案,今天到mycat官网学了一翻(http://www.mycat.org.cn),汇总下几个重点

  • mycat是什么?
  • mycat常见的双中心双活部署方案(还需进一步验证)
  • 常见的数据库切分优化方案
  • mycat的几个主要组成概念
  • 概念介绍之:【实施难点】分库分
  • 概念介绍之:读写分离
  • 概念介绍之:高可用
  • 概念介绍之:运维工具

1、mycat是什么?

mycat是一个开源的分布式数据库系统,是一个实现了 MySQL 协议的Server,前端用户可以把它看作是一个数据库代理,用 MySQL 客户端工具和命令进行访问,后端可以用 MySQL 原生(Native)协议访问数据库(不限于MYSQL数据库), 其核心功能是分表分库,即将一个多表水平分割为 N 个小表,存储在后端的数据库中。

以下是几种通俗的方式介绍MYCAT:

1)对于 DBA 来讲:

Mycat 就是 MySQL Server,而 Mycat 后面连接的 MySQL Server,就好象是 MySQL 的存储引擎,如 InnoDB,MyISAM 等,因此,Mycat 本身并不存储数据,数据是在后端的 MySQL 上存储的,因此数据可靠性 以及事务等都是 MySQL 保证的,简单的说,Mycat 就是 MySQL 最佳伴侣,它在一定程度上让 MySQL 拥有了 能跟 Oracle PK 的能力。

2)对于开发来讲:

Mycat 就是一个近似等于 MySQL 的数据库服务器,你可以用连接 MySQL 的方式去连接 Mycat(除了端 口不同,默认的 Mycat 端口是 8066 而非 MySQL 的 3306,因此需要在连接字符串上增加端口信息),大多数 情况下,可以用你熟悉的对象映射框架使用 Mycat,但建议对于分片表,尽量使用基础的 SQL 语句,因为返样能 达到最佳性能,特别是几千万甚至几百亿条记录的情况下。

3)对于架构师来讲:

Mycat 是一个强大的数据库中间件,不仅仅可以用作读写分离、以及分表分库、容灾备份,而且可以用于多 租户应用开发、平台基础设施、让你的架构具备很强的适应性和灵活性,借助于即将发布的 Mycat 智能优化模 块,系统的数据访问瓶颈和热点一目了然,根据返些统计分析数据,你可以自动或手工调整后端存储,将不同的 表映射到不同存储引擎上,而整个应用的代码一行也不用改变。

2、mycat常见的双中心双活部署方案(还需进一步验证

1)总体部署

屏幕快照 2016-04-06 下午3.39.11.png

2)双活部署

mycat、zk均采用双中心部署

数据库节点考虑如下方案:

屏幕快照 2016-04-06 下午3.40.29.png

3、常见的数据库切分优化方案

传统数据库存在着先天性的弊端,但是 NoSQL 数据库又无法将其替今,NoSQL 只能作 为传统数据的补充而不能将其替今,数据库性能优化除了在应用层对数据检索方面的调优,在架构方面主要对数据库进行切分,接下来主要从数据库切分的两个方面进行介绍:

1)垂直切分:

如果应用系统各业务或服务之间的耦合度低,相互影响小,可以接不同的模块分解,将数据库切分到不同的数据库。

2)水平切分:

上面垂直切分,当某个业务量很大时仍然会有性能问题,比如某个表的数据量过大,这时需要进行水平切分,将大表切分为多个子表。各个子表之间根据预先设置的分布规则,再通过数据库查询JOIN在一起。

水平分片常见的规则有:

  • 用户ID
  • 日期
  • 其它特定的字段

屏幕快照 2016-04-06 下午3.43.21.png

有了数据分布,现在要解决的问题是如何让应用更加透明的访问分片的数据,目前主要有两种思路:

1)客户端模式:在每个应用程序模块中配置管理自己需要的一个或多个数据源,直接访问各个数据库,在模块内完成数据的整合;

2)通过中间代理层来统一管理数据源,后端数据库集群对前端应用程序透明;

mycat提供了模式2的解决方案。

不过,因为分片需要注意以下几件事:

能不切分尽量不切分 如果要切分要选择合适的规则 数据切分尽量通过数据冗余或表分组来降低跨库JOIN的可能

4、mycat的几个主要组成概

MyCAT使用MySQL的通讯协议模拟成一个MySQL服务器,并建立了完整的Schema(数据库)、Table (数据表)、User(用户)的逻辑模型,并将这套逻辑模型映射到后端的存储节点DataNode(MySQL Instance)上的真实物理库中,这样一来,所有能使用MySQL的客户端以及编程语言都能将MyCAT当成是MySQLServer来使用,不必开发新的客户端协议。

当MyCAT收到一个客户端发送的SQL请求时,会先对SQL进行语法分析和检查,分析的结果用于SQL路由,SQL路由策略支持传统的基于表格的分片字段方式进行分片,也支持独有的基于数据库E-R关系的分片策略,对于路由到多个数据节点(DataNode)的SQL,则会对收到的数据集进行“归并”然后输出到客户端。

SQL执行的过程,简单的说,就是把SQL通过网络协议发送给后端的真正的数据库上进行执行,对于MySQL Server来说,是通过MySQL网络协议发送报文,并解析返回的结果,若SQL不涉及到多个分片节点,则直接返回结果,写入客户端的SOCKET流中,这个过程是非阻塞模式(NIO)。 DataNode是MyCAT的逻辑数据节点,映射到后端的某一个物理数据库的一个Database,为了做到系统高可用,每个DataNode可以配置多个引用地址(DataSource),当主DataSource被检测为不可用时,系统会自动切换到下一个可用的DataSource上,这里的DataSource即可认为是Mysql的主从服务器的地址。

在介绍mycat的主要组成部份时,先了解一下MYCAT的原理: MyCat技术原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。

1)数据库中间件

数据被分到多个分片数据库后,应用如果需要读取数据,需要多个数据源的数据,如果没有数据库中间件,那么应用需要花大量的工作去处理分片后的数据访问问题,所以mycat首先是一个数据库中间件,对于数据库能用的事务、数据处理由中间件处理。

数据库中间件的方式,使底层分布式数据对于上层应用而言是透明的,相当一个逻辑数据库。

2)逻辑表

上面提到MYCAT是一个逻辑库,那上面的表即是逻辑表,具体包括:

  • 分片表:一个表被切分多个表部署在多个为上;
  • 非分片表:不需要分片的表
  • ER表:父子关联的表,为了保证效率,数据上有关联的表需要放在一个库上,减少跨库访问
  • 全局表:变动不频繁、能用的配置、参数类型的表 3)分片节点:

数据切分到多个不同的数据库,切分后的数据库可以按主从方式组成一组,分片节点就是datanode

4)分片规则: 数据分片需要提前定好规则,即大表要被分成若干分片表,要有一定的规则。

5)常用的几个配置文件 MyCAT目前通过配置文件的方式来定义逻辑库和相关配置: · MYCAT_HOME/conf/schema.xml中定义逻辑库,表、分片节点等内容; · MYCAT_HOME/conf/rule.xml中定义分片规则; · MYCAT_HOME/conf/server.xml中定义用户以及系统相关变量,如端口等。

5、重点概念介绍之:【实施难点】分库分

首先先讲讲分库分表的步骤:

1)寻找大表:

2)扩大拆分表范围:有些表的数据可能没有达到预定的大表数据量,但这些表与第一步提到的大表有关联查询,这些表需要一并找出来,然后定分片算法和拆分策略

3)定分片策略:这项工作很重要不仅需要懂mycat的同学参与,还需要懂应用的同学参与进来。

以下是互联网上的一个案例以上面几点的说明:

1)单表数据量在800以上视为大表

2)针对业务特点,按经营区域、订单单位、管理城市、经营城市、店铺、时间等进行拆分

3)对于部份字段拆表仍很大的情况,采用多个字段共同拆表

接下来讲讲分片的细节: 现在大部分表都不是孤立存在,以一个用户表与用户明细表为例,为了能够执行t_user与t_user_detail的联合查询, MyCAT将子表的存储位置依赖于主表,并且物理上紧邻存放,解决了JOIN的效率和性能问题,根据这一思路,提出了基于E-R关系的数据分片策略,子表的记录与所关联的父表记录存放在同一个数据分片上。

以t_user与t_user_detail例子为例,schema.xml中定义如下的分片配置:

t_user采用mod-long这个分片策略,分片在dn1-dn32上 t_user_detail依赖父表进行分片,两个表的关联关系为 t_user_detail.user_id=t_user.id。 于是数据分片和存储的示意图如下:

这样一来,分片dn1-32上的t_user与hn1-32上的t_user_detail就可以进行局部的JOIN联合,再合并两个节点的数据即可完成整体的JOIN,试想一下,每个分片上t_user_detail表有1000万条,则10个分片就有1个亿,基于E-R映射的数据分片模式,基本上解决了80%以上的企业应用所面临的问题。 多对多的表通常情况下,有以下几种: l 主表+关系表+字典表 l 主表A+关系表+主表B

对于第一种,字典表可以被定义为“全局表”,字典表的记录规模可以在几千到几十万之间,基本是变动比较少的表,由MyCAT自动实时同步到所有分片,这样就可以三个表都做JOIN操作了。

对于第二种,需要从业务角度来看,关系表更偏向哪个表,即“A的关系”还是“B的关系”,来决定关系表跟从那个方向存储。目前还暂时无法很好支持这种模式下的3个表之间的关联。未来版本中将考虑将中间表进行双向复制,以实现从A-关系表 以及B-关系表的双向关联查询。

关于全局表的实现方式,全局表在数据插入或更新的时候,会自动在全局表定义的所有数据节点上执行相同的操作,以保证所有数据节点都一致,由于这个特性,全局表可以跟任何分片或不分片的表格进行JOIN操作。对数据更新不频繁的,规模不是很大的(100万之内)的表都可以定义为MyCAT的全局表,以实现用存储换性能的目标。 配置为:

6、重点概念介绍之:MYSQL主从复制

经验告诉我们数据库的性能问题往往出在SQL查询之上,正常情况下一个查询语句几十毫秒内可以完成,但查询则可能几秒,或几分钟以上。在没有读写分离的系统上,一些复杂的SQL查询会导致数据库CPU爆表,系统陷入瘫痪,严重情况下可能导致数据库崩溃。下面这个是MYSQL提供的主从数据库的机制:

屏幕快照 2016-04-06 下午4.26.06.png

注:主从数据库数据的复制可以通过日志、SQL等方式进行同步、异步、半异步的方式处理。

7、重点概念介绍之:高可用

屏幕快照 2016-04-06 下午4.28.40.png

8、重点概念介绍之:mycat的运维工具(mycat eye)

屏幕快照 2016-04-06 下午4.31.15.png

简单列一下mycat的功能:

1)mycat配置

mycat的服务增减、日志管理等基本配置

2)mycat监控

流量分析、连接分析、活动线程分析、缓冲队列分析、TPS分析、内存分析、JVM性能监控

屏幕快照 2016-04-06 下午4.33.15.png

3)sql监控

按用户统计SQL读写比例、耗时、执行时间、响应时间、排前面的50条SQL语句、高频SQL、耗时长的SQL

Posted in 开源数据库 on Apr 04, 2016