国产数据库能否替换oracle数据库？

对于Oracle能否被开源系衍生的数据库代替这个问题，个人觉得需要从两个维度去看。

第一个维度，技术维度。从技术维度来展开的话，首先需要看的就是产品的成熟度，这一点来讲，Oracle从三足鼎立的时代发展到今天独霸关系数据库排名之首的局面，是经历了很多年的技术洗礼，并且是来自全世界各种业务场景考验之后，才得到今天DB Engine上的荣耀。所以从通用产品的技术成熟度角度来讲，一定会胜过其他派系数据库。从性能维度展开的话，目前看到的一些性能测试报告都是来自于某厂商、某客户等局部范围内的报告，不具备权威性及足够的说服力。个人认为只有看到国际权威技术组织得出的权威报告之后才可评估。从特殊场景的支持角度来展开的话，这一点相信Oracle会逊色于一些从互联网业务场景诞生的开源系数据库，作为通用产品来讲，Oracle的设计之初一定没有想到今天中国互联网业务场景的复杂性和规模之巨大。但是这一点来讲，我觉得比的不够客观、因为我们是拿一个通用产品和一个为某类业务定制化的产品来进行比较，逻辑上有些牵强。

第二个维度，生态维度。Oracle数据库之所以发展到今天的地位，不仅仅是技术上的迭代更新，更重要的是服务、培训、社区等各个层面的同步发展。当用户不熟悉它的时候，它可以想尽办法去培养自己的用户群，一直培养到客户已经离不开它，这是一种技术行为习惯的颠覆。如果对全世界的DBA进行一个分类的话，我相信Oracle DBA 的人数一定远胜于其他，如果对所有搜索引擎上进行一个测试，基于Oracle的技术文章、问题讨论、原理分析等等的知识一定也会远胜于其他，这就是Oracle放水养鱼数年之后形成的巨大生态。这种生态不是一朝一夕就可以扭转的。

总而言之，国产化大背景的驱动下，这是发展国产数据库最好的机会，未来中国的DB市场格局一定是会向多元化方向发展。技术上我们经历了中国互联网业务飞速发展的这个特殊阶段，同时也掌握了一些别人掌握不了的尖端技术，这是我们的优势，市场也会给我们很多机会。但是如何培养好生态，站稳市场并最终发展壮大，这里有我们需要向国际厂商学习的地方。

我觉得和国产汽车一样。欠缺的大规模实际应用，没有应用只在实验室环境中的测试，理论上都是可以实现替换的。但真正在不同的行业用户中所产生的各种各样问题才是目前国产信息化面临的问题。包括和中间件的配合。包括对不同行业的数据处理的需求。包括在不同的系统环境。硬件环境下的适配。其实是整个生态圈的问题。但终究中国要走这一步。

刚看了下db-engines的排名，国产暂时还没上榜

个人感觉从技术上讲，提供肯定是可以的，但是很多事情不能单从技术上考虑
1.  很多传统的IT架构，都是经过很多年演进过来的。不管是上传应用开发还是中间层，和数据库有一定的耦合程度。不同的数据库有不同的特点，比如隔离级别、锁类型支持等，底层数据库的更换需要对上层应用做一定的修改适配。修改后的可用性、稳定性、性能都需做充分的规划和测试，确保可用支撑。如果从关系型数据库更换为分布式数据库，应用的改动可能就更大了，以前由数据库实现的功能逻辑可能都得在应用代码层实现。
2. 生态问题，目前国产数据库的生态相对还不如主流的几个国外数据库，在后续的技术支持，日常运维保障、运维团队组建等方面相对还有一定的劣势。这个也需要一个过程的积累。
3. 成本，对于一些技术实力强大的公司来说，使用国产数据库乃至自研+开源都是非常合适的，比如一些互联网公司。但是对于一些传统企业，比如医院、制造业，其IT部门的技术实力相对较弱，使用成熟的产品架构反而总体成本比较低。

目前，国产数据库发展还是比较快的，一些非核心的系统可用完全替代。有的甚至可用替换核心，如之前社区分享的某行TiDB上核心的案例，作为技术人的我们可以多关注一些，拥抱变化

