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

解决方案

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

客户端架构

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

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

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

客户端架构的优点是：

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

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

缺点是：

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

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

代理架构

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

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

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

代理架构的优点是：

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

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

缺点是：

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

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

各方案比较

如此多的方案，如何进行选择？可以按以下思路来考虑：

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

• 具体功能是否满足，比如需要跨节点 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