云南龙网

  1. 首页 > 云知道 > >

一次sharding,shardingjdbc( 三 )

云知道


b. 数据分组汇总查询（Select sum(xxx) Group By SQL）：由于（a）中持久化至分库分表的业务数据为若干段时间的业务数据，根据业务需求还需要按日，按周或者按月进行累加汇总，因此有必要对各个分表中的数据执行Select sum(xxx) Group By的分组汇总SQL；ShardingJdbc组件可以完成SQL的解析、改写、路由和结果归并，对于“Select sum(xxx) Group By SQL”的语句，可以遍历设置的多个分库分表，对每个分库分表执行SQL后进行一个结果归并再返回给业务调用方 。
c. 删除数据表（Delete SQL）：一般业务系统对会通过定时任务来生成明细数据加工处理后的业务数据（比如用户账单、清偿明细、云资源按日按月的话单） 。一旦生成这些有效业务数据后，原来落库的明细也就没有什么业务价值，可以通过任务定期删除或者迁移至历史库的方式来使得分库分表的数据水位量级维持在一定量，因此就需要涉及对原来存储在分库分表的明细数据进行删除；ShardingJdbc组件可以根据“Delete SQL”语句中的筛选条件进行规则路由来定位某个分库和分表，否则会删除所有分库中的分表数据 。
系统集成ShardingJdbc的设计根据上面对“流水”/“明细”型业务数据的场景分析，基本可以画出SpringBoot业务工程集成分库分表组件ShardingJdbc的架构设计图：从上面业务系统架构设计图中可以看出，明细型业务数据（比如之前提的，清算系统的清分明细、云管平台的资源计量明细、订单系统的订单流水和云计算主机资源上报的性能数据明细）根据设置的数据分片路由规则先落库至shardingdb00~ shardingdb04五个分库的对应分表中 。
然后，利用ShardingJdbc组件对分组汇总查询SQL的解析、改写、路由和归并结果的能力，分别对五个库中对应业务分表中的数据汇总累加求出每天/每月同一个用户下的资源计费累加值 。最后，将这些“加工”后的业务数据批量插入至共享库share_db中，其他定时任务再从共享库中读取并生成最终形式的业务数据（比如，按月的账单、话单或者性能计量值） 。
其中，对于异常情况（明细流水异常、汇总异常和系统异常等），需要将其保存至共享库中的异常信息表中 。另外，在明细落库之前还需要考虑幂等前置校验的问题 。对于ShardingJdbc组件的分库分表路由规则可以参照下图：从上面的分库分表路由规则图上可以看出，预先设置了通过客户id来路由定位至分库，通过用户id来路由定位至分表 。
这里，由原来的单库单表分成五个库的多分表（每个库中均有testmsgqueuebillrecord0～testmsgqueuebillrecord4五个分表，这里只是示例，在真实的业务场景下需要根据业务数据的总体容量来设定分库分表的规模，究竟是分5个库每个库5表，还是分10个库每个库10表来满足业务要求） 。
在一般情况下，如果执行的SQL为“select * from testmsgqueuebillrecord”就能借助ShardingJdbc组件来遍历查完5个分库中的testmsgqueuebillrecord0~4五个分表，无需我们自己来做分库分表的遍历查询了 。总结本文先介绍了目前两种数据切分的主要方案（垂直切分和水平切分）及其优缺点 。
根据“流水”/“明细”类别的数据切分业务场景，阐述了业务系统设计之初选型分库分表组件的分析，并介绍了如何利用ShardingJdbc来解决“数据落库（Insert SQL）”、“数据分组汇总查询（Select sum(xxx) Group By SQL）”和“删除数据表（Delete SQL）”的几种基本业务场景 。
最后，给出业务系统集成ShardingJdbc组件后的架构设计方案 。本文仅仅使用了Sharding-Jdbc组件的核心功能来解决了一部分基本的业务场景问题 。ShardingJdbc组件还有其他很多高级的功能（比如读写分离、最大努力送达型的柔性事务、分片路由规则动态配置和数据库治理和ShardingProxy等 。

推荐阅读


上一篇：我们25万T1老锤子就是活该，谁让新锤一下帮老罗搞定50万

下一篇：到底什么是直销,直销牌照