数据库架构设计（一）

近日订阅了沈剑大牛的无限容量数据库架构设计，分为12讲，分别从总体介绍、单Key无限容量、一对多无限容量、多对多无限容量、多Key无限容量五个方面讲解，有思路也有落地，很受用，下面我简单总结一下。

首先，我们说一说架构的分类。

一、单库：

传统意义上的数据库架构设计，现有系统可以根据微服务拆分成不同的单库系统。

优点：设计简单，运维便利，快速响应业务

缺点：无法承受千万级数据量

二、分组：

读写分离，主从同步，一般可以设计为一主多从，主为写，从为读，作为集群式部署，其特点是主库和从库在一个集群中用binlog来保证数据一致性，同时主库和从库的schema一致。

优点：解决读性能瓶颈问题，保证读高可用

缺点：未能解决大数据量问题，读压力依然存在

三、分片

即水平切分sharding，一般通过继承Spring的AbstractRoutingDataSource或者数据库中间件（mycat、cobar、sharding-jdbc）等来实现，路由规则一般有范围法或hash法，其特点是各个分库schema相同，但数据不一致（这里主要推荐分库，因为库文件更易于迁移）。

优点：解决数据量过大，一般建议千万级别需要水平切分，主要指mysql

缺点：运维成本上升，路由规则需要自定义，查询分散数据需要重新设计

四、分组+分片

市面上大多数电商平台所应用，根据不同业务来进行不同的切分，后面会讲解各类业务的切分原则。主要是集合了分组加分片的设计思路。

优点：同时解决数据量大和读高可用的问题

缺点：运维难度大，要考虑数据分散度和主从之间的数据一致性

五、垂直切分

类似于用户表，因为列过多，而进行列维度的垂直切分，也叫纵向列切分。一般切分原则有属性长度和访问频度。其特点是schema和数据都不一致，但是主键一致。

优点：拆分后业务清晰，拆分规则明确。数据维护简单。降低单库数据量，减少行长度，使相同buffer可以命中

缺点：部分业务表无法join，只能通过接口方式解决，提高了系统复杂度，事务处理复杂