云原生常用技术:https://landscape.cncf.io/?fullscreen=yes
mysql性能问题的原因
- 数据库表设计不合理
- 表数据量过大
- sql查询太复杂
- sql查询字段没有加索引
- 数据库服务器性能过低
表数据过大的解决方案
怎么算表数据过大?
阿里开发手册:单表数据行数超过500W,或单表数据容量超过2G
数据库表拆分
分库分表:垂直分库分表、水平分库分表
冷热数据分离:根据数据访问频次分开存储,一般按照时间来划分冷热数据,比如微信朋友圈,电商网站订单信息,交易信息
数据库分库分表
水平拆分
水平分库:根据年进行数据分库
水平分表:根据编号或者月份对同一个表的数据进行分表存储
垂直拆分
垂直分库:电商库分为商品库,订单库,用户库,交易库
垂直分表:订单表,订单明细表
分库分表策略
取模算法
缺点:如果新添加一张表,需要对所有数据重新计算,进行数据迁移
一致性hash算法
如果新增表或删除表,可以缩小数据迁移的范围
范围分片
根据编号范围进行分表,比如0<id<100W,100W<id<200W...
区域分片
不同区域分片存储,比如最近的健康码数据分省份存储
全局唯一ID
- 创建全局唯一表,保存全局唯一ID
- 通过UUID生成ID:缺点是ID不连续,字符串类型,占用存储空间较大
- Redis的原生递增
- Twitter-Snowflake雪花算法:64位长度的Long类型的数字ID
分库分表中间件
客户端:Application集成分库分表组件
服务端:访问Mycat独立中间件去操作数据库,中间件实现了数据库的协议,类似于直接操作数据库
分库分表实践
实际分库分表考虑
1、功能:注册、登录、查询、修改等
2、使用范围
- 用户端
如果根据用户id查询用户信息占比大,则可根据用户id进行分片
- 运营端
可以使用搜索引擎-es
建立映射表,分片键与非分片键之间建立映射关系
分库分表可能的问题
- 数据迁移
- 模型改造
模型改造三阶段:
- 新老库双写(以老库为准)
定时任务来数据校对,补平差异
定时任务去迁移老库数据到新库
- 历史库已经导完,数据校验也没问题
保持双写,事务以新库为准
定时校验数据
- 新模型已稳定运行,取消双写,所有数据只需要保存到新的模型,老模型不需要再写数据
跨库查询
- 字段冗余:不同库有关联关系的数据字段
- 绑定表:有关联的表放在同一库中
- 业务系统层面组装
- 全局表
分页、排序
业务端做聚合,存储在nosql中
分库分表解决方案
- MyCat:服务端代理
- Sharding-Sphere(5.x):Sharding-JDBC --> 客户端, Sharding-Proxy --> 服务端