ORACLE 23AI的新特性，看数据库可能前进的方向

关于选择未来

2024年的ORACLE，在国内早就不是当仍不让的唯一选择，甚至谈不上首选。不过ORACLE刚刚发布了新的版本名字叫AI，称提供300余新特性，还是引起了我的兴趣。这是一个百花齐放的时代。国内外茫茫多的数据库产品。最近的几次技术交流，能清晰的感受到，在选百花中选哪一朵，是一件令人纠结的事情。你觉得看好哪一个数据库产品未来？这可不是一个好回答的问题。不过我们可以换一个视角来思考一下这个问题，未来的数据库可能是什么样的呢？要说目前哪个产品最有可能引领数据库行业发展的未来，在2024年的眼下，ORACLE新版本的特性，还是极具有参考性的。

关于新的改变

ORACLE的BLOG上说，ORACLE 23AI的新特性集中在三个方面
AI for Data
Dev for Data
Mission Critical for Data

关于这个AI能力，乍看之下，很容易理解为ORACLE为跟上当前的AI热潮，直接选择加入向量数据库和AI的大军之中。为用户提供向量查询和向量搜索的能力。一开始我也是这么理解。直到我昨晚和一个老同学（现美国某知名数据库大厂原厂大佬）闲聊时，我好像又重新体会了一下这个新特性。大致是我问老同学怎么看ORACLE的新版本AI进入的向量查询。然后他告诉我他们也跟进。这本来不是什么特别稀奇事情。但是另外惊讶的是，他告诉我，他们是选择了和另一家数据库厂商合作开发向量数据库。这似乎也没什么值得惊讶的。然而，这个另一家数据库厂商，恰恰是我们某个头部的国产数据库厂商，正式让诸位纠结的百花中的一朵。（恕我不能点名表扬，但是不得不说还是很赞的）。然后，我们简单的聊了一下，向量数据库的实现和使用是什么样子。说至关键处，我好像突然想明白了什么。我说这个方式，听起来跟ORACLE的路子是一样。

这似乎好像是胡扯，因为ORACLE的BLOG里并没有说它怎么实现。但是先说结论，因为在聊到向量数据库实现机制那一刻，我内心中，已经把这个新特性，划归到了ORACLE之前提出的融合数据库概念的一个衍生或扩展之一。

时间回到2019年，我记得那一年我去参加了ORACLE的全球云大会。在那次大会前一天，因为一众ORACLE的专家都出现在了上海。乘这个机会，ORACLE请来了当时管研发的大神HUWEI先生跟我们作了一下午的交流。那一次聊起ORACLE正在把当时炙手可热的REDIS等一些数据库，全都融入到ORACLE一个数据库产品里面，来应对使用各种各样数据的便利性，而不是在系统里面做很多各种各样的数据库。我记得当时我提的最后一个问题，如何在同一个存储引擎里面去支持各种各样的数据，并且还能高效的查询它，似乎是个难点。最后，数据冗余成多种结构存储应对不同使用和查询是这个问题的答案。第二天，ORACLE的云大会上花了极大的篇幅介绍了融合数据库的方案。

这个记忆五年来并未被唤起，直到我们聊起向量数据库，是由外向内准实时给向量数据库提供数据，并且向量化之后存储，再在这份数据上来提供向量查询时，我又想起了这一段内容。因为老同学说出来的向量数据库的实现方式和那时候ORACLE方案简直就是如出一辙。

不一定没有一个应用都有生成式AI的使用场景，向量数据库也未必能在未来去取代关系型的地位。但是多样化的数据存储、查询需求却是显而易见。融合的理念，使得数据库产品具有更加广阔的兼容性和灵活性。尤其是要成为一个各行各业都可以使用的数据库产品。融合能使之能够适应更多的场景取得更多的市场。在一些重点和热点出现时，就不容易踏空。就假如未来真的走到了一个万物AI的时代，那ORACLE又一次占到了有利的历史位置上。

关于数据开发
文章里有一段描述
Oracle Database 23ai focus was to make the experience of developing applications simpler by removing the complexity associated with your database interaction. Removing complexity from the application development process means you get more opportunities to focus on the intricacies of creating elegant applications that meet your customer’s requirements rather than getting bogged down in technical details. Moreover, reducing complexity can lead to faster development cycles, this is crucial in today’s fast-paced digital landscape, where market demands can shift rapidly.
其实就是在一件事情，提高用户的易用性。

在我们的视角看来，ORACLE产品一直是优秀而傲慢的存在，俯视一切。即便如此，它面对开发者却总能保持足够的谦卑。意思就是，你把复杂和困难交给我，你关注好的的客户需求，并且把他做好就行了。

而我们总是每天听到这样的故事。那些面对百花齐放的产品的开发者，他们自然而然的会用这些产品去和ORACLE对标，很多对标后失望的点其实都是可以回归到易用性上面。比如：
1.你写了一个看起来很荒谬的SQL，但是非常不可思议的是，这个SQL在ORACLE上竟然跑得还不错。很不幸当你迁移了数据库产品之后，发现这条SQL里所应当的炸裂了。你承认这个SQL很烂，但是你不死心，于是你大声的质问厂商，为什么这SQL在ORACLE上能跑，换你们就不行了。
2.又比如你的数据库出了一个问题，你曾经并不懂数据库里面那些弯弯绕绕，你拿着错误码和AWR报告在网上一通搜索就解决了问题。然而你换了产品之后，不仅报的错你看不懂，即使找来原厂的工程狮，你发现他们靠猜靠蒙，在一堆你搞不明白的日志里，搞出一个你搞不明白结论。
从另一个维度来理解是，优秀的数据库产品，需要降低使用者用好它的门槛。而非绝大部分开发者都需要去达到一个专家级的水平。ORACLE的用户享受了很长时间的这种易用性（大约11G版本开始吧），并且久而久之，这些用户认为这件事情里所应当存在的。

另外，这一条的举例里面，先后列出了，JSON和图数据库的使用案例。这一条又和上一条绕回前一条去了。为什么要融合数据库，因为使得使用者更加方便。怎么样才能用起来方面呢？ORACLE把复杂的东西屏蔽在产品里面，开发者用ORACLE就能获得方便。

关于关键任务数据
在这一条下面，ORACLE写下了全球分布式和RAFT协议相关的内容。我理解他大约想说的应该是数据库的高可用的事情。从源生分布式概念出现，到基于PAXOS协议或者RAFT协议的数据库产品越来越多。这种源生分布式数据库产品，确实在跨地区级别的数据分片和均衡，以及高可用方面上，有它非常天生的优势在。于是ORACLE认可了这个优点，并吸取这个优点。
第二条是关于缓存问题，这就是在说，用REDIS不如用融合了REDIS缓存能力的ORACLE吗？所有用过缓存的系统，几乎都面临过，缓存和数据库数据的一致性保障问题。这里ORACLE 的TURE CACHE前移到了AP测，减少了网络代价同时保证准确。我想这也是为什么它会出现在这一条下面的原因。但是，归根不又回到了融合数据库上面去了吗。
最后一个例子看起来像是一个SQL粒度的权限管控能力。

写在最后

我想大约整个思路是非常清楚的。数据库产品要很通用，要使用面广的化，它把自己设计的比较复杂可能是必然的。但是这种负责永远是对开发者透明的。降低使用门槛，让普通的开发者，也能很容易用好数据库产品。