目录

  • 读多写少的业务场景
  • 读多写少的解决方案
  • 写多读少的业务场景
  • 写多读少的解决方案
  • 读多写多的业务场景
  • 写多读少的解决方案
  • 数据库集群方案缺点
  • 数据库集群方案优点
  • 总结



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

读多写少的业务场景

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

读多写少的解决方案

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

写多读少的业务场景

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

写多读少的解决方案

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

读多写多的业务场景

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

写多读少的解决方案

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

数据库集群方案缺点

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

数据库集群方案优点

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

总结

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