分布式方案
分库&拆表方案
基本认识
用分库&拆表是解决数据库容量问题的唯一途径。
分库&拆表也是解决性能压力的最优选择。
分库 – 不同的数据表放到不同的数据库服务器中(也可能是虚拟服务器) 拆表 – 一张数据表拆成多张数据表,可能位于同一台服务器,也可能位于多台服务器(含虚拟服务器)。
去关联化原则
摘除数据表之间的关联,是分库的基础工作。
摘除关联的目的是,当数据表分布到不同服务器时,查询请求容易分发和处理。 学会理解反范式数据结构设计,所谓反范式,第一要点是不用外键,不允许Join操作,不允许任何需要跨越两个表的查询请求。第二要点是适度冗余减少查询请求,比如说,信息表,fromuid, touid, message字段外,还需要一个fromuname字段记录用户名,这样查询者通过touid查询后,能够立即得到发信人的用户名,而无需进行另一个数据表的查询。
去关联化处理会带来额外的考虑,比如说,某一个数据表内容的修改,对另一个数据表的影响。这一点需要在程序或其他途径去考虑。
分库方案
安全性拆分
将高安全性数据与低安全性数据分库,这样的好处第一是便于维护,第二是高安全性数据的数据库参数配置可以以安全优先,而低安全性数据的参数配置以性能优先。参见运维优化相关部分。
顺序写数据与随机读写数据分库
顺序数据与随机数据区分存储地址,保证物理i/o优化。这个实话说,我只听说了概念,还没学会怎么实践。
基于业务逻辑拆分
根据数据表的内容构成,业务逻辑拆分,便于日常维护和前端调用。
基于业务逻辑拆分,可以减少前端应用请求发送到不同数据库服务器的频次,从而减少链接开销。
基于业务逻辑拆分,可保留部分数据关联,前端web工程师可在限度范围内执行关联查询。
基于负载压力拆分
基于负载压力对数据结构拆分,便于直接将负载分担给不同的服务器。 基于负载压力拆分,可能拆分后的数据库包含不同业务类型的数据表,日常维护会有一定的烦恼。
分表方案
数据量过大或者访问压力过大的数据表需要切分
忙闲分表
单数据表字段过多,可将频繁更新的整数数据与非频繁更新的字符串数据切分 范例 user表 ,个人简介,地址,QQ号,联系方式,头像 这些字段为字符