MySql数据库读多写少和读多写多

MySql数据库读多写少和读多写多

• 多都写少的业务场景
  普遍来说，绝大多数系统都是读多写少的

• 写多读少的业务场景

比如滴滴打车，就是写多读行的业务场景，当行程开始之后，滴滴app就会将行车记录
数据实时写入到数据库，这样做是为了乘客的安全考虑，但是这些数据很少被查询，只有
在出现事故的时候，才会查询

写多读少的解决方案1 - 低价值数据

• 如果是低价值的数据，可以采用NoSQL数据库来存储这些数据
  什么是低价值的数据呢？
  
  比如：专车的线路坐标，虽然数据很多，但是每条记录的价值并不是很大，如果用mysql
  这样的关系型数据库来存储，那么事务上的开销就让我们无法承受，因为在事务机制下
  ，写入数据之前都要先写 undo日志,然后写redo日志，都没有问题了，等到事务提交的时候
  在把redo日志里面的数据同步的数据文件里面，那么在读多写少的业务场景里，虽然说事务
  机制下的写入速度并不快，但是写入的业务量不大，所有看不出什么问题，但是在写多读少
  的业务场景里，每一秒中都要写入大量的数据，那么事务机制就会拖累写入的速度，因此传统的
  关系型数据库就不太适合了，最好的解决办法就是使用NoSQL数据库

• NoSQL抛弃了复杂的表结构和约束，有的NoSQL数据库也抛弃了事务机制，数据的写入速度很快

写多读少的解决方案2 - 高价值数据

• 如果是高价值的数据，可以用MySql的TokuDB引擎来保存

因为NoSQL数据库抛弃了事务机制，所以不能存储高价值的数据。

MySQL的TokuDB可以带着事务高速写入

• MySQL的TokuDB的写入速度是InnoDB的9-20倍，数据的压缩比大约是InnoDB的15倍
  TokuDB适合写入多，查询少的业务场景，也就是存入冷数据占优势

写多读多的业务场景

这种场景一般不多见，比如qq和微信都有离线留言的功能，即便对方没有上线，我们发出去的
消息，会被临时存储在服务器上，等到对方上线之后，就能收到这些离校的消息了，这部分的
场景就是 读多写多的，常规的数据库时没有办法应对这样的场景的，所有这时候只能求助NoSql
数据库了，包括微信朋友圈，也是读多写多的场景，朋友圈的数据也是存储在noSql数据库中

数据库集群方案的缺点

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

比如：使用MyCat管理MySql集群，MyCat要生成全局主键，然后还有去判断当前商品是什么类型

数据库集群方案的优点

• 数据库集群能支持更大规模的并发访问，并且存放更多的数据
  比如：单节点的mysql难以支持500个并发连接，但是用了数据库集群，这个并发的数量就会翻倍，那么
  单节点的数据库在高并发的情况下它的实际性能很差，一万的并发及不行了。
  
  InnoDB单表数据如果超过2千万，这个表的读写速度就会明显的下降，因此我们可以把数据切分存储
  到不同的mysql数据节点上，这样每个节点单表数据量就减少了

支持我-微信扫一扫-加入微信公众号

赞赏作者