分库分表方法合集

末蓝、 2022-07-16 13:19 164阅读 0赞

[http://www.myexception.cn/database/1770219.html][http_www.myexception.cn_database_1770219.html]

对分库分表的一些想法

经历过几家公司从小到大的成长，数据量也会跟着业务量和访问量剧增。最初的系统架构完全无法支持大数据的到来，期间做过多次架构升级，包括数据库主从读写分离，系统soa化等等。那么就针对系统最重要的一块 数据来说吧。

说到数据大家都会想到数据存储和读取，还会联想到关系型数据库和非关系型数据库，当然随着互联网的发展，非关系性数据库越来越火，但是不能说明非关系型数据库完全能取代关系型数据库，至少目前不行。那么，关系型数据库的性能，是让人头疼的一个问题。目前最主流的方案是分库分表。

先说分表吧，可以分为纵向拆分和横向拆分，纵向拆分就是根据时间或者业务分表，或者拆分表结构，这些都需要改变表结构。但是数据量暴增，纵向分表最终还是无法解决问题，最终还是要考虑到横向拆分。

横向拆分也可以说是水平拆分，就是按照一定规则进行分表，不改变表结构。那么水平拆分的依据也是需要斟酌的。要保证数据能基本平均分配到不同的分表中，那么分表的依据就是重复性不能太高。那么首先考虑的就是主键。根据主键按照一定的策略进行分表。我想到的的有按区间分表，取模分表。

先说按区间分表，按区间分表有局限性，就是主键一定要保证是一个有序的数字，而且是不执行或很少执行delete的。但是好处是能保证表的数据量，也好维护。分表后的数据如下表：

取模分表，很简单就是对某个数值取余，然后分配到不同的表里。比如对4取余。那么数据分布如下：

取模分表没有对数据有苛刻要求，但是需要提前确定好取模因子（被取余数 也可以看做分表的数量）

看似取模分表比较合适，但是如果分表后数据量增长，当前分表已经无法支撑的时候怎么办呢，增加表，再取模？ 那么同步数据将会是很头疼的事情。因为每张表都要再从新分配数据。那么我们能不能借鉴一致性hash来进行分库分表呢？

一致性hash也可以看做是按区间分表，在0-2^32之间创建几个节点，节点可以看做是表，同时增加虚拟节点（对0-2^32分成多个区间段，然后多个区间段分别指定到几个表中）来保证各表的数据基本均衡，如果出现数据分配不均衡，就增加节点来分流数据命中大的节点。这样增加表的时候只同步数据量最大的那张表即可。但是0-2^32是一个很大的范围，怎么分区保证数据平均将是很复杂的事情。如果分段比较粗粒度那么不能保证数据的均衡，细粒度的话则需要维护一个范围段的数据，增加运算和维护成本。粒度越细运算和维护成本越高。那么有没有更好的方案呢？

能不能用二叉树的结构来进行分表呢？统一对2取模，left节点库存放可整除的数据，right存放不可被2整除的数据。如果某个节点压力较大则对该节点继续二叉，同时对分库指标加固定前缀或后缀，再hash对2取模。这样的话就可以避免添加表的时候全部数据要从新分配，也节省了维护成本（只维护一个二叉树即可）。

比如：分表字段为一个uuid，值为b9a6fd18-8734-45c4-ad81-57a98ada8304,hashcode = 2039422118（可以被2整除）, 那么该数据存放在left节点， 如果left节点不是最终节点（再分表），则uuid+后缀 如：b9a6fd18-8734-45c4-ad81-57a98ada8304\_EXT , 则该值的hashcode为 -1376741656（可以被2整除），则该数据存放再二级二叉树的left节点。

节点内容存放表名称，如果该节点有子节点，则按照规则加前缀或后缀，再hash，按照取模原则找下一节点，直到节点没有子节点的时候，获取表名称。

先分析添加表，比如某个节点表压力较大需要分表，则分流这个节点即可，最糟糕的情况是多个节点同时分表，那么逐个分表即可，各个节点互不影响。这样比取模分表扩容的时候要方便的多。

从维护的角度看，根据二叉树的原理分表，可以避免数据迁移的麻烦，同时系统只要维护一个二叉树即可，也节省了维护成本。

以上只是个人的一些想法，难免有一些不合理或者错误的地方，请大家指出批评并一块讨论改进。

飞信的分库方式：

[http://mt.sohu.com/20160513/n449139101.shtml][http_mt.sohu.com_20160513_n449139101.shtml]

![20180225194110565][]

逻辑POOL与物理POOL的优点，能有序地扩张用户;数据迁移的时候，不需要修改用户数据;只需要修改物理;Pool与逻辑Pool的映射即可。能够把逻辑和存储很好地融合起来，比如用来做分省控制用户，减少省间用户跨物理库调用。

第一阶段：通过组件直接读写数据，用户越来越多，物理POOL越来越多;服务越来越多，服务的镜像越来越多，连接数越来越多，数据库不可承受;服务越来越多，都能直接访问数据库将导致权限，引起的安全问题。

第二阶段：通过IBS服务读写数据，服务越来越多，IBS服务几乎和所有服务强耦合。

第三阶段：通过组件+DAL服务读写数据，DAL一旦出现问题，所有业务受影响，DAL间接增加了服务间的耦合。

第四阶段：SOA服务分层治理。

### 基于一致性树分布的数据分布式存储方法 ###

[http://www.cnki.net/KCMS/detail/detail.aspx?QueryID=0&CurRec=10&recid=&filename=JSJY201312029&dbname=CJFDHIS2&dbcode=CJFQ&pr=&urlid=&yx=&v=MTA5MzFOclk5SGJZUjhlWDFMdXhZUzdEaDFUM3FUcldNMUZyQ1VSTHllWnVkbUZpbm5Xci9KTHo3QmQ3RzRIOUw=][http_www.cnki.net_KCMS_detail_detail.aspx_QueryID_0_CurRec_10_recid_filename_JSJY201312029_dbname_CJFDHIS2_dbcode_CJFQ_pr_urlid_yx_v_MTA5MzFOclk5SGJZUjhlWDFMdXhZUzdEaDFUM3FUcldNMUZyQ1VSTHllWnVkbUZpbm5Xci9KTHo3QmQ3RzRIOUw]

唯品会分库分表说明

[https://my.oschina.net/stephenzhang/blog/650225][https_my.oschina.net_stephenzhang_blog_650225]

唯品会分库总结

[http://www.infoq.com/cn/articles/summary-and-key-steps-of-vip-orders-depots-table][http_www.infoq.com_cn_articles_summary-and-key-steps-of-vip-orders-depots-table]

[利用一致性哈希水平拆分MySql单表][MySql]

[http://blog.csdn.net/xiaobluesky/article/details/50429428][MySql]

[数据库分库分表(sharding)系列(五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案][sharding_ _Sharding]

[http://blog.csdn.net/bluishglc/article/details/7970268][sharding_ _Sharding]

### 蘑菇街交易平台 数据库架构演进历程(总结的非常好的文档) ###

[http://sanwen8.cn/p/3334qPr.html][http_sanwen8.cn_p_3334qPr.html]

### 对话：一个工程师在蘑菇街4年的架构感悟 ###

[http://sanwen8.cn/p/175N8hr.html][http_sanwen8.cn_p_175N8hr.html]

[http_www.myexception.cn_database_1770219.html]: http://www.myexception.cn/database/1770219.html
[http_mt.sohu.com_20160513_n449139101.shtml]: http://mt.sohu.com/20160513/n449139101.shtml
[20180225194110565]: /images/20220715/11081e2e57c9404e97d186c546eda264.png
[http_www.cnki.net_KCMS_detail_detail.aspx_QueryID_0_CurRec_10_recid_filename_JSJY201312029_dbname_CJFDHIS2_dbcode_CJFQ_pr_urlid_yx_v_MTA5MzFOclk5SGJZUjhlWDFMdXhZUzdEaDFUM3FUcldNMUZyQ1VSTHllWnVkbUZpbm5Xci9KTHo3QmQ3RzRIOUw]: http://www.cnki.net/KCMS/detail/detail.aspx?QueryID=0&CurRec=10&recid=&filename=JSJY201312029&dbname=CJFDHIS2&dbcode=CJFQ&pr=&urlid=&yx=&v=MTA5MzFOclk5SGJZUjhlWDFMdXhZUzdEaDFUM3FUcldNMUZyQ1VSTHllWnVkbUZpbm5Xci9KTHo3QmQ3RzRIOUw=
[https_my.oschina.net_stephenzhang_blog_650225]: https://my.oschina.net/stephenzhang/blog/650225
[http_www.infoq.com_cn_articles_summary-and-key-steps-of-vip-orders-depots-table]: http://www.infoq.com/cn/articles/summary-and-key-steps-of-vip-orders-depots-table
[MySql]: http://blog.csdn.net/xiaobluesky/article/details/50429428
[sharding_ _Sharding]: http://blog.csdn.net/bluishglc/article/details/7970268
[http_sanwen8.cn_p_3334qPr.html]: http://sanwen8.cn/p/3334qPr.html
[http_sanwen8.cn_p_175N8hr.html]: http://sanwen8.cn/p/175N8hr.html