去O的话题，可谓由来已久。从十年前阿里提出了这一口号，并率先在公司内部实现了数据库的总体去O开始，到后面从互联网公司到传统企业也纷纷跟进，能够说去O的理念已逐步深刻人心。但到直到如今，咱们能够看到Oracle在国内的市场依然占有至关大的比例。即便在对外的不少去O宣传中，也大可能是以非重度O记案例或非关键业务系统居多，大量核心、关键业务系统仍然采用O的方案。那形成这一现象的缘由是什么呢？本文尝试对去O可能存在的难点及应对策略加以分析。下面文字表明我的观点，仅供参考。
前端
1. 难点：功能完备度数据库
Oracle从上世纪七十年来发展而来，通过4、五十年的发展，其功能的完备程度达到至关高的水平。能够说，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的生态，无疑是其成功的主要因素之一。其发展的4、五十年来，在不少领域是其引领了整个行业的发展，其产品实现方式，很大程度上也成为了事实标准。后续的不少企业在产品设计上，也参考了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中磨练自身能力，同时助力开源、国产数据库技术长远发展。
韩锋频道：
关注技术、管理、随想。
长按扫码可关注
本文分享自微信公众号 - 韩锋频道（hanfeng_channel）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。