企业去O六大难点及应对策略.docx

《企业去O六大难点及应对策略.docx》由会员分享，可在线阅读，更多相关《企业去O六大难点及应对策略.docx（9页珍藏版）》请在第一文库网上搜索。

1、企业“去0”六大难点及应对策略去0的话题，可谓由来已久。从十年前阿里提出了这一口号，并率先在公司内部实现了数据库的整体去0开始，到后面从互联网公司到传统企业也纷纷跟进，可以说去0的理念已逐步深入人心。但到直到现在，我们可以看到Orac1e在国内的市场依然占有相当大的比例。即使在对外的很多去0宣传中，也大多是以非重度0记案例或非关键业务系统居多，大量核心、关键业务系统仍然采用0的方案。那造成这一现象的原因是什么呢？本文尝试对去0可能存在的难点及应对策略加以分析。下面文字代表个人观点，仅供参考。1 .难点：功能完备度Orac1e从上世纪七十年来发展而来，经过四、五十年的发展，其功能的完备程度达到相

2、当高的水平。可以说，Orac1e仍然是数据库业内功能最为强大的一款产品。从早期关系模型的实现、率先提出集群理念、到引入多模异构存储、软硬件一体化、人工智能在数据库的应用等等。Orac1e在产品能力上不断增强。在本世纪早期的一段时间内，开源、大数据、云等确实对Orac1e造成了一定的冲击，但后者加速迭代更新速度，可以说现在Orac1e更是一个“全能”选手。在各个领域，均有着不俗的表现，甚至从某种程度来讲，技术选型采用Orac1e基本都可以满足功能需要。但也正是这一现象，造成去0的选择是困难的，很难找到一款产品可以完美替代Orac1e的全部产品能力。所以，去0的过程往往不是一个简单的“苹果换桔子”

3、的问题，而是需要从应用架构、基础架构、数据库架构综合考虑，进而造成较大的困难。举个简单的例子，很多案例中是采用MySQ1作为Orac1e的替代方案。但在真正使用中，会发现很多问题。排除底层的内核差异等外，仅从承载数据规模来看，两者的差异就很大。当数据量增大后，容量、性能问题暴露出来，你不得不去考虑使用类似分库分表等方案来解决，但这势必会带来应用架构的调整。在应用通过改造、引入中间件等解决这一问题后，又会发现数据分片后的整体分析变得困难，此时又需要引入分析类产品，还要解决数据同步等问题。可以看到一个看似简单的底层数据库技术选型的改变，变得越来越复杂。如果上述过程是在“在线”的状态下完成，这个过程

4、又将难上加难。综上可见，Orac1e全面而强大的功能，是在去0中不得不去面对的问题。应对策略在应对策略上，首先要接受这一事实，功能差异是客观存在的。不存在一个完美的产品可以替代OraCIe。此时能做的更多是细化场景分析，找出更适合项目情况的技术方案（或方案组合）。细化场景的目的，就是在于对功能需求做减法，找出替换功能边界，进而为后面的选型提供参考依据。如果是一个重度0的用户，就需要梳理所有场景，提出若干种差异化的技术方案来满足不同的需要。甚至针对同一场景，也要有几种方案可选，以面对成本、风险等其他因素的考虑。例如下图是多年前在公司整理的去O方案总结，其中场景部分正是基2 于上面的考虑。3 .难

5、点：性能有差异性能问题，可以说是数据库使用中大家最为关注的，也是在很多评测中经常拿来说事的，但这点是需要理性来看待的。性能指标，是受到工作负载(work1oad).软硬件环境、测试方法、验收指标等很多种因素有关。很多数据库在评测中谈到性能碾压OraCIe,此时要辩证来看待。例如前一阶段国内数据库厂商OCeanBase,在TPeC的评测中再次刷新了此前成绩，可以说性能指标遥遥领先，这点也确实看到国内厂商取得了长足的进步，值得夸奖；但同时也要理性看待，性能打榜成绩不能完全代表性能好。客户更为关注的是在通用场景下的性能表现及性能上持续稳定输出。基于这两点，OraCIe产品无疑做的非常出色。这里面重点

