前言
MyCAT 名称来看是我的猫的意思,它其实是一款完全开源分库分表的通用性数据库中间件,它的父亲出身名门:“阿里巴巴” 名字叫“Cobar”.so 支持最好的就是MySQL数据库辣。
Cobar曾经广为流传,据说最早的发起 者对 Mysql 很精通,后来从阿里跳槽了,阿里随后开源的 Cobar,并维持到 2013 年年初,然后,就没有然后 了。
对于阿里现在使用的otter、 cancel 的数据库相关产品,其基本原理就是伪装成一个MySQL 服务器 来骗取信任,以便快速获取二进制等信息来进行路由实现,并在其内部进行了优化。
Cobar 前期成功替代了原先基于 Oracle 的数据存储方案,目前已经接管了 3000+个 MySQL 数据库的 schema,平均每天处理近 50 亿次的 SQL 执行请求。
社区网站的一句话确实是触动了小编的内心: MYCAT并不依托于任何一个商业公司,因此不像某些开源项目,将一些重要的特性封闭在其商业产品中,使得开源项目成了一个摆设。
MyCAT文件下载地址:
原理
Mycat 的原理并不复杂,复杂的是代码,如果代码也不复杂,那么早就成为一个传说了。
Mycat 的原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的 SQL 语句,首先对 SQL 语句做了
一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分析等,然后将此 SQL 发往后端的真实数据库, 并将返回的结果做适当的处理,最终再返回给用户。
从而使用MyCat+MySQL实现了一个伪安全分布式数据架构.
危险因素
对于这种可以无限分表和表分区都是同理的技术方案。一张大表,可以按照各种切分策略来搞到各个数据库,各个物理机上,想没想过,如果一旦mysql路由器崩溃了怎么办!
你切分的越多,危险系数越大。所以拆分策略很重要。小编建议以下几点
1、mysql路由服务器也要搭建成高可用的集群模式 (但是增加了架构的复杂性)
2、 尽量不要分的太复杂,同时有备用的其他路由 模型。
使用中间件,前期一定要做大量的调研,有哪些坑,都要调研的很清楚。并且要有一个比较长的周期性的灰度测试。如果就只有1、2个数据量不是很大的表、可以尝试使用Sharding jdbc方式来快速业务端快速进行实现,无疑增大业务逻辑的开发量和复杂度。
MyCAT分库分表术语概念
1、逻辑库(schema)
针对业务开发人员不需要知道有这个Mycat的数据库中间件的存在,所以数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。
2、逻辑表(table)
既然有逻辑库,那么就会有逻辑表,分布式数据库中,对应用来说,读写数据的表就是逻辑表。逻辑表,可 以是数据切分后,分布在一个或多个分片库中,也可以不做数据切分,不分片,只有一个表构成。
3、分片表
分片表,是指那些原有的很大数据的表,需要切分到多个数据库的表,这样,每个分片都有一部分数据,所 有分片构成了完整的数据。
4、非分片表
非分片是相对分片表来说的,就是那 些不需要进行数据切分的表。
5、ER 表
子表的记录与所关 联的父表记录存放在同一个数据分片上,即子表依赖于父表,通过表分组(Table Group)保证数据 Join 不会跨
库操作。
6、全局表
一个真实的业务系统中,往往存在大量的类似字典表的表,这些表基本上很少变动。
• 变动不频繁;
• 数据量总体变化不大;
• 数据规模不大,很少有超过数十万条记录。
Mycat 中通过数据冗余来解决这类表的 join,即所有的分片都有一份数据的拷 贝,所有将字典表或者符合字典表特性的一些表定义为全局表。
7、分片节点(dataNode)
数据切分后,一个大表被分到不同的分片数据库上面,每个表分片所在的数据库就是分片节点。
8、节点主机(dataHost)
数据切分后,每个分片节点(dataNode)不一定都会独占一台机器,同一机器上面可以有多个分片数据库, 这样一个或多个分片节点(dataNode)所在的机器就是节点主机(dataHost),为了规避单节点主机并发数限 制,尽量将读写压力高的分片节点(dataNode)均衡的放在不同的节点主机(dataHost)
9、分片规则(rule)
前面讲了数据切分,一个大表被分成若干个分片表,就需要一定的规则,这样按照某种业务规则把数据分到 某个分片的规则就是分片规则,数据切分选择合适的分片规则非常重要,将极大的避免后续数据处理的难度。
10、全局序列号(sequence)
数据切分后,原有的关系数据库中的主键约束在分布式条件下将无法使用,因此需要引入外部机制保证数据 唯一性标识,这种保证全局性的数据唯一标识的机制就是全局序列号(sequence)。
11、多租户
实现如何于多用户的环境下共用相同的 系统或程序组件,并且仍可确保各用户间数据的隔离性。阿里云的一些共享主机,就做的不错~。
12、 独立数据库
即一个租户一个数据库,这种方案的用户数据隔离级别最高,安全性最好,但成本也高。
这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。如果面对
的是银行、医院等需要非常高数据隔离级别的租户,可以选择这种模式,提高租用的定价。如果定价较低,产品 走低价路线,这种方案一般对运营商来说是无法承受的。
13、共享数据库,隔离数据架构
即多个或所有租户共享 Database,但是每个租户一个 Schema。
优点:
为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可以支持更多的租
户数量。
缺点:
如果出现故障,数据恢复比较困难,因为恢复数据库将牵扯到其他租户的数据;
如果需要跨租户统计数据,存在一定困难。
14、共享数据库,共享数据架构
即租户共享同一个 Database、同一个 Schema,但在表中通过 TenantID 区分租户的数 据。这是共享程度最高、隔离级别最低的模式。
优点:
维护和购置成本最低,允许每个数据库支持的租户数量最多。
缺点:
隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量;
数据备份和恢复最困难,需要逐表逐条备份和还原;
如果希望以最少的服务器为最多的租户提供服务,并且租户接受以牺牲隔离级别换取降低成本,这种方案最适合。
参考:Mycat权威指南