共计 688 个字符,预计需要花费 2 分钟才能阅读完成。
前言
公司最近在搞服务拆分的内容,由于服务拆分必然会带来数据库的拆分,
同时公司业务单表数据最高已经达到了亿级,于是乎考虑分库分表来对库进行拆分
所以将分库分表提上日程必然是势在必行
特此记录一下对分库分表的研究历程
何谓
分库分表,字面意思就给人一种手艺活的感觉
既然是一门手艺活,那么当然得先从姿势讲起(手动❀鸡)
垂直
- 垂直分表:大表拆分成小表,由于大表有很多字段,但是有部分简单查询时这些字段并不常用,因此可以拆分成基础信息表和详细信息表。
- 垂直分库:大库拆分成小库,一般是按照服务来进行拆分,比如订单库,用户库。
水平
- 水平分表:将表的行数据进行拆分,比如主键为偶数的表放到 order_1 表,主键为奇数的数据放到 order_2 表
- 水平分库:和水平分表逻辑类似,将数据按照一定规则在不同的库上进行分配
何时需要
数据库在一个公司的架构中,作为最底层的基础建设,对各种上层应用提供数据服务支撑,很容易在整个架构的性能上形成一定瓶颈,常见现象有如下几种:
- 数据库连接过多
- 查询经过索引等优化后无法满足日常查询
- 读写分离已经无法满足
注意点
- 分库后如何处理事务
- 多数据源管理
- 跨库 join 操作
如何落实
- ShardingSphere
- MyCat
总结
- 分库分表之前要慎重,因为涉及到数据的变更,可能业务代码上还需要作改动
- 分库分表的优先级一般位于所有优化方案之后,在索引或读写分离等优化方案无法满足后,如果这些方式不能根本解决问题,才进行分库分表
- 数据库设计之初就考虑分库分表,但是不推荐直接分库分表,大多数的产品还是以满足功能和使用为为前提,提前分库分表无疑会增加开发成本
本文由博客群发一文多发等运营工具平台 OpenWrite 发布
正文完