6、谈到两点，一是OraC1e的优化器能力，二是其软硬一体机方案。如果说数据库是基础软件的皇冠的话，那么优化器就是皇冠上的明珠。优化器的好坏，直接反映数据库的性能表现。笔者之前曾有过这样的体验，某项目去O迁移（包括应用改造等）总共花费三天时间，但上线后的优化足足花了一个月，甚至很多代码不得不重写。造成这一问题的原因，正是优化器的差异造成同样语句，在不同数据库的表现差异巨大。通俗来说，就是写的很烂的SQ1,在Orae1e中也可以执行得很好。第二点是软硬一体化方案，这方面Orae1e是走在各厂商的前列，其最早提出一体机的理念，经过十余年的迭代发展，其综合性能表现令人印象深刻。其将最新的硬件技术，与数据

7、库软件相结合，爆发出强大能量。可以说在极致性能表现场景下，一体机仍然是非常好的一种选择。应对策略如何面对性能的差异呢？企业要做到以下几点：一是理性看待性能指标，提出适合自己的性能要求。过高的指标要求，只会带来后面技术选型的偏差。比单一指标更为重要的是，性能指标的多维度。要结合场景提出自己的指标规范，是满足低延迟，还是满足大吞吐；是满足高并发，还是满足稳态输出。针对这些，要提出一个综合性的测试标准。二是构建适合企业自身的测试集，TPeC等测试标准可以用来参考，但不要完全依赖而是从更贴近企业业务入手，构建自有的测试集。三是关注长期发展，做有预测性的性能评估。产品的性能表现是存在所谓拐点现象，很难做

8、到完全线性扩展，要在评估初期就关注到这点，并根据业务发展做好预测评估及可能的备选方案。四是注意新技术的tradeoffo很多新技术确实给人眼前一亮的感觉，例如性能表现非常好，但此时要理性注意到其背后的取舍问题，进而评估是否选择及可能的解决方案。例如以RediS为代表的KV产品，在某些场景有很好的性能表现，但它的背后是舍弃了什么？什么场景适合它？后端架构如何适配这一技术，在解决了性能问题的同时，避免其他可能带来的问题？4 .难点：生态完整性OraCIe的生态，无疑是其成功的主要因素之一。其发展的四、五十年来，在很多领域是其引领了整个行业的发展，其产品实现方式，很大程度上也成为了事实标准。后续的很

9、多企业在产品设计上，也参考了OraeIe的做法，某种程度将OraCIe成了数据库的代名词。伴随着其成熟稳定的生态，也有很多相关企业，从底层基础设施厂商、到数据库周边的备份、监控，到上层的数据建模、治理，再到应用软件开发，这些企业伴随着OraC1e共同发展，共存共荣。例如：OraC1e在传统金融领域布局多年，服务了大量银行客户。而这些银行的业务系统，则是有很多ISV来开发支持，他们已经非常习惯使用OraCIe作为底层数据的存储、计算基础，此时更换数据库已不是简单的一替了之，而是需要大量的应用系统改造适配的过程。这其中还需要考虑新老系统的共存、数据迁移带来的应用适配等种种问题。可以说这方面带来的工

10、作量，是整个去。工作中的主体部分，也是关乎到其最终替换效果能否达到预期的关键。此前看到的陆金所的分享，正是在业务梳理、服务化改造到后面迁移、切流等做了大量工作后，才逐步将数据库从Orac1e迁移到MySQ1上。应对策略面对OraC1e成熟的生态，作为企业要做好充分的准备，认识到去0工作不是简单的底层替换而已，要从方方面面着手准备。后者所占的工作比例，甚至超过前者，而这些“细节”会决定最终的实际效果。那么作为技术提供方来说，不要试图仅仅通过全新建立生态来替代OraCIe,而是可做两手准备，做好一定的适配OraCIe的工作。一方面，要尽量兼容OraCIe的生态标准，方便其周边生态企业可以非常低成本

11、的切换过来。这也是我目前认为国内产品做的相对薄弱的部分，很多产品都号称可完美地兼容OraC1e,是实际效果往往大打折扣。第二方面是做好差异化声明。一个产品要完美地兼容另一款产品是不可能的，双方的差异势必存在。重要的是，将这个差异明确地传达给客户，不要等上线后才发现两者的行为不同。第三方面是做好迁移辅助工作，可通过文档、工具、专家服务等形式，提供给客户迁移辅助能力。比如阿里的ADAM平台，就是一款迁移评估产品，可以很方便地评估两者的差异并给出建议、甚至是部分迁移逻辑的实现。这样可大大减少客户迁移的忧虑。5 .难点：成本不便宜成本，是大家经常来谈到去0可能带来收益的一个说辞，但这里是有一个误区的。

