垂直拆分
垂直拆分就是要把表按模块划分到不同数据库表中(当然原则还是不破坏第三范式),这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候,只有小量的人来开发和维护,各模块和表都在一起,当网站不断丰富和壮大的时候,也会变成多个子系统来支撑,这时就有按模块和功能把表划分出来的需求。其实,相对于垂直切分更进一步的是服务化改造,说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务,通过服务间的调用来满足业务需求看,因此表拆出来后要通过服务的形式暴露出去,而不是直接调用不同模块的表,淘宝在架构不断演变过程,最重要的一环就是服务化改造,把用户、交易、店铺、宝贝这些核心的概念抽取成独立的服务,也非常有利于进行局部的优化和治理,保障核心模块的稳定性
垂直拆分:单表大数据量依然存在性能瓶颈
水平拆分
上面谈到垂直切分只是把表按模块划分到不同数据库,但没有解决单表大数据量的问题,而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如像计费系统,通过按时间来划分表就比较合适,因为系统都是处理某一时间段的数据。而像SaaS应用,通过按用户维度来划分数据比较合适,因为用户与用户之间的隔离的,一般不存在处理多个用户数据的情况,简单的按user_id范围来水平切分
通俗理解:水平拆分行,行数据拆分到不同表中, 垂直拆分列,表数据拆分到不同表中
垂直与水平联合切分
由上面可知垂直切分能更清晰化模块划分,区分治理,水平切分能解决大数据量性能瓶颈问题,因此常常就会把两者结合使用,这在大型网站里是种常见的策略
案例:
以mysql为例,简单购物系统暂设涉及如下表:
1.产品表(数据量10w,稳定)
2.订单表(数据量200w,且有增长趋势)
3.用户表 (数据量100w,且有增长趋势)
以mysql为例讲述下水平拆分和垂直拆分,mysql能容忍的数量级在百万静态数据可以到千万
垂直拆分:
解决问题:
表与表之间的io竞争
不解决问题:
单表中数据量增长出现的压力
方案:
把产品表和用户表放到一个server上
订单表单独放到一个server上
水平拆分:
解决问题:
单表中数据量增长出现的压力
不解决问题:
表与表之间的io争夺
方案:
用户表通过性别拆分为男用户表和女用户表
订单表通过已完成和完成中拆分为已完成订单和未完成订单
产品表 未完成订单放一个server上
已完成订单表盒男用户表放一个server上
女用户表放一个server上(女的爱购物)
参考 : http://www.cnblogs.com/zr520/p/5449748.html
DELIMITER $$
CREATE
PROCEDURE domain_area_bandwidth()
BEGIN
DECLARE i INT;
DECLARE table_name VARCHAR(30);
DECLARE table_pre VARCHAR(24);
DECLARE sql_text VARCHAR(2000);
SET i = 0;
SET table_name = '';
SET table_pre = 'p_domain_area_bandwidth_';
SET sql_text = '';
WHILE i < 16 DO
SET table_name = CONCAT(table_pre,i);
SET sql_text=CONCAT('CREATE TABLE ', table_name, '(
`domain_id` BIGINT(20) COMMENT \'域名id\',
`country_code` INT(8) COMMENT \'国家\',
`province_code` INT(8) COMMENT \'省份\',
`isp_code` INT(8) COMMENT \'运营商\',
`bandwidth` BIGINT(20) COMMENT \'带宽\',
`time` TIMESTAMP,
INDEX `index_domainId_country_province_isp_time` (`domain_id`, `country_code`, `province_code`, `isp_code`, `time`)
) ENGINE=INNODB CHARSET=utf8 COLLATE=utf8_general_ci' );
SELECT sql_text;
SET @sql_text=sql_text;
PREPARE stmt FROM @sql_text;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
SET i=i+1;
END WHILE;
END$$
DELIMITER ;
CALL domain_area_bandwidth();
存储过程创建多张表 http://825635381.iteye.com/blog/2161290