分表分库
一、常见面试题
1、为什么分表分库？
2、分表分库中间件有哪些？分别有什么特点？
3、垂直拆分还是水平拆分？有什么区别？
二、问题分析
1、由于用户数量增长，导致数据量越来越大，请求并发量也会增加，这样就会导致服务器压力增加，那么我们就要采取措施了。有时候分表不一定会分库，分库不一定会分表，具体情况要看并发情况和表数据量情况。
2、分表分库的中间件有：cobar 、TDDL、atlas、sharding-jdbc、mycat
cobar ——— 阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
TDDL ———- 淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
atlas ———- 360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
sharding-jdbc ———— 当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
mycat ————- 基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。
其实我一个都没有用过，还没遇到过太大的高并发量。
总结：一般情况建议使用mycat和sharding-jdbc。中小公司使用sharding-jdbc，大型公司使用mycat。
其一： sharding-jdbc不必部署，运维成本低，不需要代理层的二次转发请求，性能较高。
其二：mycat需要部署，运维成本高。
3、水平拆分：就是把一个表的数据给分到多个库的多个表中，但是每个表中的结构是一样的，只是存放的数据不同，所有库表的数据加起来就是全部数据了。
垂直拆分：就是把一个有很对字段的表拆分成多个表，或者多个数据库中，每个库表的结构是不同的，每个库表都只有部分字段。一般情况下将访问次数多的字段和访问次数少的字段分别存到到不同的表中。
淡淡的烟草味﹌
你的名字
我会带着你远行
野性酷女
还没有评论，来说两句吧...