12、仅仅从字面成本代表的经济投入来说，去0往往就是不划算的；再从外延所涉及的人力成本、时间成本、风险成本、机会成本来说，更是如此。先从经济成本来看，OraC1e采取的绑定资源的许可证+后期服务费的方式，是比较昂贵的；而且往往在议价方面也是比较强势。很多企业也是看到这一点，因而才考虑去0的。 选择了去0,仅从经济投入角度也会带来很大一笔投入。这里面可能包括选择其他商业产品（或商业服务）可能的投入，需构建新的服务体系带来的人力投入，上下游适配带来的更换类、改造类的投入等等。 再从人力成本来看，引入一款或多款新的数据库/大数据类产品来替代0,需要人力投入；如引入例如分库分表等中间件产品，在应用架构上、应

13、用开发上也是需要人力投入的。如采用的是开源产品，还需要企业有很好的掌控开源产品能力，在必要内核上及构建周边生态工具平台上同样需要人力投入。 三从时间成本来看，去0往往有个周期较长的过程，是需要花费较长的时间成本。企业是否有足够的时间来完成这一过程？是否在快速业务发展中，有足够的空间来做？是采取大刀阔斧还是小步快跑的方式，这些都是与企业整体发展节奏相关，需要统筹来考虑。 四方面的风险成本，也是不可回避的一个问题。做任何技术决策都可能带来风险，针对这样的风险企业是否有足够的认知？为规避这一风险，是否采取了必要的措施？而这些措施，是否又带来了额外的经济、人力、时间成本，甚至新的风险点（好吧，有点烧脑

14、）应对策略面对上述种种成本，企业该如何来解决呢？这里能采取的应对策略就是充分评估，将上述可能的成本因素都罗列出来。针对不同的解决方案，在不同成本投入上有所差异，这也是后面做选型时的重要考量因素之一。此外，还需要从长远及战略层面考虑这一问题，不要仅依靠成本说话。该需要长期投入的，要舍得投入；该纳入企业技术战略决策的，要敢于投入。不要被短时的成本收益所左右。5 .难点：服务健全性很多企业选择OraC1e,是看中其良好的服务能力。所谓的“交钥匙”项目，让企业可以更安心在自身业务上，而不是技术本身。能够达成这点，一方面是OraC1e产品本身发展多年，其功能完备度已经很高，并已形成了很好的交付能力；第二

15、方面，完备的生态带来的交付闭环，大量的服务类企业保证了很好的交付质量。相比较而言，无论是国产数据库或者开源产品，都需要企业在产品服务上面有更多的关注。应对策略针对这点，作为甲方的企业要更多做好选择把关工作，选择那些真正有实力交付的企业及产品。特别是某些基于开源产品衍生而言的商业产品，企业是否对内核有足够的把控力，尤为关键。此外，在其服务体系（流程、标准等）、客户案例等，都需要加以考虑。如果是企业选择自研或开源方案解决，则需要构建其成熟的运维体系，这点可参照商业解决方案。对涉及数据安全、可用性等关键指标，做好必要的预案并定期演练。而作为乙方来说，提升交付服务能力是需要一个过程，要承认与传统商业数

16、据库厂商服务积累多年的差距。有意识地去模仿构建成熟的服务体系，同时加大对生态合作伙伴的支持，让大家共同参与到服务中来。6 .难点：风险可控度风险问题，是大家做去O选择时不得不面对的问题。作为基础软件，出现bug是难以避免的，但以OraC1e为代表的大型商业数据库，经过多年的打磨积累已经可以做到风险可控。OraCIe从最早物理逻辑的备份恢复、到高可用集群(RAC),到数据卫士(DataGuard),再到独立的备份一体机。经历了数十年的发展，在多方面做到数据保障。这也是之前用户，敢于将核心、关键业务放在上面的原因之一。某种程度上讲，用户可以接受一定的服务降级，但在关键的数据安全、可用性上面，是需要严格得到保障的。与之相对比，去0之后的方案同样需要规避上述可能的风险。应对策略为解决上述问题，甲方企业需要本着严谨的原则，将可能的风险因素都纳入到评测之后，以此来考察候选方案。同时，在推进过程中可以按照“先边缘、后核心；先局部、后整体”的原则