数据库架构设计(一)

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

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

一、单库:

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

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

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

二、分组:

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

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

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

三、分片

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

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

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

四、分组+分片

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

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

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

五、垂直切分

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

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

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180419G0DOP200?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券