从oracle到mysql,主从到分库,一个普通项目数据库架构的变迁
2016-11-10 14:51
951 查看
为了节约成本,也是为了顺应去IOE这个大时代的发展,项目的数据库从最初的Oracle切到了MySQL。
开始切到MySQL的时候项目才上线时间不长,当时数据不多,而且当时预计在较长一段时间内数据也不会发生爆炸式的变化,考虑到大部分是读的请求所以考虑用主从架构。
注:存储引擎用的是InnoDB,当时主要是考虑事物的需求,其实在选择存储引擎的时候没有特殊需求都应该选择InnoDB,关于InnoDB和MyISam的区别可参考:MySQL存储引擎之MyISAM、InnoDB详细对比。
市面上目前开源且比较有名字的中间件主要有3种,分别是360的atlas、阿里巴巴的Cobar(目前也有叫MyCat,其实应该都是说同一个东西)、淘宝的TDDL。
Atlas https://github.com/Qihoo360/Atlas/wiki
我们将Atlas作为主从架构的中间件,之所以选择Atlas是因为其简单只是做个纯转发的操作,所以对SQL语句的支持度也是很好的,且具有以下特性能满足我们的需求:
1、实现读写分离;
2、实现分表;
3、主库宕机会被自动摘掉不影响从库的读,从库宕机也会被自动摘掉不影响应用;
4、通过管理接口,简化管理工作,DB的上下线对应用完全透明,同时可以手动上下线;
5、所有MYSQL支持的SQL,Atlas都支持。换句话说:Atlas并不分析SQL,只是把SQL语句路由到对应数据库节点;
6、支持事物:事物内SQL全部走写节点;
7、为了解决读写分离存在写完马上就想读而这时可能存在主从同步延迟的情况,Altas中可以在SQL语句前增加 /*master*/ 就可以将读请求强制发往主库;
8、能通过client-ips参数对有权限连接Atlas的ip进行过滤;
9、日志中记录所有通过Atlas处理的SQL语句,包括客户端IP、实际执行该语句的DB、执行结果以及耗费的时间。
Atlas架构图:
缺点:
1、Atlas在主库或者从库宕机摘掉后不会自动恢复,需要自己手动去或者写心跳脚本去处理;
2、不能实现分布式分表,所有的子表必须在同一台DB的同一个database里。
Cobar
随着接入应用的激增,token表数据在未来可预计的时间内会发生重大变化,单表数据太大主从明显已经力不从心,故而考虑了分库分表,对于此种业务场景cobar是不二的选择。我们使用cobar的一个很重要的考量是团队中有人阅读过并具有修改相关代码的能力,且公司中其他团队有相关的成功使用经验。
cobar架构图:
优点:
1、Mycat支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分;
2、Mycat支持将不同的表放入不同的库。
缺点:
1、支持标准SQL99语法,不支持部分Mysql特定的SQL。
2、分库字段不能UPDATE。
3、查询条件中尽量带分库字段,否则扫描所有分库节点合并结果集。
4、数据库中新增表后,Mycat中必须修改配置文件,增加表配置。
5、对事物的支持不够好,不支持SAVEPOINT操作。
6、不支持跨库情况下的join、分页、排序、子查询操作。
7、分库情况下,insert语句必须包含拆分字段列名。
8、分库情况下,update语句不能更新拆分字段的值。
开始切到MySQL的时候项目才上线时间不长,当时数据不多,而且当时预计在较长一段时间内数据也不会发生爆炸式的变化,考虑到大部分是读的请求所以考虑用主从架构。
注:存储引擎用的是InnoDB,当时主要是考虑事物的需求,其实在选择存储引擎的时候没有特殊需求都应该选择InnoDB,关于InnoDB和MyISam的区别可参考:MySQL存储引擎之MyISAM、InnoDB详细对比。
市面上目前开源且比较有名字的中间件主要有3种,分别是360的atlas、阿里巴巴的Cobar(目前也有叫MyCat,其实应该都是说同一个东西)、淘宝的TDDL。
Atlas https://github.com/Qihoo360/Atlas/wiki
我们将Atlas作为主从架构的中间件,之所以选择Atlas是因为其简单只是做个纯转发的操作,所以对SQL语句的支持度也是很好的,且具有以下特性能满足我们的需求:
1、实现读写分离;
2、实现分表;
3、主库宕机会被自动摘掉不影响从库的读,从库宕机也会被自动摘掉不影响应用;
4、通过管理接口,简化管理工作,DB的上下线对应用完全透明,同时可以手动上下线;
5、所有MYSQL支持的SQL,Atlas都支持。换句话说:Atlas并不分析SQL,只是把SQL语句路由到对应数据库节点;
6、支持事物:事物内SQL全部走写节点;
7、为了解决读写分离存在写完马上就想读而这时可能存在主从同步延迟的情况,Altas中可以在SQL语句前增加 /*master*/ 就可以将读请求强制发往主库;
8、能通过client-ips参数对有权限连接Atlas的ip进行过滤;
9、日志中记录所有通过Atlas处理的SQL语句,包括客户端IP、实际执行该语句的DB、执行结果以及耗费的时间。
Atlas架构图:
缺点:
1、Atlas在主库或者从库宕机摘掉后不会自动恢复,需要自己手动去或者写心跳脚本去处理;
2、不能实现分布式分表,所有的子表必须在同一台DB的同一个database里。
Cobar
随着接入应用的激增,token表数据在未来可预计的时间内会发生重大变化,单表数据太大主从明显已经力不从心,故而考虑了分库分表,对于此种业务场景cobar是不二的选择。我们使用cobar的一个很重要的考量是团队中有人阅读过并具有修改相关代码的能力,且公司中其他团队有相关的成功使用经验。
cobar架构图:
优点:
1、Mycat支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分;
2、Mycat支持将不同的表放入不同的库。
缺点:
1、支持标准SQL99语法,不支持部分Mysql特定的SQL。
2、分库字段不能UPDATE。
3、查询条件中尽量带分库字段,否则扫描所有分库节点合并结果集。
4、数据库中新增表后,Mycat中必须修改配置文件,增加表配置。
5、对事物的支持不够好,不支持SAVEPOINT操作。
6、不支持跨库情况下的join、分页、排序、子查询操作。
7、分库情况下,insert语句必须包含拆分字段列名。
8、分库情况下,update语句不能更新拆分字段的值。
相关文章推荐
- 从oracle到mysql,主从到分库,一个普通项目数据库架构的变迁
- 项目实战7—Mysql实现企业级数据库主从复制架构实战
- 数据库高可用架构(MySQL、Oracle、MongoDB、Redis)
- MySQL 数据库主从复制架构
- 数据库高可用架构(MySQL、Oracle、MongoDB、Redis)
- MySQL 数据库主从复制架构
- SSH2+mySQL整合项目,在由一个名为A的DB,转到B的DB时,项目还是连到之前的A数据库之原因
- [数据库测试]强烈推荐一个python ODBC数据源插件,可支持Oracle,Db2,Mysql,Sql-server以及各种数据库版本,附例子和测试程序
- MySQL 数据库主从复制架构
- MySQL 数据库主从复制架构
- 搭建mysql主从数据库实现双机热备架构
- 一个访问mysql 数据库的 shiny 项目
- 刚刚接手的一个项目要用oracle数据库。把一些SQL SERVER2005的表导入过去以后发现查询时有问题,比如登陆时的查询
- 以一个权限系统来告别WebForm —(一)项目整休架构设计与数据库设计
- MySQL 数据库主从复制架构
- [数据库测试]强烈推荐一个python ODBC数据源插件,可支持Oracle,Db2,Mysql,Sql-server以及各种数据库版本,附例子和测试程序
- [数据库测试]强烈推荐一个python ODBC数据源插件,可支持Oracle,Db2,Mysql,Sql-server以及各种数据库版本,附例子和测试程序
- 一个项目中说系统分为表现层、控制层、逻辑层、DAO层和最终数据库五层架构-转
- MySQL 数据库主从复制架构
- MySQL 数据库主从复制架构