Mysql数据库大表优化方案和Mysql大表优化步骤(3)

2019-03-07 14:41:49 来源:互联网作者:佚名 人气: 次阅读 918 条评论

当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化。单表优化  除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部...

解决方案

由于水平拆分牵涉的逻辑比较复杂,当前也有了不少比较成熟的解决方案。这些方案分为两大类:客户端架构和代理架构。

客户端架构

通过修改数据访问层,如JDBC、Data Source、MyBatis,通过配置来管理多个数据源,直连数据库,并在模块内完成数据的分片整合,一般以Jar包的方式呈现

这是一个客户端架构的例子:

20190307150302.jpg

可以看到分片的实现是和应用服务器在一起的,通过修改Spring JDBC层来实现

客户端架构的优点是:

  • 应用直连数据库,降低外围系统依赖所带来的宕机风险

  • 集成成本低,无需额外运维的组件

缺点是:

  • 限于只能在数据库访问层上做文章,扩展性一般,对于比较复杂的系统可能会力不从心

  • 将分片逻辑的压力放在应用服务器上,造成额外风险

代理架构

通过独立的中间件来统一管理所有数据源和数据分片整合,后端数据库集群对前端应用程序透明,需要独立部署和运维代理组件

这是一个代理架构的例子:

20190307150332.jpg

代理组件为了分流和防止单点,一般以集群形式存在,同时可能需要Zookeeper之类的服务组件来管理

代理架构的优点是:

  • 能够处理非常复杂的需求,不受数据库访问层原来实现的限制,扩展性强

  • 对于应用服务器透明且没有增加任何额外负载

缺点是:

  • 需部署和运维独立的代理中间件,成本高

  • 应用需经过代理来连接数据库,网络上多了一跳,性能有损失且有额外风险

各方案比较

201902.jpg

如此多的方案,如何进行选择?可以按以下思路来考虑:

  • 确定是使用代理架构还是客户端架构。中小型规模或是比较简单的场景倾向于选择客户端架构,复杂场景或大规模系统倾向选择代理架构

  • 具体功能是否满足,比如需要跨节点 ORDER BY,那么支持该功能的优先考虑

  • 不考虑一年内没有更新的产品,说明开发停滞,甚至无人维护和技术支持

  • 最好按大公司->社区->小公司->个人这样的出品方顺序来选择

  • 选择口碑较好的,比如github星数、使用者数量质量和使用者反馈

  • 开源的优先,往往项目有特殊需求可能需要改动源代码

按照上述思路,推荐以下选择:

  • 客户端架构:ShardingJDBC

  • 代理架构:MyCat或者Atlas

兼容MySQL且可水平扩展的数据库

目前也有一些开源数据库兼容MySQL协议,如:

  • TiDB(https://github.com/pingcap/tidb)

  • Cubrid(http://www.cubrid.org)

但其工业品质和MySQL尚有差距,且需要较大的运维投入,如果想将原始的MySQL迁移到可水平扩展的新数据库中,可以考虑一些云数据库:

  • 阿里云PetaData(https://cn.aliyun.com/product/petadata/?spm=5176.7960203.237031.38.cAzx5r)

  • 阿里云OceanBase(https://cn.aliyun.com/product/oceanbase?spm=5176.7960203.237031.40.cAzx5r)

  • 腾讯云DCDB(https://www.qcloud.com/product/dcdbfortdsql.html)

NOSQL

在MySQL上做Sharding是一种戴着镣铐的跳舞,事实上很多大表本身对MySQL这种RDBMS的需求并不大,并不要求ACID,可以考虑将这些表迁移到NoSQL,彻底解决水平扩展问题,例如:

  • 日志类、监控类、统计类数据

  • 非结构化或弱结构化数据

  • 对事务要求不强,且无太多关联操作的数据

原文出处:https://segmentfault.com/a/1190000006158186

END

您可能感兴趣的文章

相关文章