首先说国产数据库是肯定能替换oracle的。
再者就是说迁移替换的工作量的问题，替换要看兼容性和替换后性能表现。国产的达梦数据库已经有很多案例，金融行业的案例也不少。达梦数据库对oracle的兼容性比较好，只要遵循SQL标准的应用都能直接运行。但是每个数据库都有自己的方言，不完全遵循SQL标准，oracle的应用如果使用了修改量一般也不是很多。关于架构和产品，达梦数据库有对应oracle常用两地三中心的架构产品都有可以实现的产品，不管是共享存储，还是主备，还是异构数据库数据同步，还是ETL 都已经有迁移成功案例。

这个得里应外合。外部得给机会，这个不敢切，那个不敢切，永远上不去。就像高中生考大学，不是得满分750才能上，680分就可以上。内部得舍得投入，真下狠心切过来了，肯定有大量问题，得舍得撒人去人肉运维。光想着切系统，不舍得运维上撒钱，哪个客户闲大了陪你玩，就算要去IOE。人家一个报告说不行，那就没法切，谁自己背雷替别人趟路。而且里边提的国产厂商有一头算两头，OCP级培训哪个铺开了，市场上没有OCP级的运维人员，啷个运维噻。都从厂家派么，厂家养得起几千个OCP级到处跑来灭火？

这是一个很纠结的问题，说的不好，容易被拍板砖。但是又不得不去面对。
从题目的角度来看，“# 国产数据库能否替换oracle数据库”，我认为肯定是可以是替换的。
为什么这样来讲呢？
传统的OLTP数据库对于应用程序来说，我认为最大的价值还是ACID的四个特性，其他都可以看做附属价值，换言之，其他的一些功能是可以通过应用补偿来去实现的，ACID确实不好在应用侧来去实现。
所谓“ 国产数据库能否替换oracle数据库 ”可行性，唯一办法是从项目的角度出发，数据库能力不如ORACLE的地方，应用程序去做补位以完成数据库的替换。所以我说，国产替换ORACLE是可行的。
但是从数据库产品能力和软件能力来去评判，国产数据库和ORACLE还有很大很大的鸿沟，这个现状我们需要有清醒的认识。不是说我们完成了一个oracle数据库替换的项目，我们的国产数据库就具备和ORACLE PK的产品能力。我认为这是两件事情。
我遇到过很多很多用Oracle数据库的甲方，他们提的问题通常是两个：1、oracle的兼容性如何？2、是否可以超过oracle计算能力。
其实我们应该反过来思考：
1、提到了oracle的兼容性，基本上都是面向应用的语法和函数的兼容性，而不能代表产品的全部能力。从这点上来说,oracle的兼容性和oracle具备的产品能力两者之前还有很大差距。
      很多客户都以为自己对ORACLE很熟悉很了解，其实大部分还是停留在应用层面。我个人认为ORACLE本身如同一个庞大而复杂的机器，极少有人能退出来看到机器的全貌，绝大部分人都是扎到机器里面看到某几个部分。
2、从代码、算法、还是优化器、RAC、ADG等，我都认为ORACLE是非常非常非常强大的，换言之，就算我们在某个场景比ORACLE计算的快，也不能说我们具备了和ORACLE一样的能力，更不能说完全替换ORACLE。

我们需要清醒的认识到数据库到底是干什么用的，我们自己的业务场景到底是需要什么样的数据库能力，我们就能选择出适合自己的数据库产品。

总之，我的看法国产数据库的路还长，我们不能因为在项目上替换几个ORACLE数据库而骄傲自满，也不能因为看到和ORACLE产品能力的差距而妄自菲薄。

