第133期 为什么一些场景下Oracle很难被替换掉（20240113）

本文主要是介绍第133期 为什么一些场景下Oracle很难被替换掉（20240113），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

第133期 为什么一些场景下Oracle很难被替换掉（20240113）

今天在薛首席的群里，聊到一些应用场景和数据库的事情，讲到很多国产数据库也在朝All in One的融合方向发展，但是很多数据库连一件事情都还没做好，发展充满了挑战、机遇与矛盾。PostgreSQL中文社区前主席、巨杉数据库产品及运营资深总监萧少聪，萧老师说了一句话“说实话都是Oracle惹的祸，要不是他做的那么牛逼，中国数据库有至于那么难吗。”确实，在某些应用场景或者说叫使用环境下，Oracle数据库是很难被替换的，结合一些以前一些文章（包括被转载的地方）的留言讨论和一些群聊内容。

1 数据量

先保个命，这里不是说分布式数据库不好，但确实最早分布式数据库的出现有一点原因是单机处理性能不够，需要更多的服务器来解决问题，其中很大一个原因就是数据量的增长。而现在在软硬件水平飞速发展的现在（尤其是IO能力），单机的处理能力有了非常显著的提升，现在的瓶颈反而来到了数据库单个实例的处理能力上了，当然Oracle也可以需要通过RAC来扩展多个实例来解决一些场景，但就目前的实践来看，使用Oracle RAC确实用不到分布式数据库那么庞大的服务器规模。
这里又到某些人的观念，一个关系型数据库就不该存放超过10TB的数据，这里拿我服务的运营商来举例，一个省的资源点大大小小加起来会达到几十亿的量级，其中本身描述数据非常复杂（说白了就是行数据量贼大的那种）的资源点也是过亿的，其中的关联关系和资源本身的其他属性，就会带来海量的数据（这里还没有包含所谓的时序数据），对这些数据的使用，其实偏向于OLTP，比如资源点的存活状态、性能状态、上下游关系、告警等等操作，这种杂乱无序的数据的操作，是Oracle（或者说是集中式数据库）擅长的，而单存从海量数据的处理效能和硬件资源利用率来看，目前Oracle还无出其右。
说起数据量，吐槽一下之前看到的留言评论，说数据库使用不占IO资源，其实说出这样观点的人无外乎就几种，没有接触过大规模的系统的、只接触过大系统的部分功能的或者纯纯圈外习惯质疑的…

2 架构

虽然现在我主要服务于运营商，算是传统企业，但是曾几何时也供职工互联网公司（再说了还有那么多互联网公司的大佬朋友可以探讨）。我发现一点，传统企业或者说是传统行业，IT架构往往十分简单，一个或多个中间件服务器加上一套数据库就能解决问题，这里也要说一下Oracle无论在功能还是性能上都能很好的支撑这种架构（PG用好了也可以哈）。
但是很多互联网架构，实现数据的高性能和及时性往往是通过一个比较庞大且复杂的数据中间层实现的，比如Kafka、Redis、ElasticSearch、ClickHouse等等组合出来的，也就是很多地方说的中台架构，这种架构（如果配合上云）的好处就是可以便捷支撑快速扩展的业务，快捷上线新功能，而最终数据库成为了最终记录和兜底的存在。
传统架构和互联网架构没有好坏之分，差的只是应用场景的不同而已，但是有一点，传统企业的IT架构往往只需要几台服务器，而变更为互联网架构（或称为数字化转型），往往就要几十上百台的服务器，同时技术栈的扩展，原来中间件+数据库的开发管理维护现在可能需要近10种技术栈的使用，以前一种数据库就能解决的问题，现在A库查完去B库，B库关联完去C库，最终结果还要去D库关联，不一定每一家传统企业都能接受或者承受这种变化。

3 应用改造

其实这又是一个历史遗留问题，大量存量且高负载的重要核心系统仍然运行在Oracle数据库上，举一些鲜红的例子，不能点名，某些金融行业客户（不是那种贼小的地方）对部分核心系统进行国产化改造，数据库也就1000W左右，但是应用改造破亿了（还超的有点多）。不要去听信那种不需要针对数据库进行应用改造的忽悠，不同数据库单就SQL方言问题都能搞死一大片，更别说不同架构的数据库使用方式是完全不一样的。即使是号称兼容性最好的国产数据库，也需要大量改写来解决很多性能问题（其实最终整体性能还是不达标）。

4 Exadata和融合数据库

还是说那些大量存量且高负载的重要核心系统仍然运行在Oracle数据库上，这类数据库还有一部分还运行在Oracle Exadata一体机上，一体机性能的强大，可以翻翻我以前的文章，一体机的性能会给很多业务研发带来一种幻觉，写个不怎么好的SQL也能跑出那么好的性能（我真牛？那是一体机真牛！放在普通自建环境该跑不出来还是跑不出来）。虽然也有人说国产一体机能不错（同样跑Oracle），但就一点不行，在Exadata上全库可以不建索引，而在国产一体机上都得整上（其实就算是国产化硬件迁移不换数据库，改造量就不少，更别说换数据库了）。
Oracle近几个版本都在推融合数据库，很早以前实现的GIS、Spatial，到后来的Inmemory和JSON数据类型，再到最近Oracle 23c融合了Kafka、JSON二元性、关系型图、全功能高速缓存等等功能，使得可以将传统复杂的数据架构合一到一套数据库，有些融合进来的功能还不用改使用习惯。这对于IT架构简单和团队小的地方，吸引力还是蛮大的。

总结

我认为，数据库的使用，是应用场景与数据库产品的匹配，数据库得适合应用场景，应用也得好好使用、遵循数据库产品的特性。
最后，我是没有自己的微信群，这里推广一下薛首席的微信群，里面数据库圈大佬众多，日常进行技术、非技术讨论，由于群人数已超过200，只能把首席微信二维码贴出来，想入速加：

这篇关于第133期 为什么一些场景下Oracle很难被替换掉（20240113）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---