ShardingSphere笔记（一）： 经验和踩坑总结

ShardingSphere笔记（一）： 使用经验总结

这篇文章里面只简单总结一些使用ShardingSphere的个人经验，具体的技术实现可以看后面的文章。

先叠个甲，这里面提到的一些解决方案是针对我们的项目总结出来的，可能并不适用于所有情况，算是一个思路。具体场景还需要具体分析。如果各位大佬有更好的解决方案欢迎讨论。

一、背景

公司之前的项目中，所有的历史数据都是使用单表进行存储的，随着历史数据越积越多，有的历史数据表中的数据已经到了上亿条数据，数据的查询就成了一个很大的问题。

以往的时候，除了历史数据查询操作历史数据表的情形比较少，很多数据的查询走的都是抽样表和近期表。但是随着功能的不断扩展，需要从历史数据中分析更多的东西，这时候分库分表就是一个很迫切的需求了。

框架选择

当时我们有两种选择，一个是 mycat、一个就是shardingsphere。
mycat是代理数据库访问，可以看成是一个数据库代理。
而shardingsphere提供了两个项目，一个shardingsphere-jdbc， 一个是shardingsphere-proxy。看名字就能看出来一个是提供jdbc驱动类的jdbc增强库。另一个就是类似于 mycat 的数据库代理了。

经过查询一些资料我更倾向于shardingsphere-jdbc来做数据库分表。原因如下：

1. 我们的项目不是类似于互联网那种提供云服务的项目，而是需要打包卖给很多客户的。考虑到部署与维护，架构需要尽量减少维护环节。
2. shardingsphere 也提供了代理端的项目，如果使用 shardingsphere 来做，将来想要切换到代理数据库的实现方式切换成本也会比较小。
3. shardingsphere 作为 Apache的顶级项目，框架稳定性方面会更信任一些。
4. Mycat官网的文档真的欣赏不来，反而shardingsphere管网的文档很漂亮。

二、ShardingSphere-jdbc 只是一个帮助你路由的框架（踩坑总结）

这是我在使用和封装框架的过程中一个坑一个坑总结到的最深刻的经验。那就是ShardingShpere没有我们想象的那么智能，在数据分片中，它只是负责帮你去路由。

在这里我们需要先理解ShardingSphere是怎么来做路由的。他通过代理 jdbc，在sql查询的时候通过解析sql，找到你想要查询的表。然后根据你配置数据库表的分片算法根据对应的列找到应该从哪些数据库、哪些数据表中查询数据。

所以这是为什么它会存在很多限制：

1. 存储过程不支持。（存储过程可以理解成在数据库端存储的封装好的函数，鬼才能从函数名解析到你想要查那个数据库呢，就算解析到了也改不了你的存储过程内容）
2. 分片列的函数，对分片列的函数同样无法应用分片算法。
3. 查询需要待分片列，如果不带分片列就没办法走分片算法，那么就会出现全表查询，所有表都要过一遍，尤其当存在join的时候，甚至存在笛卡尔积的查询次数。效率极差。

这还意味着：

1. 它默认会认为你配置的所有的节点都是存在的

就像上面说的，框架没有那么智能，它会认为你既然都让我路由了，那你所有的表都应该存在才是。所以忽略了这个情况就可能会出现一些莫名其妙的问题。以我踩过的坑为例。

我们是需要按月分表的，而按月分表我们又不想一次性建好那么多表，要不然数据库突然多了那么多空的数据表，管理也很麻烦。

所以来看看大聪明是怎么想办法解决这个问题的呢？

spring:
  shardingsphere:
    datasource:
      # ....
  rules:
    sharding:
      tables:
      # 需要分片的数据库表
        test_data:
          # 大聪明觉得我一次性配置了200年的表规则，就可以一次性配置一劳永逸了吧，哈哈
          actual-data-nodes: ${
   
   ['ds1', 'ds2']}.test_data_${
   
   2018..2200}0${
   
   1..9}, ${
   
   ['ds1', 'ds2']}.test_data_${
   
   2018..2200}0${
   
   10..12}
          table-strategy:
            # ....

这里，一次性配置了200年的数据表规则，但是数据库里面其实没有这么多的表。测试运行没问题。但是现实非常露骨