数据库优化专题---4、读多写少和读多写多

数据库优化专题—1、表的主键用数字还是UUID
数据库优化专题—2、逻辑删除还是物理删除
数据库优化专题—3、千万记录如何快速分页
数据库优化专题—4、读多写少和读多写多
数据库优化专题—5、删改数据如何避免锁表
数据库优化专题—6、如何避免偷换交易中的商品信息
数据库优化专题—7、SQL语句优化
数据库优化专题—8、Mysql参数优化
数据库优化专题—9、索引优化
数据库优化专题—10、存储优化
数据库优化专题—11、数据库结构优化

应用系统操作数据集分为读多写少和读多写多两种，业务场景分别是什么，如何优化？这节我们介绍下。

读多写少的业务场景

• 普遍来说，绝大多数系统都是读多写少；
  

读多写少的解决方案

• 可以采用Redis存储部分高并发读请求数据，减轻数据库压力；
• 搭建数据库集群，独立读库与写库，读写请求分离；
  

写多读少的业务场景

• 打车、导航等业务场景为读多写少；
  

写多读少的解决方案

• 如果低价值的数据，可以采用NoSql数据库来存储这些数据。NoSql没有抛弃了复杂的表结构和约束，数据的写入速度很快；
• 如果是高价值的数据，可以用TokuDB来保存。TokuDB的写入速度是InnoDB的9~20倍；
  

读多写多的业务场景

• IM系统、消息系统等为读多写多业务；
  

写多读少的解决方案

• 搭建数据库集群解决，目前可基于MyCat实现集群方案；

数据库集群方案缺点

• 数据库集群的读写速度低于单节点数据库实例；
  

数据库集群方案优点

• 数据库集群能支持更大规模的并发访问，并且存放更多的数据；

总结

读多写少和读少写多可基于Nosql优化；读多写多可基于数据库集群优化。