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