兼容oracle的开源数据库,别总想着用使用Oracle的方式使用开源数据库

作为用惯了Oracle数据库的人来说，转而使用开源数据库或者国产数据库总是觉得有些不习惯。总是希望其他数据库都能像Oracle那样省心，但是其他数据库总是在某些地方不尽如人意。老白使用数据库是从dbase II 和vms rms起步的，那个时代数据库是应用的一部分，哪怕是大型数据库也是一样。第一次用大型数据库rdb的时候向那些老家伙请教如何在程序里用好rdb数据库。那些老家伙给我的最重要的建议是两条，第一条是自己单独建一个库，千万别图省事和别的应用共用一个数据库；第二条是程序里要把自己的数据库管好了，数据库服务没启动就先把库启动了再跑你的应用逻辑。那个时代的数据库都是分散的，与应用系统结合的十分紧密的，应用也都是T/S架构的应用，终端服务器模式的。伴随着C/S架构的出现，又出现了一个新名词，大型集中式数据库，其代表就是三强Oracle、SYBASE、Informix，DB2 UDB的兴起还要晚上几年。与以前的数据库不同的是大型集中式这几个字。首先，在C/S架构替代T/S架构的过程中，数据库作为一种基础设施，从应用中独立出来了；其次，这些数据库与以前的数据库的收费模式不同了，在VMS上只要购买一套rdb的许可证，你就可以在这台服务器上随便使用数据库，不管你建几个库，启动多少个数据库服务，有多少个并发访问，只收一次钱。而新兴的大型集中式数据库不同，是按并发数收钱的，因此企业用户再也不能像以前一样把数据库当成操作系统中的一个工具来使用你了。花了上百万买了一套数据库就必须物尽其用，因此“集中式”这个概念就深入人心了。不过集中式意味着纵向扩展能力，在这场超大并发能力，超强性能的大比拼中，Oracle以其优秀的CBO优化器，强大的资源管理能力，高效的共享池机制和独门绝技ORACLE RAC，在这场军备竞赛里一枝独秀，把所有的竞争对手都抛在了后面。同时也把我们的用户与开发商培养出了集中式情节。数据库的单库规模越来越大，甚至连最大型的小型机系统都无法承载单一数据库业务了。这时候Oracle RAC成了数据库选型的唯一选择。当时老白也和一些IT部门的主管聊过他们为什么不愿意用多个数据库而非要使用一个大型的集中式数据库。他们的回答不外乎三方面原因，一个是应用开发省事，另外一个是数据库太多了不好管理，第三个原因是少买几套库省钱。集中式数据库确实比较易于管理，不过也有一个不好的地方，那就是一旦数据库出问题了，那么所有的使用这个集中数据库的应用都会受影响。于是大家就想方设法提高数据库架构的可用性，HA/RAC/异地容灾/同城双活等等，只要确保了数据库是安全可靠的，那么信息系统的可靠性就有了一半了。于是DBA的价值也就水涨船高了。作为一个干了二十多年的DBA，老白也是这个时代的受益者之一。IT潮流是在不断变化的，随着应用架构体系的不断演进和业务的爆炸式增长，集中式的弊端已经十分明显了。于是分布式，微服务架构日渐流行。大量小型的APP替代大型信息系统的趋势也越来越明显。再加上这些年知识产权保护的不断深入，总是使用盗版的oracle来确保信息系统的稳定运行不是一条好路子了。于是开源数据库、国产数据库替代Oracle数据库的趋势越来越明显了。不少以前用惯了Oracle的人总是会有这样的感觉，Mysql要是有这个功能就好了，PostgreSQL为啥不能像Oracle那样做资源管理。还有一些人就希望能够用Mysql/PostgreSQL这样的数据库，通过分布式改造，能够构建出一套媲美Oracle的处理能力的数据库系统来，这也是这些年所谓分布式数据库厂商大量出现的主要原因。实际上，以老白的观点，找到一套能够完全替代Oracle的数据库解决方案并不是一个好的技术路线。大家都了解开源数据库与商用的Oracle数据库之间的技术差距，因此我们在使用这些数据库的时候也一定要因地制宜。合理的拆小应用系统，拆分数据库，采用读写分离技术分拆负载，认真的设计历史数据库，优化数据归档的规则。这样就能让数据库的规模，并发访问量都控制在一个合理的范围内。这样哪怕没有强大的资源管理器，CBO优化器的能力不如Oracle，没有ORACLE RAC的横向扩展能力，也不是啥大事情了。还有一个问题需要解决的，就是这么一来，数据库的数量变多了，需要管理的数据库数量多了，对于运维人员也是一个负担。不过我们有没有留意到，管理一个小型的MYSQL数据库的难度和管理一个大型的ORACLE数据库是不同的，管理前者对DBA的技能要求更低，需要投入的人力资源也更低。只要做好自动化运维工具，做好自动化监控，实际上很可能在DBA的资源投入上，使用了开源数据库很可能会有大幅降低。如果你不想对应用架构进行优化而只想用开源数据库替代Oracle，那么你总是会想到Oracle的各种好，而如果你的改造真的到位了，那么对于这些拆小的，应用开发上做了很好的资源管控的系统，甚至数据库不需要专职的管理都是可能的。数据库出问题了，要么重启解决，要么切换到备库，要么是某些应用写的不够好，要么就需要维护索引了。不再需要优化SGA，不再需要不断地解决ORA-600问题，这样的美好前景谁不想梦一梦呢。现在已经有很多企业在考虑后Oracle时代的数据库架构问题了。前阵子有一次和一个客户交流，他们提出了未来数据库的架构思想如下图：

OLTP生产应用都采用容器云，数据库与应用都部署在K8S云平台里。生产数据库最多只保留最近3个月的数据，确保数据库的规模可控。生产数据产生后通过消息队列传送到流式处理平台上，使用各种有向无环图来构建处理逻辑，完成数据的二次加工应用。同时通过数据订阅中心向各种其他数据消费者发布订阅的数据。经过流式平台加工后的数据汇聚到数据湖，经过价值发现后进入数据仓库或者把发现的数据价值发布到数据集市中。