搭建ORACLE高可用 高性能 高扩展的 MMM_APE 架构

除了ORACLE 目前 提倡的MMA 架构体系 只是达到高可用而已. 互联网电商系统 大部分用的MYSQL 堆砌几十台机器来支持千万级 亿级 架构.
一般简单的MYSQL 主从架构和MHA 都能达到百万级 PV UV 还是QPS.....
一般来说一个数据库每天查询操作长很大的比例. 比如我如今管理的ORACLE 单机实列,可以达到百万级

日期	总操作量	查询	查询占比	更新	更新占比	插入	插入占比	删除	删除占比
2016/4/28	3,358,971	2,820,150	83.96%	322,394	9.60%	163,165	4.86%	49,182	1.46%
2016/4/29	1,837,178	1,707,191	92.92%	73,954	4.03%	40,539	2.21%	10,209	0.56%
2016/4/30	1,297,660	1,182,675	91.14%	63,457	4.89%	35,796	2.76%	8795	0.68%
2016/5/1	1,385,831	1,247,982	90.05%	75,081	5.42%	40,314	2.91%	11,911	0.86%
2016/5/2	1,120,262	998,707	89.15%	68,315	6.10%	35,321	3.15%	7840	0.70%

在ORACLE 里面有两大性能问题 那就是并发量和数据量. 一般系统这两个都在一个数据库里. 在MYSQL世界里什么分库,分表,水平,垂直.再来个什么中间代理.
一直以来ORACLE追求的是高可用,单机实列性能高并发. 它那套复杂的共享池,和复杂的数据缓存池. 当扩展性就差强人意了.
就拿RAC来说 大家搭建的大部分是双实列的.顶多4个实列.虽然ORACLE公司说可以达到16还是255个,当实践检验得出差过了4个会线性递减.
因为内存融合技术,和网络通信成本极大地降低了扩展后的性能.
不过也说来RAC 本身就不是追求高扩展,高性能的. 它是追求高可用,高并发的. 比如说单实列挂了,可以在秒级别上不丢失任何数据前下自动地转移到另外实列.
高并发,这里是指事务 就是 更新和插入. 本身单实列的并发能力高于MYSQL ,再加上多实列的RAC自然比MYSQL强很多. 虽然也带来递减.只要设计得好,递减效果就少.
要应对高的查询量 RAC就不太胜能了.
当可以通过11G的 ACTIVE DATA GUARD技术 已经CASECADE DG技术得到 亿级QPS量
好吧 说了那么多 上图



从上图来看RAC 负责写入和更新删除操作. 查询操作由CASE CADE DG 三台来完成
它的数据来源于 中间备库来传递. 另外中间备库通过GOLDEN GATE工具 把数据传给报表数据库
应用服务器TOMCATE 通过三个数据源接口 分别连接 RAC CASECADEDG和报表数据库

报表数据库采用的32KB的数据块,采用表空间压缩 并行技术 来支持报表系统
RAC可以采用 当前表, 散列表 历史表 分区表技术结合在一起 在分区表或者历史表多建索引. 而当前表 少建索引.
建索引就是为了支持CASECADE DG 的查询操作.

应用服务器客户端TNS 采用LAOD_BANCE 来负载均衡.

注意这只是一个业务的架构.

业务多了话 那就要业务分离 正常业务,特殊业务,异常业务的分离

这里还没有用到NOSQL 和REDIS 服务.