前言
数据分片 。。。 降低单个数据库节点压力、和处理大量数据的方案
其中 拆分方案 分为 单独的垂直分片、水平分片 和垂直、水平混合分片
数据分片之后 + 读写分离 基本上解决大多数数据的容量、性能问题 对于现在的项目基本上都是可以支撑起来
最近在看sharding share 的jdbc组件 也能很快速的实现 数据分片
垂直分片(单独分库)
- 优点: 缓解一定情况下的数据量和单个数据库节点的压力
- 缺点: 没有解决单表数据量大的问题 、无法跨库连表查询
垂直分片 可以说是解决同库多张表的数据量过大的优化 最简单快速的方案
因为大多数情况下 只需要多个数据源定好访问规则就行 不涉及分表
但是有上限 例如单表数据超过极限 例如mysql 百万级别数据 postgres 千万级别数据 这个时候 sql执行就会相对来说比较慢
shardingJDBC 垂直分片示例
分片方案:
staff表 -> ds0
api_consuming_log -> ds1
其他表 分配到ds0 上
为了加深印象 采用java配置模式
1 | package com.ming.base.config; |
水平分片(分库+分表)
- 优点: 解决单表数据量问题 提升部分功能性能
- 缺点: 增加多个数据库 需要冗余副本 耗费资源、实际存储表较为分散 、事务难以控制
制定好分片规则 理论上可以大规模扩展
shardingJDBC 水平分片示例
分片方案:
staff 均匀分布在ds0 ds1 中的 staff0 staff1 库
api_consuming_log 分布在ds0 的api_consuming_log0 ds1的api_consuming_log1,api_consuming_log2,api_consuming_log3
其他表 分配到ds0 上
1 | package com.ming.base.config; |
数据分片+读写分离
增加一个 masterSlave 配置即可
1 | package com.ming.base.config; |
总结
一般项目 遇到db的瓶颈
优化的方向肯定是 数据分区 —> 读写分离 —> 分库 —> 分库分表
一般来说 初期做个数据分区够用 不够了 就做读写分离 当数据量达到一定的程度 再去采用分库分表
因为使用分库分表涉及到很多复杂的问题 没有必要的话 还是不要轻易的使用
shardingJDBC 除了不解决db本身的数据分区 其他的 读写分离、分库分表 都有比较良好的支持
最主要的是 通过jdbc来支持的 不嵌入业务代码 也不需要部署中间件 只需要部署db即可
非常的舒服