去O的话题由来已久。自十年前阿里提出这个口号，并率先在公司内部实现了数据库的整体去O化，互联网公司和传统企业纷纷效仿。可以说，de-O的概念逐渐深入人心。但直到现在，我们可以看到甲骨文在国内市场还是占有相当大的比重。即使在对外的多次宣传中，也大多是非重度O案例或非关键业务系统，大量核心关键业务系统仍然采用O方案。那么造成这种现象的原因是什么？本文试图分析去O可能面临的困难和应对策略。以下文字代表个人观点，仅供参考。1.难点：功能完备性Oracle是从70年代开始开发的。经过40、50年的发展，其功能完备性已经达到了很高的水平。可以说，Oracle仍然是数据库界最强大的产品。从早期关系模型的实现、集群概念的首次提出、多模式异构存储的引入、软硬件的融合、人工智能在数据库中的应用等，甲骨文不断提升产品能力.在本世纪初的一段时间里，开源、大数据、云等确实对甲骨文产生了一定的影响，但后者加快了迭代更新的速度。可以说，甲骨文现在是一位“全能型”选手。在各个领域都表现不错，甚至在一定程度上，使用Oracle进行技术选型基本可以满足功能需求。但也正是这种现象，导致了选择O的困难。很难找到一款产品可以完美替代Oracle所有的产品能力。因此，de-O的过程往往不是一个简单的“苹果换橘子”的问题，而是需要综合考虑应用架构、基础设施架构、数据库架构，进而造成更大的困难。举一个简单的例子，MySQL在很多情况下被用作Oracle的替代品。但是在实际使用中，会发现很多问题。排除底层内核的差异，两者在携带的数据大小上的差异是非常大的。当数据量变大，容量和性能问题暴露出来，就不得不考虑使用分库分表等方案来解决，但这必然带来应用架构的调整。应用通过中间件的改造和引入解决了这个问题后，会发现数据分片后的整体分析变得困难。这时候就需要引入分析产品，解决数据同步等问题。可见，一个看似简单的底层数据库技术选型的变化，变得越来越复杂。如果上述过程是在“在线”状态下完成的，这个过程会更加困难。综上所述，可以看出Oracle全面而强大的功能是在走向O的过程中不得不面对的问题。应对策略：在应对策略上，我们首先要接受功能差异客观存在的事实。没有完美的产品可以替代Oracle。此时可以做的是细化场景分析，找出更适合项目情况的技术方案（或方案组合）。场景提炼的目的是减去功能需求，找出替换功能的边界，为后续选型提供参考。如果你是O重度用户，你需要梳理所有的场景，提出几种差异化的技术方案来满足不同的需求。即使是同一个场景，也有多种方案可供选择，以面对成本、风险等其他因素的考量。比如下图是公司多年前组织的de-O计划的总结，场景部分就是基于以上的考虑。2.难点：性能差异性能问题可以说是数据库使用最关心的问题，在很多评测中也经常被引用，但这需要理性看待。性能指标与工作量、软硬件环境、测试方法、验收指标等诸多因素有关。很多数据库在评测中都说性能碾压Oracle，所以我们要辩证地看待。比如上一阶段，国内数据库厂商OceanBase在TPCC评测中再次刷新了此前的成绩。可以说各项性能指标遥遥领先。这确实是国内厂商的一大进步，值得表扬；但同时也要理性对待，性能排名不能完全代表好的性能。客户更关心通用场景下的性能和持续稳定输出。基于这两点，甲骨文的产品无疑做的非常好。这里我们主要关注两点，一是Oracle的优化器能力，二是它的软硬件一体机解决方案。如果说数据库是基础软件的皇冠，那么优化器就是皇冠上的明珠。优化器的好坏直接反映了数据库的性能。笔者曾有过这样的经历。一个项目迁移到O总共用了三天时间（包括应用改造等），上线后却花了整整一个月的时间进行优化，甚至还得重写很多代码。出现这个问题的原因是优化器的不同导致同一条语句在不同的数据库中性能差异巨大。通俗地说，写得不好的SQL在Oracle中执行得很好。第二点是软硬件一体化。在这方面，甲骨文走在了各个厂商的前列。它是第一个提出一体机概念的人。经过十余年的迭代发展，其综合性能令人瞩目。它将最新的硬件技术与数据库软件相结合，产生强大的能量。可以说在极限性能场景下，一体机还是非常不错的选择。应对策略：如何应对绩效差异？企业应做到：一是理性看待绩效指标，提出与其相适应的绩效要求。过高的指标要求只会导致后续的技术选择出现偏差。比单一指标更重要的是绩效指标的多维性。需要根据场景提出自己的索引规范，是满足低延迟还是高吞吐量；是满足高并发还是稳态输出。针对这些，应该提出一个综合性的测试标准。二是构建适合企业自身的测试集。TPCC等测试标准可以借鉴，但不要完全依赖，而是从更贴近企业业务的测试集入手，构建自己的测试集。三是着眼长远发展，做好前瞻性绩效评价。产品性能存在所谓拐点现象，难以实现完全线性扩展。需要在评估的前期就关注这一点，根据业务发展情况做出预测评估和可能的备选方案。第四，注意新技术的权衡。很多新技术确实给人一种眼前一亮的感觉，比如性能非常好，但是这个时候，我们要理性地关注它们背后的取舍，进而评估是否选择以及可能的解决方案。比如以Redis为代表的KV产品，在某些场景下表现不错，但背后丢弃的是什么？适合什么场景？后端架构如何适配这项技术？同时，避免其他可能出现的问题？3.难度：生态完整性Oracle的生态无疑是其成功的主要因素之一。在过去40到50年的发展过程中，它在多个领域引领了整个行业的发展，其产品实现方式在很大程度上成为了事实上的标准。很多后来的公司在产品设计上也参考了甲骨文的做法，使得甲骨文在某种程度上成为了数据库的代名词。伴随着它成熟稳定的生态，也有很多相关的公司，从底层的基础设施厂商，到围绕数据库的备份和监控，到上层的数据建模和治理，再到应用软件的开发，这些公司与Oracle共同发展，共存和共同富裕。例如：甲骨文在传统金融领域深耕多年，服务过大量银行客户。这些银行的业务系统由许多独立软件开发商开发和支持。他们非常习惯使用Oracle作为底层数据的存储和计算基础。这时候更换数据库就不再是简单的更换，而是需要大量的应用。系统改造和适应的过程。其中，需要考虑数据迁移带来的新旧系统共存、应用适配等各种问题。可以说，这方面带来的工作量是整个de-O工作的主体部分，也是最终置换效果能否达到预期的关键。在之前看到的陆金所的分享中，是经过业务梳理、服务化改造、后续迁移、流切换等大量工作，才逐步将数据库从Oracle迁移到MySQL。应对策略：面对Oracle成熟的生态系统，作为企业，我们必须做好充分的准备，认识到上O工作不仅仅是底层的简单更换，必须从各个方面进行准备。后者比前者的工作量更大，而这些“细节”将决定最终的实际效果。所以作为技术提供者，不要仅仅通过构建一个新的生态就试图取代Oracle，而是可以做好两手准备，做好一定的适配Oracle的工作。一方面要尽可能兼容Oracle的生态标准，让周边的生态企业能够以极低的成本进行切换。这也是我目前认为是国货比较薄弱的部分。很多产品号称可以完美兼容Oracle，但实际效果往往大打折扣。第二个方面是做出差异化的表述。一种产品不可能与另一种产品完美兼容，两者之间的差异是必然存在的。重要的是要清楚地向客户传达这种差异，而不是等到上线后才发现两者的行为不同。第三个方面是做好迁移协助，可以通过文档、工具、专家服务等形式为客户提供迁移协助能力。比如阿里的ADAM平台就是一款迁移评测产品，可以方便的评估两者的差异并给出建议，甚至可以实现部分迁移逻辑。这大大减少了客户迁移问题。4.难度：成本不便宜。成本是人们常说的去O可能带来的收益的说法，但这里有一个误解。仅从字面成本所代表的经济投入来看，去O往往是不划算的；尤其是在延伸所涉及的人工成本、时间成本、风险成本和机会成本方面。首先，从经济成本的角度来看，Oracle的资源绑定许可+后期服务收费方式是比较昂贵的；并且在议价方面往往比较强势。很多企业也看到了这一点，所以考虑去O。选择去O，单从经济投资的角度来说，会带来很多投资。这可能包括可能选择其他商业产品（或商业服务）的投入，需要构建新的服务体系带来的人力投入，上下游适配带来的替代和改造的投入等等。从人力成本的角度来看，引入一个或多个新的数据库/大数据产品来替代O需要人力投入；比如分库分表等中间件产品的引入，应用架构和应用开发也是需要人工输入的。如果采用开源产品，企业还需要对开源产品有很好的把控能力，在必要的核心和外围生态工具平台的建设上也需要人力投入。3、从时间成本来看，去O往往有一个长期的过程，需要很长的时间和成本。公司是否有足够的时间来完成这个过程？在快速的业务发展中是否有足够的空间来做？大刀阔斧还是小刀阔斧，这些都关系到公司整体的发展节奏，需要统筹考虑。四个方面的风险成本也是无法回避的问题。任何技术决策都可能带来风险。公司是否对此类风险有足够的认识？是否采取了必要的措施来避免这种风险？而这些措施是否带来了额外的经济、人力、时间成本，甚至新的风险点……（嗯，有点烧脑）应对策略：企业应该如何解决上述成本？这里可以采取的应对策略是对上述列出的可能的成本因素进行全面评估和综合考虑。对于不同的方案，不同的成本投入是有差异的，这也是后期选型时的重要考虑因素之一。此外，还需要从长远和战略的角度考虑这个问题，不能只靠成本说话。需要长期投资的要舍得投资；那些应该纳入企业技术战略决策的，要敢于投入。不要被短期成本收益所左右。5、难点：服务诚信很多公司选择Oracle是因为其良好的服务能力。所谓的“交钥匙”项目让企业更放心的是自己的业务，而不是技术本身。要做到这一点，一方面，Oracle产品已经发展多年，功能完备度已经很高，形成了良好的交付能力；另一方面，完整生态带来的闭环配送，大量服务企业的配送质量得到了很好的保障。相比之下，无论是国产数据库还是开源产品，企业都需要更加重视产品服务。对策：针对这一点，甲方企业应多做把关，选择真正具备交付能力的企业和产品。尤其是一些基于开源产品衍生而来的商业产品，企业是否对内核有足够的控制权尤为关键。此外，还需要考虑其服务体系（流程、标准等）、客户案例等。如果企业选择自研或开源解决方案，则需要构建其成熟的运维体系，这可以参考商业解决方案。针对数据安全、可用性等关键指标，制定必要的规划，定期进行演练。对于乙方而言，提升交付服务能力需要一个过程，必须承认与传统商业数据库厂商多年积累的差距。自觉模仿和构建成熟的服务体系，同时加大对生态伙伴的支持力度，让大家共同参与服务。6、难点：风险可控性风险问题是每个人做O选择时都要面对的问题。作为基础软件，Bug在所难免，但以Oracle为代表的大型商业数据库，经过多年的打磨和积累，可以控制风险。Oracle从最早的物理、逻辑备份恢复，到高可用集群（RAC），再到数据卫士（DataGuard），再到独立备份一体机。经过几十年的发展，实现了多方面的数据保护。这也是之前用户敢于把核心关键业务放在上面的原因之一。在某种程度上，用户可以接受一定的服务降级，但必须严格保证关键数据的安全性和可用性。相比之下，去除O后的方案也需要规避上述可能存在的风险。对策：为解决上述问题，甲方需要遵循严谨的原则，将所有可能的风险因素纳入评估，对备选方案进行检验。同时，在推进过程中，可以按照“先边缘，后核心；先局部，后整体”的原则推进工作。在这个过程中，整个方案不断完善和打磨。作为乙方的产品，如何打消客户顾虑，让客户放心选择，也是值得探讨的问题。比如支持产品组合，把自己的产品放在后端，通过全只读->读写混合->全可写的步骤逐步替换，降低风险的可能性。比如支持前端路由选择，尽量用一小部分业务流量来验证，逐步扩容等，通过这些手段的使用，逐步提升用户的信心。同时，对于产品本身的质量，也需要严格把关，做好交期和产量。7.最后，您如何理性看待de-O的价值？或者，为什么企业会做出这样的选择？一方面，随着国内外形势的变化，对本土化、自主化、可控性有现实要求。对于一些重点行业和重点领域，政策上有明确要求。另外，企业选择去O更多是出于成本、可扩展性和自身技术战略的考虑。这个时候，企业就需要冷静思考，做出最适合企业自身的选择。从近几年的发展趋势来看，越来越多的企业开始将de-O作为未来的技术发展战略。与此同时，国内多家数据库或云数据库厂商也加入了这股浪潮。这为国内数据库发展带来了新的发展机遇。去O本身并不是目的，未来如何拥有独立使用和开发基础软件的能力才是关键。大势是乘风破浪；希望更多的企业在去O的过程中磨练自己的能力，同时助力开源和国产数据库技术的长远发展。
