分库分表方法合集-蒲公英云

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

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=

唯品会分库分表说明

https://my.oschina.net/stephenzhang/blog/650225

唯品会分库总结

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