数据库系列（二）数据库瓶颈

数据库瓶颈，数据量的增加，并发的增加：

　　1、加强硬件，换商业化软件====》花钱解决

　　2、架构设计上来解决，让数据库最少的做事，放弃触发器、外键、存储过程、函数

数据库复杂均衡

 

 

 多要数据库完成一台的事，数据库要保证一致性的

负载均衡：

　　利用多台服务器的读写能力，但是数据同步和访问分配交给第三方软件

Moebius：

　　读的压力分配到不同的服务器，写其实是多态服务器都得完成，对外只有一个IP，使用者是不知道细节的。

读写分离

　　二八原则：数据库中80%操作都是读，只有20%是写。

　　实现原理：就是把读和写的压力分开，降低IO压力；一主多从，主库写从库读；数据同步的问题，从主库到从库（肯定是有延迟的，网速没问题，两三秒吧）

　　1、数据库里面列别的数据库？link到主要+定时的job，是不是就可以了？【效率低】

　　2、日志传送，SQLserver2005，备份----复制----复制，这种方式简单，但是有局限性（局域网，只能文件夹共享）

 

 

 　　3、镜像，snapshot：内存拍照；主库，对外提供服务；从库，通过快照回复，数据跟主课一直；监控转移，负责检查状况，有问题切到从库

　　4、数据复制（发布/订阅）

 

 

 　　主库---发布到服务器---从库；延迟小，配置方便，但是需要程序配合。发布订阅后，从数据库是可以水平卓展的，查询就不是大问题。业务量进一步增加，写库还是抗不住===》分库/分区/分表

分库/分表/分区（最考验设计和开发）

　　多台服务器

　　分库：

　　　　1、系统里面有订单/物流/仓储/论坛/博客/客服

　　　　　　垂直分库，按照业务拆分库，不同的库不同的服务器

　　　　2、订单增删改查特别大

　　　　　　水平分库，每个库结构一致，数据不一致（地域/时间/类别/随机算法）

　　分表　　

　　　　垂直分表：

　　　　　　1、文章表，10个常规字段，还有一个很长很长的内容字段

　　　　　　　　垂直分表，直接减小表的体积，提升增删改查的效率

　　　　　　2、单表数据量太大（订单表/商品表）

　　　　　　　　水平分表（地域/时间/类别/随机算法）

　　分完之后，数据的查询怎么办呢？

　　　　拆分的时候要根据产品特点来

　　　　　　房产-----按照城市拆分

　　　　　　订单/流水-----按时间拆分

　　　　　　追求平均----随机算法

　　　　　　抛砖引玉，自己要根据业务特点来拆分，考虑业务，拆分的维度，最好不要再被聚合查询，但是又无法完全避免业务操作。

　　　　1、跨库垮表join---很不推荐

　　　　2、汇总表，定时任务定时作业====》专门应该特殊要求

　　　　3、特殊要求，就是为难你，同步一个报表库（总库），专门满足需求，性能肯定低

　　　　4、向业务妥协

　　表分区：就是水平分表的意思，也可以垂直分（用的少）