MySQL 分库分表方案,总结的非常好!
前言 公司最近在搞服务分离,数据切分方面的东西,因为单张包裹表的数据量实在是太大,并且还在以每天60W的量增长。 之前了解过数据库的分库分表,读过几篇博文,但就只知道个模糊概念, 而且现在回想起来什么都是模模糊糊的。 今天看了一下午的数据库分库分表,看了很多文章,现在做个总结,“摘抄”下来。(但更期待后期的实操) 会从以下几个方面说起: 第一部分:实际网站发展过程中面临的问题。 第二部分:有哪几种切分方式,垂直和水平的区别和适用面。 第三部分:目前市面有的一些开源产品,技术,它们的优缺点是什么。 第四部分:可能是最重要的,为什么不建议水平分库分表!?这能让你能在规划前期谨慎的对待,规避掉切分造成的问题。 名词解释 库: database ;表: table ;分库分表: sharding 数据库架构演变 刚开始我们只用单机数据库就够了,随后面对越来越多的请求,我们将数据库的 写操作 和 读操作 进行分离, 使用多个从库副本( Slaver Replication )负责读,使用主库( Master )负责写, 从库从主库同步更新数据,保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展,所以更多的读请求不成问题。 但是当用户量级上来后,写请求越来越多,该怎么办?加一个Master是不能解决问题的, 因为数据要保存一致性,写操作需要2个master之间同步,相当于是重复了