本文将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以“用户中心”为例,讲解数据库架构设计的常见玩法。
01
用户中心
用户中心是一个非常常见的业务,主要提供用户注册、登录、信息查询与修改的服务,其核心元数据为:
User(uid, uname, passwd, sex, age, nickname, …)
其中:
数据库设计上,一般来说在业务初期,单库单表就能够搞定这个需求。
为了方便大家理解,后文图片说明如下:
02
单库架构
最常见的架构设计如上:
03
分组架构
1. 分组架构究竟解决什么问题?
答:大部分互联网业务读多写少,数据库的读往往最先成为性能瓶颈,如果希望:
此时可以使用分组架构,需要注意的是,分组架构中,数据库的主库依然是写单点。
04
分片架构
1. 分片架构究竟解决什么问题?
答:大部分互联网业务数据量很大,单库容量容易成为瓶颈,此时通过分片可以:
一句话总结,分片解决的是“数据库数据量大”问题,所实施的架构设计。
05
分组+分片架构
如果业务读写并发量很高,数据量也很大,通常需要实施分组+分片的数据库架构:
06
垂直切分
除了水平切分,垂直切分也是一类常见的数据库架构设计,垂直切分一般和业务结合比较紧密。
还是以用户中心为例,可以这么进行垂直切分:
User(uid, uname, passwd, sex, age, …)
User_EX(uid, intro, sign, …)
1. 如何进行垂直切分?
答:根据业务对数据进行垂直切分时,一般要考虑属性的“长度”和“访问频度”两个因素:
这是因为,数据库会以行(row)为单位,将数load到内存(buffer)里,在内存容量有限的情况下,长度短且访问频度高的属性,内存能够load更多的数据,命中率会更高,磁盘IO会减少,数据库的性能会提升。
06
业务场景决定数据库架构
本文以“用户中心”为例,对常见数据库架构设计进行了简要梳理与总结,但实际数据库架构设计远比此复杂,特别是水平切分的架构设计,不同业务场景的切分方式不尽相同。
感兴趣的可以订阅我的专栏,后续将要详细介绍,覆盖90%互联网业务特性的四类业务:
从《“1对多”类业务》这篇文章,能够了解到:
从《“多对多”类业务》这篇文章,能够了解到:
从《“多KEY”类业务》这篇文章,能够了解到: