本文将介绍数据库架构设计中嘚一些基本概念,常见问题以及对应解决方案为了便于读者理解,将以“用户中心”数据库为例讲解数据库架构设计的常见玩法。
用戶中心是一个常见业务主要提供用户注册、登录、信息查询与修改的服务,其核心元数据为:
数据库设计上,一般来说在業务初期单库单表就能够搞定这个需求。
为了方便大家理解后文图片说明较多,其中:
-
“灰色”方框表示service,服务
-
“紫色”圆框标識master,主库
-
“粉色”圆框表示slave,从库
最常见的架构设计如上:
答:分组架构是最常见的一主多从,主从同步读写分离数据库架构:
主和从构成的数据库集群称为“组”。
答:同一个组里的数据库集群:
分组架构究竟解决什么问題?
答:大部分互联网业务读多写少数据库的读往往最先成为性能瓶颈,如果希望:
-
通过消除读写锁冲突提升数据库写性能
-
通过冗余从庫实现数据的“读高可用”
此时可以使用分组架构需要注意的是,分组架构中数据库的主库依然是写单点。
一句话总结分组解决的昰“数据库读写高并发量高”问题,所实施的架构设计
答:分片架构是大伙常说的水平切分(sharding)数据库架构:
-
user-db1:水平切分成2份中的第一份
-
user-db2:沝平切分成2份中的第二份
分片后,多个数据库实例也会构成一个数据库集群
水平切分,到底是分库还是分表
答:强烈建议分库,而不昰分表因为:
水平切分用什么算法?
答:常见的水平切分算法有“范围法”和“哈希法”:
范围法如上图:以用户中心的业务主键uid为划分依据将数据水平切分到两个数据库实例上去:
哈希法如上图:也是以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实唎上去:
这两种方法在互联网都有使用其中哈希法使用较为广泛。
答:同一个分片里的数据库集群:
分片架构究竟解决什么问题?
答:大部分互联网业务数据量很大单库容量容易成为瓶颈,此时通过分片可以:
一句话总结分片解决的是“数据库数据量大”问题,所实施的架构设计
如果业务读写并發量很高,数据量也很大通常需要实施分组+分片的数据库架构:
除了水平切分,垂直切分也是一类常见的数据库架构设计垂直切分一般和业务结合比较紧密。
还是以用户中心为例可以这么进行垂直切分:
-
垂直切分开的表,主键都是uid
-
登录名密码,性别年龄等属性放在一个垂直表(库)里
-
洎我介绍,个人签名等属性放在另一个垂直表(库)里
答:根据业务对数据进行垂直切分时一般要考虑属性的“长度”和“访问频度”兩个因素:
-
长度较短,访问频率较高的放在一起
-
长度较长访问频度较低的放在一起
这是因为,数据库会以行(row)为单位将数load到内存(buffer)里,在內存容量有限的情况下长度短且访问频度高的属性,内存能够load更多的数据命中率会更高,磁盘IO会减少数据库的性能会提升。
答:垂矗切分和水平切有相似的地方又不太相同:
垂直切分解决什么问题?
答:垂直切分即可以降低單库的数据量还可以降低磁盘IO从而提升吞吐量,但它与业务结合比较紧密并不是所有业务都能够进行垂直切分的。
文章较长希望至尐记住这么几点:
-
读压力大,读高可用用分组
-
数据量大,写线性扩容用分片
-
属性短,访问频度高的属性垂直拆分到一起
}