标准是什么？USB3.0是标准，USBTYPE-C是标准，X86架构是标准，安卓手机操作系统也是标准。所以，标准是强者制定的规则，是其他追随者所仰望的目标。在数据库中，MySQL协议是标准的，因为MySQL是其他数据库所仰赖的。近年来，几乎所有新的数据库系统都以兼容MySQL协议为卖点。比如TDSQL、Aurora、MyRocks、OceanBase、PolarDB、GoldenDB、TiDB等数据库，对于业务来说，几乎不需要做任何改动，开发者可以快速适应原有的MySQL研发流程，甚至一些以前的MySQL数据库框架都是可以直接Multiplexing的，比如数据库连接池，数据库代理等，不仅在技术领域，这种向上兼容的操作其实很常见。其他领域也有操作，但这种方式叫做“蹭流量”。利用大V的流量和热点新闻的流量。一句话，弱肉强食。不过，令人意外的是，在最近的OracleCloudWorld大会上，Oracle23c版本引入了对MongoDBAPI的兼容。简单的说，就是可以通过原有的MongoDBAPI访问Oracle数据库，也就是把Oracle数据库当成文档数据库来使用。正如我们之前所说，兼容是弱者对强者的钦佩。世界上最强大的数据库Oracle兼容MongoDB数据库，这是一个划时代的标志。从此，甲骨文数据库走下神坛，进入了全面没落的时期。我知道很多O迷不愿意接受这个事实。然而，这样的事情在历史上一再发生。最近，它是IBMDB2。那一年，DB2推出了MySQL存储引擎插件IBMDB2I，可以访问DB2数据库。然而，这一操作非但没有帮助DB2数据库扩大市场份额，反而加速了DB2数据库的快速下滑。从DB-Engines的趋势图可以发现，PostgreSQL、MongoDB、Redis、Elasticsearch都已经超越了IBMDB2数据库，更不用说处于数据库第一梯队的Oracle、MySQL、MicrosoftSQLServer数据库了。越相配，下降的越快。最后，我们再分析一下，OracleMongoDBAPI是不是一个好的产品设计？显然，OracleDatabase的出发点是抢占MongoDB的文档数据库市场份额。出发点是好的，但现实是很残酷的。从技术上分析，文档数据库一点都不复杂，就是1个id主键+1个JSON列。MongoDB的NoSQL其实不太好用，分布式sharding功能在实际生产中用的不多。近年来，Oracle、MySQL和MicrosoftSQLServer数据库也提供了对JSON列类型的支持。从逻辑上讲，可以围绕这些数据库创建文档存储体验。MySQL甚至提供了一个新的NoSQLAPI接口和文档数据库解决方案InnoDBCluster，与MongoDB的体验几乎相同。即使使用InnoDB存储引擎的强大特性，也有数据事务保证。然而，这些数据库都无法挑战MongoDB在文档数据存储领域的地位。因此，即使这次Oracle数据库支持原生的MongoDBAPI，也不会有太大的变化。如果只有一个MongoDBAPI可以吸引客户迁移，那么MySQL和MicrosoftSQLServer也可以做到，而且我相信他们的要价肯定会低于Oracle。回过头来看，甲骨文早年的收购战略还是比较成功的。最经典的案例就是收购了InnoDB存储引擎的母公司Innobase，然后完成对Sun的收购，从而完成了对MySQL数据库的完全控制。Larry一直觊觎的是正在崛起的MySQL数据库，而不是落日的Sun。不过，在过去的10年里，甲骨文的战略收购并不算太成功。相反，甲骨文错失了整个云数据库红利时代。业界领先的分布式数据库架构、存储计算分离的云原生数据库架构、Oracle数据库不再是行业领导者。一些我们引以为豪的数据库能力，比如MVCC、OLAP能力、开源数据库也做得很好。此外，不仅中国开始不断推进“去”甲骨文数据库的工作，许多国外企业也因为高昂的许可费用或其他相关问题，逐渐减少使用甲骨文数据库。很难想象，一夜之间，全世界都“转向”了Oracle数据库。但甲骨文真的无牌可玩了吗？其实并不是。甲骨文还有一对王炸，那就是MySQL数据库。但如果加大对MySQL的支持和投入，将对原有的Oracle数据库商业市场造成严重冲击。有没有像微软CEO拉德纳那样的勇气，全面拥抱开源和云时代？这是对新时代商业领袖的最大考验。算一下，拉里已经78岁了。英雄迟暮，当下青春。多于。
