开源项目：TSharding-client

1、单台数据库的数据量、数据处理能力是有限的。

2、分库分表用于应对互联网常见的两大场景：大数据量、高并发。

3、分库分表后，采用最终一致性的柔性事务居多，eventual consistency。

1、垂直切分，将表按照功能模块、关系密切程度划分部署到不同库表上。

2、水平切分，将表中的数据按照某种规则切分成结构相同的多个表和不同库上，通常是分片算法。

3、如果表太多而造成海量数据，并且业务逻辑划分清晰、低耦合，则垂直切分，简单明了，容易实施。

4、如果表并不多，但单表数据量很大或数据热度很高，则水平切分，做数据物理分割，考虑分割粒度、数据平均、负载平均、后期管理。

5、分片策略：按时间、名称、hash。

1、分库分表后，数据库事务管理困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的代价。如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

2、表关联join操作受到限制，无法join不同分库的表，也无法join分表粒度不同的表，结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

3、额外的数据管理负担，最明显的就是数据的定位问题和数据的增删改查的重复执行的问题，这些都可以通过程序解决，但必然引起额外的逻辑运算。例如对于一个记录用户成绩的数据表usertable，业务要求查询出成绩最好的100位，在进行分表之前，只需要一个order by就可以搞定，但分表后，将需要n个order by，分别查出每个分表的前100位，然后对这些数据进行合并计算，才能得出结果。

1、基于sharding支持分库分表

2、支持数据源路由

3、支持分布式事务

4、支持结果集合并

5、支持读写分离

6、支持ORM框架

7、其他：分片规则配置、Sql解析、Sql改写、Sql路由、Sql执行、结果归并。

8、分片框架很像mysql 的fabric

做数据与shard对应表，每次请求先从这张表中找shard id，再从shard中查询数据。

多hash表： 采用多个hash表的方式扩展原hash表。

可扩展的动态散列：引入一个仅存储桶指针的目录数组，用翻倍的目录项数来取代翻倍的桶的数目，且每次只分裂有溢出的桶，从而减小翻倍的代价。

线性散列：它能随数据的插入和删除，适当的对hash桶数进行调整，与可扩展散列相比，线性散列不需要存放数据桶指针的专门目录项，且能更自然的处理数据桶已满的情况，允许更灵活的选择桶分裂的时机，因此实现起来相比前两种方法要复杂。