数据库的分库分表

一 概念: 什么是分库分表 (sharding)

1 将集中于单一节点的数据拆分并分别存储到多个数据库或表, 称为分库分表
2 数据切分分为两种方式, 垂直切分和水平切分
3 分库: 因为表多导致数据过多使用垂直切分, 垂直切分就是根据业务的耦合性, 将关联度低的不同表存储在不同的数据库, 按照业务分离进行独立存储
4 分表: 每张表的数据非常多适合使用水平切分, 即把表的数据按某种规则切分到多个数据库上
                 

二 用途: 分库分表用来解决什么问题

 数据库面对海量数据由于数据量过大导致的性能问题 

三 用例: 具体的使用用例, 解决了什么典型问题

Sharding 的基本思想就要把一个数据库切分成多个部分方法哦不同的数据库 server 上, 从而缓解单一数据库的性能问题,    

中间件

• 当当 sharding-jdbc
• 蘑菇街 TSharding
• sharding
• TDDL Smart Client 的方式 — 淘宝
• Atlas — 360
• alibaba.cobar 阿里巴巴 B2B
• MyCat 基于阿里开源的 Cobar
• Oceanus 58 同城
• OneProxy 支付宝首席架构师 楼方鑫
• vitess 谷歌

分库分表后会遇到什么问题?

• 事务问题 方案一, 使用分布式事务. 方案二, 由应用程序和数据库共同控制
• 跨节点 Join 的问题 方案, 两次查询 第一次找出关联数据的 ID, 第二次根据这些 ID 获得关联数据
• 跨节点的 count,order by,group by 以及聚合函数问题 方案, 并行在各节点上查询然后合并结果

• 数据迁移, 容量规划, 扩容问题

         来自淘宝综合业务平台团队，它利用对 2 的倍数取余具有向前兼容的特性（如对 4 取余得 1 的数对 2 取余也是 1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了 Sharding 扩容的难度 

• ID 问题

  UUID , 结合数据库维护一个 Sequence , [Twitter 的分布式自增 ID 算法 Snowflake][1]

• 跨分片的排序分页 方案, 限制能查看的页数, 一定要查看可缩小范围重新查看
• 分库策略 根据数值取模
• 分库数量 初次建议 4 – 8
• 路由透明
• 使用框架还是自主研发

扩容

  //TODO

四 其他解决方案

 主从  读写分离  缓存   

五 熟悉原理, 重新实现

//TODO

备注

1 , 横向扩展 也叫 水平扩展，用更多的节点支撑更大量的请求。如成千上万的蚂蚁完成一项搬运工作
2 , 纵向扩展 又叫 垂直扩展，扩展一个点的能力支撑更大的请求。如利用 1 个人的能力，如蜘蛛侠逼停火车
3 , 参考 分库分表的基本思想