架构之美—数据库架构

本文来自朋友圈

数据库架构通常从简单到复杂的过程

一、一主一从
由一台主库和一台从库组成，从库只用做备份和容灾，当主库出现故障时，从库就手动变成主库
随着压力的增长，加上了memcached

二、一主多从
经过添加多个从库来分流查询压力

三、随着数据量的增长，读写压力都迅速增长，

进行数据库拆分，将数据存放到不一样的数据库服务器中

数据库拆分
通常能够按两个纬度来拆分数据:
（1）垂直拆分
按功能模块拆分，多个数据库之间的表结构不一样
（2）水平拆分
将同一个表的数据进行分块保存到不一样的数据库中，数据库中的表结构相同

拆分规则
常见的拆分方式是对表中某列值的范围或者hash值拆分，好比ID在0-10000之间的用户对应到数据库A，ID在10000-20000这个范围的对应到数据库B
这种方法实现起来比较方便高效，可是不能知足后续的伸缩性要求，若是须要增长数据库节点，必需调整算法或移动很大的数据集，比较难作到在不中止服务的前提下进行扩充数据库节点

采用的拆分方法有：映射表
这种方法是指创建一个索引表，保存每一个用户ID和数据库ID的对应关系，每次读写用户数据时先从这个表获取对应数据库，新用户注册后，在全部可用的数据库中随机挑选一个为其创建索引
把索引表进行缓存，提升检索性能

数据迁移
若是须要平衡各个节点的压力，须要进行数据的迁移
例如要迁移用户A的数据
（1）将A状态置为迁移数据中，这个状态的用户不能进行写操做，并在页面上进行提示
（2）而后将用户A的数据所有复制到新增长的节点上
（3）更新映射表
（4）将用户A的状态置为正常
（5）将原数据库上的数据删除

数据访问过程

 

拆分带来的问题（1）跨库关联查询若是须要查询的数据分布于不一样的数据库，不便于经过JOIN的方式查询得到好比要得到好友的最新照片，不能保证全部好友的数据都在同一个数据库里，须要经过屡次查询，再进行聚合有些需求能够经过保存多份数据来解决，例如用户A、用户B的数据库分别是DB一、DB2，当A评论了B做品时先在B所在DB2中photo_comments表插入记录，记录B的哪一个做品被谁评论了什么内容而后在A所在DB1中user_comments表插入记录，记录A给哪一个做者的哪一个做品发表过评论这样能够经过photo_comments获得B的某张照片的全部评论，也能够经过user_comments得到A发布过的全部评论（2）不能保证数据的一致/完整性跨库的数据没有外键约束，也没有事务保证，好比上面评论照片的例子，极可能出现成功插入photo_comments表，可是插入user_comments表时却出错了能够在两个库上都开启事务，而后先插入photo_comments，再插入user_comments，而后提交两个事务，但不能彻底保证这个操做的原子性（3）自增ID增长了一个专门用来生成ID的数据库，表结构很简单，只有一个自增字段id例如要插入评论时，先在ID库的photo_comments表里插入一条空的记录，以得到一个惟一的评论ID按期清理ID库的数据，以保证获取新ID的效率