业务分表方案咨询

大卫1228 发布于 2017/05/23 17:39
阅读 259
收藏 1

大家好,目前在考虑分库分表方案:

问题场景描述:

视频(子)和专辑(父)关系,一个专辑对应多个视频,一个视频只属于一个专辑;

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

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

 

分表方案设计:

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

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

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

 

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

 

以上请教大家!

加载中
0
亮_ShardingSphere
亮_ShardingSphere

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

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

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

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

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

可以支持。

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

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

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

 

大卫1228
大卫1228
上面提到的相当于针对同一表混合分片方式了(既有按专辑ID,也有按视频ID),应该能支持吧?我看demo给出的是单片键示例。
大卫1228
大卫1228
0 嗯,您提到的建议尽量不要修改数据的分片键。 比如无专辑视频A,最开始计算出的分片对应表table_k1,接下来将A关联到了一个专辑Pa上,这个视频A仍然在table_k1表中吗? 因为有场景是根据专辑查询所有视频列表,是不是迁移到专辑Pa所在分片上更合适些? 还是仍然在table_k1上,通过sharding-jdbc来实现聚合查询呢?
返回顶部
顶部