MYSQL下如何优雅的对一个大数据量的表进行自动的分库分表存储。

MYSQL下如何优雅的对一个大数据量的表进行自动的分库分表存储。
当一个表预期数据量足够大的时候,如果进行分库分表存储,读写分离,来实现高效、稳定的数据存储和读。

参与3

1同行回答

bryanbryan  软件架构设计师 , 金融研发
分库分表分区是解决大数据量时的一个分而治之的思路,建议依次考虑的顺序如下1.分区:表分区之后只是引擎存储的工作去保证,对用户相对透明,因为对应用侵入度较低;2.分表:在同一个schema中的多个表,应用可能需要根据业务逻辑去判断业务对应的表,这种情况下单库内路由也相对比较好办...显示全部

分库分表分区是解决大数据量时的一个分而治之的思路,建议依次考虑的顺序如下
1.分区:表分区之后只是引擎存储的工作去保证,对用户相对透明,因为对应用侵入度较低;
2.分表:在同一个schema中的多个表,应用可能需要根据业务逻辑去判断业务对应的表,这种情况下单库内路由也相对比较好办;
3.分库:这个方法最大的问题就是分布式事务,目前市场有很多开源中间件可以选择,如当当或者360的,但未必能够满足需求,需要进行选择。

其实可以考虑为什么会出现大数据量呢?如果从生命周期角度考虑,对于这样大量的数据,是否可以分为热、温和冷三种类型呢?如果存在,那么
1)冷数据(历史数据):是否就可以从现行数据表中进行定期剥离呢?比如交易记录,后续只是进行查询,完全可以将完全交易的数据进行定期转存到历史库
2)温数据:对于访问频度相对低一点的数据,如果考虑存储成本,是否可以采用分区的形式将这些数据放在相对廉价的存储上面
3)热数据:对于频繁访问的数据,一般是整个系统的性能瓶颈点,是否可以考虑SSD的硬盘,这样能保证既有业务的快速响应
对于数据生命周期的管理还是需要考虑业务实际场景

当数据量比较大时落地实现的所有功能都交给数据库吗?作为架构设计中的业务架构、应用架构、技术架构、数据架构和部署运行架构中的架构之一,应该是与其他架构设计逻辑整合的一起的,因此需要应用人员和业务人员的参与,有部分功能为了保障数据库整体性能需要提升到应用逻辑中去完成,这样可以更好的提升数据库性能,我们在实战中的一些经验,比如不用存储过程、不用外键、不用复杂表操作,尽量单表操作,这些不是不做了,是数据库不做了,约束交给应用去做了,这样应用在从数据库得到快速响应后可以在应用层面进行逻辑处理,而这种处理的服务器一般可以较好的进行扩展,提高响应能力

收起
银行 · 2017-05-19
浏览12135

提问者

hht202208
业务部门经理aaaa
擅长领域: 数据库服务器中间件

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2017-05-17
  • 关注会员:2 人
  • 问题浏览:14595
  • 最近回答:2017-05-19
  • X社区推广