近日订阅了沈剑大牛的无限容量数据库架构设计,分为12讲,分别从总体介绍、单Key无限容量、一对多无限容量、多对多无限容量、多Key无限容量五个方面讲解,有思路也有落地,很受用,下面我简单总结一下。
首先,我们说一说架构的分类。
一、单库:
传统意义上的数据库架构设计,现有系统可以根据微服务拆分成不同的单库系统。
优点:设计简单,运维便利,快速响应业务
缺点:无法承受千万级数据量
二、分组:
读写分离,主从同步,一般可以设计为一主多从,主为写,从为读,作为集群式部署,其特点是主库和从库在一个集群中用binlog来保证数据一致性,同时主库和从库的schema一致。
优点:解决读性能瓶颈问题,保证读高可用
缺点:未能解决大数据量问题,读压力依然存在
三、分片
即水平切分sharding,一般通过继承Spring的AbstractRoutingDataSource或者数据库中间件(mycat、cobar、sharding-jdbc)等来实现,路由规则一般有范围法或hash法,其特点是各个分库schema相同,但数据不一致(这里主要推荐分库,因为库文件更易于迁移)。
优点:解决数据量过大,一般建议千万级别需要水平切分,主要指mysql
缺点:运维成本上升,路由规则需要自定义,查询分散数据需要重新设计
四、分组+分片
市面上大多数电商平台所应用,根据不同业务来进行不同的切分,后面会讲解各类业务的切分原则。主要是集合了分组加分片的设计思路。
优点:同时解决数据量大和读高可用的问题
缺点:运维难度大,要考虑数据分散度和主从之间的数据一致性
五、垂直切分
类似于用户表,因为列过多,而进行列维度的垂直切分,也叫纵向列切分。一般切分原则有属性长度和访问频度。其特点是schema和数据都不一致,但是主键一致。
优点:拆分后业务清晰,拆分规则明确。数据维护简单。降低单库数据量,减少行长度,使相同buffer可以命中
缺点:部分业务表无法join,只能通过接口方式解决,提高了系统复杂度,事务处理复杂
领取专属 10元无门槛券
私享最新 技术干货