这个问题很多年前就被提出来，当时去ioe最难的一点就是去o，既然有人提出这个想法，肯定很多企业很多人去在为这件事努力，近几年国产的数据库越来越多，也有一些客户进行了替换。如果单从技术来说，国产厂商无论是代码开发还是版本维护，肯定可以做出媲美oracle的数据库，但是一时间没有那么多客户敢一步迈出去，技术来说没有问题，现在只是推进方面，大家比较谨慎。不过国际大环境如此，相信国产替换这只是时间问题，这段时间也给了国产数据库的厂商更多的机会。性能，架构，包括其他一些功能，国产数据库肯定没有任何问题。如果真的替换了，对于运维人员来说，其实应该没啥问题，技术是相通的，很容易就能入手的，这不会给运维带来问题的，现在最主要的就是一些大客户进行推进，一些中小企业并没有足够的技术支持进行替换，如果大客户逐渐替换，给其他人员更多的经验和案例，我相信，近几年，国产数据库会更多的替换oracle。

国产数据库能不能替换oracle？能，但是困难一定很多。没有什么数据库是无法替代的，只是替代的代价到底有多高。迁移替代需要考虑很多方面：

1 性能

首先是性能有没有oracle好。其实是大部分国产数据库都不一定比得过oracle，但也不是天差地别。单纯的简单sql应该相差不大，复杂的sql经过优化拆解，也能变成简单sql。

国产分三种，自研内核，基于pg内核改造，或者是在mysql基础上改造。我测了很多数据库，现在拿openGauss作为迁移对象。这个数据库能够支撑混合负载类型，性能不差oracle多少。

2 兼容性和迁移方式

这个可能是代价最高的地方。向存储过程，内部函数什么的，几遍国产数据库做的再好，也不可能100%完全兼容oracle语法。所以对于需要迁移的oracle，如何迁移数据库对象，如何将原有的存储过程改写到程序里面去。

对象迁移都还好说，厂商也会有些工具来帮助迁移。数据迁移也会有各种办法，无论是否落地。但是这些都是很繁琐的工作，也很容易出错。反正加点投入还是能做到的。

3 数据同步

保险起见，迁移之后有可能需要并行运行一段时间，其中oracle和新的数据库需要有实时同步数据的方式，这个当前也是需要工具支持的。不同的数据库有不同的工具，这个具体好不好用不太好说。数据同步还能当做短暂停机切服务的迁移方式来用。

4 架构和稳定性

oracle的架构和稳定性已经很成熟了。 而现在的国产数据库架构也和oracle差不多，都是双机，HA，物理日志同步等方式。架构上应该差别不大。但是稳定性肯定存在不确定性。

所以新的国产数据库，一定要在高可用保护上多做文章，尽可能多冗余，自动化切换方案等方式要做好，争取面对突发问题的时候有快速的解决方案。

5 分布式

现在分布式数据库也大行其道。通过资源横向扩展，数据分片等方式，既满足了性能扩展需求，也减少了单点故障的影响。部分高负载的oracle数据库，考虑迁移到分布式的国产数据库环境也算是个方案。

国产数据库替代已经是个不得不面对的事情，所以下定决心去o，总是能办到的。

目前在核心业务还不能。事关生死慎重又慎重。非核心业务可以勇敢尝试，不给国产产品机会，永远不能替代。

这个问题只能作为一个粗浅观点交流来谈谈，不具备作为决策意见的意义，毕竟没有任何一家国产厂商敢拍胸脯保证能完全替换Oracle，并且不会出现重大故障。功能、性能这些方面要展开说的话太多了，另外国产数据库厂商公开或中立评测数据都太少，大多都是厂商自行测试的结果，需要甄别。

这就像五菱宏光和兰博基尼，作为车，都有车的基本功能。
我平时开兰博基尼60码跑城市路，开多了想换个口味，开五菱宏光60码跑城市路行不行？肯定是行啊，顶多驾驶感受和节奏打些折扣。
若我平时开兰博基尼下赛道飚到200多码，开惯了还觉得不带劲，想开五菱宏光去赛道飚个车、和兰博基尼来一把，行不行？为什么不行呢，五菱宏光的仪表盘上不还是有200码，一脚油门下去速度还不是能飚起来。你说安全？你都想着开五菱宏光下赛道和兰博基尼一较高下，还谈安全不安全？