美文网首页
数据库分库分表

数据库分库分表

作者: 喧嚣城外 | 来源:发表于2019-03-19 22:03 被阅读0次
为什么分库分表?(设计高并发系统时候,数据库层面该如何设计?)

分库和分表是两回事,大家别搞混了,可能是光分库不分表,也可能是光分表不分库,都有可能。

分表:

就是把一个表的数据放到多个表中,然后查询的时候你就查一个表。比如按照用户id来分表,将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内,比如每个表就固定在200万以内。

分库:

就是你一个库一般我们经验而言,最多支撑到并发2000,一定要扩容了,而且一个健康的单库并发值你最好保持在每秒1000左右,不要太大。那么你可以将一个库的数据拆分到多个库中,访问的时候就访问一个库好了。


分库分表中间件,不同的分库分表中间件有什么优点和缺点?
常见的中间件:cobar、TDDL、atlas,sharding-jdbc、mycat
  • cobar:阿里b2b团队开发和开源的,属于proxy层方案。早些年还可以用,但是最近几年都没更新了,基本没啥人用,差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库join和分页等操作。
  • TDDL:淘宝团队开发的,属于client层方案。不支持join、多表查询等语法,就是基本的crud语法是ok,但是支持读写分离。目前使用的也不多,因为还依赖淘宝的diamond配置管理系统。
  • atlas:360开源的,属于proxy层方案,以前是有一些公司在用的,但是确实有一个很大的问题就是社区最新的维护都在5年前了。所以,现在用的公司基本也很少了。
  • sharding-jdbc:当当开源的,属于client层方案。确实之前用的还比较多一些,因为SQL语法支持也比较多,没有太多限制,而且目前推出到了2.0版本,支持分库分表、读写分离、分布式id生成、柔性事务(最大努力送达型事务、TCC事务)。而且确实之前使用的公司会比较多一些(这个在官网有登记使用的公司,可以看到从2017年一直到现在,是不少公司在用的),目前社区也还一直在开发和维护,还算是比较活跃,个人认为算是一个现在也可以选择的方案。
  • mycat:基于cobar改造的,属于proxy层方案,支持的功能非常完善,而且目前应该是非常火的而且不断流行的数据库中间件,社区很活跃,也有一些公司开始在用了。但是确实相比于sharding jdbc来说,年轻一些,经历的锤炼少一些。

sharding-jdbc这种client层方案的优点在于不用部署,运维成本低,不需要代理层的二次转发请求,性能很高,但是如果遇到升级啥的需要各个系统都重新升级版本再发布,各个系统都需要耦合sharding-jdbc的依赖。
mycat这种proxy层方案的缺点在于需要部署,自己及运维一套中间件,运维成本高,但是好处在于对于各个项目是透明的,如果遇到升级之类的在中间件那里搞就好。


如何对数据库垂直拆分或水平拆分的

水平拆分:把一个表的数据给弄到多个库的多个表中,但是每个库的表结构都一样,只不过每个库表放的数据是不同的,所有库表的数据加起来就是全部数据,水平拆分的意义,就是将数据均匀放到更多库中,然后用多个库来抗高并发,还有就是用多个库的存储容量来进行扩容。
垂直拆分:就是把一个很多字段的表拆分成多个表,或多个库中,每个库的结构都不一样,每个库表都包含部分字段,一般来说,将较少的访问频率很高字段放在一个表,然后将较多的访问频率很低的字段放到另外一个表中,因为数据库是有缓存的,你访问频率高的行字段越少,就可以在缓存里缓存更多行,性能就越好,这个一般在表层面做的较多。

两种分表分库方式(range&hash)
  • range:
    每个库一段连续的数据,这个一般都是按比如时间范围来的,但是这种一般较少用,很容易产生热点问题,大量的流量打在最新的数据上。
    好处在于,后面扩展时,很容易,因为你只要预备好,给每个月都准备一个库,到了一个新的月份,自然就写新的库。
    缺点在于,大部分请求都是访问新的数据,实际生产使用range,要看场景,用户不仅仅访问最新的数据,而是均匀的访问现在的数据以及历史数据。
  • hash:
    按照某个字段hash一下均匀分散
    好处在于,可以平均分配每个库的数据量和请求压力。
    坏处在于,扩容起来比较麻烦,会有一个数据迁移的过程。
01_分库分表的由来.png 02_数据库如何拆分.png

相关文章

网友评论

      本文标题:数据库分库分表

      本文链接:https://www.haomeiwen.com/subject/btjomqtx.html