云南龙网

  1. 首页 > 云知道 > >

一次sharding,shardingjdbc( 二 )

云知道


此外，由于这一类型的业务数据量普遍较大，比如清算系统的清分明细、云管平台的资源计量明细、订单系统的订单流水和云计算主机资源上报的性能数据等，如果只是使用单库单表存储的普通方案，那么在单表数据量达到千万级别以上的时候，单库的IO读写能力将持续降低，会成为业务系统整体吞吐量和性能的瓶颈 。对于上述的问题，有一些对DB较为熟悉的同学第一时间想到的解决方案，可能会是MySQL的分区表 。
MySQL的分区表比较适合用于解决业务数据具有较强时间序列特点，且数据量偏大的场景 。但是，如果SQL的查询条件并非基于时间维度的，那么执行起来的效率并不会有所改观，同时对于处理单表千万级别以上数据量时，MySQL的分区表方案还是会显得有些“力不从心” 。对于以上这种“流水”/“明细”类的业务数据，作者还是推荐使用水平切分的方案从根本上来解决业务上遇到的单表数据过大的问题 。
由于该类型的业务数据基本不会涉及跨库的Join连表SQL查询、只需保证分库的本地事务，且并不会遇到上面水平切分方案中的几个需要考虑的问题，对于这样子的业务场景可以考虑使用水平切分的方案 。那么，我们应该选择哪一款开源的分库分表组件，又或者是根据业务情况来自己定制化研发呢？选型分库分表中间件的分析如果业务系统设计之初打算采用水平切分方案的话，那么有必要好好思考下如何来选型分库分表的中间件 。
在当前业界开源组件中比较流行的两款代表分别为ShardingJdbc和MyCat 。ShardingJdbc这款分库分表组件代表了客户端类的分库分表技术框架，其定位为轻量级数据库驱动，可以由Spring Boot这样的业务工程直接快速集成，以jar包形式提供服务，无需额外部署和其他依赖 。对于业务系统的开发人员与数据库运维人员无需改变原有的开发与运维方式 。
在2.X版本中，采用"半理解"理念的SQL解析引擎，以达到性能与兼容性的最大平衡 。因此，ShardingJdbc即为增强版的JDBC驱动，其优势在于无需对原有的业务工程进行任何改造的基础上，即可使其拥有分库分表的能力，成本较低，易于上手 。但是，也有缺点，中间件与业务应用工程绑定在一起，对应用本身有侵入 。
并且目前只支持Java语言，问题难以追踪 。而MyCat是一个开源的分布式数据库系统（属于代理类框架），相当于一个实现了MySQL协议的数据库代理服务器 。用户可以使用MySQL客户端工具和命令行访问，而其后端使用MySQL原生协议与多个MySQL数据库服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信 。
其分库分表的方案优点在于，能够处理非常复杂的需求，不受数据库访问层原来实现的限制，扩展性强且对于应用服务透明且没有增加任何额外负载 。其缺点是上线部署需要额外的中间件，增加运维成本；应用服务需经过代理来连接数据库，网络上多了一层链接的开销，性能有损失且有额外风险 。使用ShardingJdbc解决的基本业务场景选择ShardingJdbc组件后，就需要使用该组件来解决实际的问题 。
这一节主要根据之前提到的“流水”/“明细”一类的业务数据，同时结合ShardingJdbc组件的特点来进行一定的分析，使得读者对正确使用ShardingJdbc组件进行业务系统水平切分有一定的了解 。前面已经提到了“流水”/ “明细”类的业务数据，一般是准实时或者说相对滞后，需要按小时、按日和按月汇总处理后生成最终的业务数据（如账单、报表和话单等） 。
我们对“流水”/“明细型”业务数据处理过程中，一般都会涉及数据落库（Insert SQL）、数据分组汇总和分组查询（Select sum(xxx) Group By SQL）以及删除数据表（Delete SQL）等业务处理操作 。这里有必要对这几种类型的SQL进行一定的说明：a. 数据落库（Insert SQL）：流水/明细类的数据一般都需要先DB持久化处理；以云计算平台中10W台虚拟机同时产生性能明细数据上报，如果是单库单表，则这个数据库会进行每小时会有10W次的写请求；如果使用100个分表（分10个库，每库10个表）则每个表平均承受1000次写请求，每个库平均分担1W次的请求压力，这样子就可以将原来单库单表的写请求压力成倍的减少；一般业务研发人员使用ShardingJdbc组件，设置合理的数据分片路由规则，即可使得流水/明细类的数据基本均匀落在我们预先设置的分库分表中 。

推荐阅读


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

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