业务分表方案咨询

Question

大家好，目前在考虑分库分表方案：

问题场景描述:

视频（子）和专辑（父）关系，一个专辑对应多个视频，一个视频只属于一个专辑；

总数据量在千万级以上，一部分是有专辑的视频，另外一部分是无专辑的视频；

注意点：视频所属专辑会变更的 （父子关系会变化）。每个视频还会有对应的关联子表。

 

分表方案设计：

 1）同一个专辑中的所有视频放在一个表中，便于上层应用查询。问题就是如果视频变更到新的专辑，就需要迁移原专辑视频到新专辑所在表中，这里会涉及事务操作。有的专辑下视频上千条，个别会上万条，所以同步在一个事务中执行，效率很低。

     另外的一个想法就是避免上述的迁移数据问题，直接将分片后表名记录到路由中间表，然后在原专辑所在表中直接更新下所属专辑（即关联的专辑ID）。

 2）没有专辑的单视频单独可以单独做分片，对外接口（有缓存，如果缓存没有回查DB）有通过批量id查询需求，涉及跨表join。

 

以上方案如果使用sharding-jdbc能否直接支持呢，第1）个方案是否需要自己实现分片算法呢？

 

以上请教大家！

Answer 1

0 嗯，您提到的建议尽量不要修改数据的分片键。 比如无专辑视频A，最开始计算出的分片对应表table_k1，接下来将A关联到了一个专辑Pa上，这个视频A仍然在table_k1表中吗？ 因为有场景是根据专辑查询所有视频列表，是不是迁移到专辑Pa所在分片上更合适些？ 还是仍然在table_k1上，通过sharding-jdbc来实现聚合查询呢？

Answer 2

上面提到的相当于针对同一表混合分片方式了（既有按专辑ID，也有按视频ID），应该能支持吧？我看demo给出的是单片键示例。

Answer 3

可以支持。

但是建议尽量不要修改数据的分片键，否则需要进行数据迁移。

另外，专辑和视频这种有强对应关系的，建议使用Sharding-JDBC提供的BindingTable，分片的效果会比较好。

Sharding-JDBC没有提供默认的分片策略，每个分片策略都需要自己写，但是不难，直接看看example应该就会了。

 

Answer 4

最终总结下，基本思路已经明确。 因实际的无专辑视频数据量要大于有专辑的视频数据量。 所以，我们针对有专辑视频，按照专辑ID进行分片，无专辑视频则按照视频ID分片。同时，会有一个路由表记录下映射关系，视频ID自增通过这个表先生成下，这块用sharding-JDBC应该在分片策略自行实现中来完成。

Answer 5

从需求上看数据迁移是避免不了的。

以这个例子来说，我的建议是：可以设置为专辑表和视频表是1对多的关系。分片键是专辑ID，这样专辑表和视频表是Sharding-JDBC的BindingTable。如果视频的专辑变了就迁移专辑数据。这样通过专辑ID查询视频比较方便。

另外一个办法是分片键设置为视频ID，这样视频无论如何修改所属专辑，都不会产生数据迁移，但是查询麻烦，因为每个专辑的视频不一定在一个表上，需要全路由查询。

因此需要根据改和查的平衡设计了。