企业“去O”六大难点及应对策略.docxVIP

?

?

企业“去O”六大难点及应对策略

?

去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是走在各厂商的前列，其最早提出一体机的理念，经过十余年的迭代发展，其综合性能表现令人印象深刻。其将最新的硬件技术，与数据库软件相结合，爆发出强大能量。可以说在极致性能表现场景下，一体机仍然是非常好的一种选择。

应对策略

如何面对性能的差异呢？企业要做到以下几点：一是理性看待性能指标，提出适合自己的性能要求。过高的指标要求，只会带来后面技术选型的偏差。比单一指标更为重要的是，性能指标的多维度。要结合场景提出自己