sharding-jdbc分库实战

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/it_manman/article/details/84990473

参考文档http://shardingsphere.io/
配置
Java配置 较为繁琐，但是至少是java语言比较清晰，而且复杂的分片逻辑可以用java语言来实现更为方便（强烈推荐） 我上一些网站和论坛，大部分都会采用这种，因为逻辑可能较为复杂。
Yaml配置 比较简单清晰,很难处理复杂的分片逻辑（推荐）
springboot配置 low版yaml配置 （不推荐）
spring命名空间配置 繁琐,但是也有较强的结构 （看情况用,不推荐）
分库
优点:而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。水平扩展，在单机作用有限的情况下提供性能上的提升
分表
优点:减少笛卡尔积
分库分表的缺点：
我自己的理解首先分库分表增加了整个系统的复杂度需要相当多的资源去管理分库分表，如果实在没必要分库分表是一般不会采用
1、事务问题：在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担
2、 跨库跨表的join问题:在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
3、额外的数据管理负担:最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。