数据库高可用方案PK：选择Oracle还是MySQL？

作者：杨建荣

关于Oracle和MySQL的高可用方案，其实一直想要总结了，今天分为几个系列简单说说。通过这样的对比，会对两种数据库架构设计上的细节差异有一个基本的认识。

高可用方案概览

Oracle有一套很成熟的高可用解决方案MAA。用我在OOW上的ppt来看，这个方案自9i开始，到今年已经有16个年头了。

如果从技术架构的角度来看，部署的分布图类似下面的形式，中间有远距离的数据传输，可以通过中间的节点来转换，中间这个节点很特别，是不存数据的，只是保持一个内存结构，同步数据。

这种扩展方式简直是酸爽，在一些跨数据中心的场景，允许一定延迟的情况下还是有用武之地。比如你需要从北美读数据，可以从北美推送数据库到香港或者新加坡，再推送到北京。有了这种方式就很容易扩展。当然在实时交易中还是存在一些瓶颈和缺陷。

展望和后续补充

如果抛开具体的数据库，整体来说数据量和业务量到达一定程度都会碰到一系列的问题。这些都是痛点也是难点，常见的问题如下：

单台服务器无法承载已有的压力

数据库单表容量越来越大

大量的读写需求无法平衡

资源如果扩容，应用改动较大

资源的负载没法拆分，或者不易拆分

这时就需要扩展，就需要匹配的解决方案，比如中间件的方案，有的解决了一些通用的问题，有些侧重于某一方面。比如需要考虑sharding来分片，读写分离来做分担读写压力，前端海量访问可以通过大量的水平扩展来分担。

从这个角度来说，MySQL是以架构和规模取胜，通过业务拆分和架构拆分能够实现线性扩展。而Oracle的扩展性虽然没有那么好，但从架构和业务层面来说也能做，这个后续有机会再细细说一说，可以拟一篇分布式方面的文章。

小结

简单总结一下，高可用的方案选择很多，各家有各家的需求，能定制的定制，能开源的开源。大道至简，只要满足了需求，系统稳定不背锅，那就是最好的方案。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。