数据库垂直拆分 水平拆分
当我们使用读写分离、缓存后，数据库的压力还是很大的时候，这就需要使用到数据库拆分了。
数据库拆分简单来说，就是指通过某种特定的条件，按照某个维度，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面以达到分散单库（主机）负载的效果。
切分模式： 垂直（纵向）拆分、水平拆分。
垂直拆分
专库专用
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指
按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面，如下图：
优点：
1. 拆分后业务清晰，拆分规则明确。
2. 系统之间整合或扩展容易。
3. 数据维护简单。
缺点：
1. 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
2. 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
3. 事务处理复杂。
水平拆分
垂直拆分后遇到单机瓶颈，可以使用水平拆分。相对于垂直拆分的区别是：垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一个表拆到不同的数据库中。
相对于垂直拆分，水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中 的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，主要有分表，分库两种模式，如图：
优点：
1. 不存在单库大数据，高并发的性能瓶颈。
2. 对应用透明，应用端改造较少。
3. 按照合理拆分规则拆分，join操作基本避免跨库。
4. 提高了系统的稳定性跟负载能力。
缺点：
1.
拆分规则难以抽象。
2. 分片
事务一致性难以解决。
3. 数据多次扩展难度跟维护量极大。
4. 跨库join性能较差。
拆分的处理难点
两张方式共同缺点
1. 引入分布式事务的问题。
2. 跨节点Join 的问题。
3. 跨节点合并排序分页问题。
针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个 数据库，在模块内完成数据的整合。
优点：相对简单，无性能损耗。
缺点：不够通用，数据库连接的处理复杂，对业务不够透明，处理复杂。
B. 通过
中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
优点：通用，对应用透明，改造少。
缺点：实现难度大，有二次转发性能损失。
拆分原则
1. 尽量不拆分，架构是进化而来，不是一蹴而就。(SOA)
2. 最大可能的找到最合适的切分维度。
3. 由于数据库中间件对数据Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取 尽量少使用多表Join -尽量通过数据冗余，分组避免数据垮库多表join。
4. 尽量避免分布式事务。
5. 单表拆分到数据1000万以内。
切分方案
范围、枚举、时间、取模、哈希、指定等
案例分析
场景一
建立一个历史his系统，将公司的一些历史个人游戏数据保存到这个his系统中，主要是写入，还有部分查询，读写比约为1:4；由于是所有数据的历史存取，所以并发要求比较高；
分析：
历史数据
写多都少
越近日期查询越频繁？
什么业务数据？用户游戏数据
有没有大规模分析查询？
数据量多大？
保留多久？
机器资源有多少？
方案1：按照日期每月一个分片
带来的问题：1.数据热点问题（压力不均匀）
方案2：按照用户取模， --by Jerome 就这个比较合适了
带来的问题：后续扩容困难
方案3：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
场景二
建立一个商城订单系统，保存用户订单信息。
分析：
电商系统
一号店或京东类？淘宝或天猫？
实时性要求高
存在瞬时压力
基本不存在大规模分析
数据规模？
机器资源有多少？
维度？商品？用户？商户？
方案1：按照用户取模，
带来的问题：后续扩容困难
方案2：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
方案3：按省份地区或者商户取模
数据分配不一定均匀
场景3
上海公积金，养老金，社保系统
分析：
社保系统
实时性要求不高
不存在瞬时压力
大规模分析？
数据规模大
数据重要不可丢失
偏于查询？
方案1：按照用户取模，
带来的问题：后续扩容困难
方案2：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
方案3：按省份区县地区枚举
数据分配不一定均匀
数据库问题解决后，应用面对的新挑战就是拆分应用等
参考
Mycat在线视频培训【链接：
http://pan.baidu.com/s/1nuR26rZ 密码：1gr9 （2015）】
大型网站系统与Java中间件实践.pdf
MySQL数据库的演化可以参考：http://mp.weixin.qq.com/s?__biz=MjM5ODI5Njc2MA==&mid=207666963&idx=2&sn=0d0710e071420c6fc6af8d4a3bc3dfe6&scene=1#rd
垂直拆分就是要把表按模块划分到不同
数据库表中（当然原则还是不破坏第三范式），这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候，只有小量的人来开发和维护，各模块和表都在一起，当网站不断丰富和壮大的时候，也会变成多个子系统来支撑，这时就有按模块和功能把表划分出来的需求。其实，相对于垂直切分更进一步的是服务化改造，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，通过服务间的调用来满足业务需求看，因此表拆出来后要通过服务的形式暴露出去，而不是直接调用不同模块的表，淘宝在架构不断演变过程，最重要的一环就是服务化改造，把用户、交易、店铺、宝贝这些核心的概念抽取成独立的服务，也非常有利于进行局部的优化和治理，保障核心模块的稳定性
垂直拆分：单表大数据量依然存在性能瓶颈
水平拆分
上面谈到垂直切分只是把表按模块划分到不同数据库，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如像计费系统，通过按时间来划分表就比较合适，因为系统都是处理某一时间段的数据。而像SaaS应用，通过按用户维度来划分数据比较合适，因为用户与用户之间的隔离的，一般不存在处理多个用户数据的情况，简单的按user_id范围来水平切分
通俗理解：水平拆分行，行数据拆分到不同表中， 垂直拆分列，表数据拆分到不同表中
垂直与水平联合切分
由上面可知垂直切分能更清晰化模块划分，区分治理，水平切分能解决大数据量性能瓶颈问题，因此常常就会把两者结合使用，这在大型网站里是种常见的策略
案例：
以mysql为例，简单购物系统暂设涉及如下表：
1.产品表（数据量10w，稳定）
2.订单表（数据量200w，且有增长趋势）
3.用户表 （数据量100w，且有增长趋势）
以mysql为例讲述下水平拆分和垂直拆分，mysql能容忍的数量级在百万静态数据可以到千万
垂直拆分：
解决问题：
表与表之间的io竞争
不解决问题：
单表中数据量增长出现的压力
方案：
把产品表和用户表放到一个
server上
订单表单独放到一个server上
水平拆分：
解决问题：
单表中数据量增长出现的压力
不解决问题：
表与表之间的io争夺
方案：
用户表通过性别拆分为男用户表和女用户表
订单表通过已完成和完成中拆分为已完成订单和未完成订单
产品表 未完成订单放一个server上
已完成订单表盒男用户表放一个server上
女用户表放一个server上(女的爱购物)
转载：https://www.cnblogs.com/firstdream/p/6728106.html
扫一扫
581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
