业务向前，数据库向后

在上周末，外出参加数据库综艺（这个是首席的旧词新读，指的是在工作以外的一些数据库行业或厂商的重量级会议）之前，和移动客户深入聊了一下数据库国产化进程中的一些问题与感触，本篇做了一个小小的总结与发散。

1 CRUD

我这边在过去的2年中还是经历了很多国产数据库的试点工作，其中一些是整体统筹的，有些是业务自测的，但是给客户的直接感触就是，绝大多数国产数据库连最基本的CRUD都没有实现好，这里说的不是说这些数据库没有CRUD的功能，而是无法满足客户业务场景对性能、稳定性的需求（还可以先不谈兼容性和高可用性）。

一些源自于低负载管理类系统的案例，根本没法在负载稍微大一点、业务逻辑稍微复杂点的应用场景中复用落地，至少是需要经历较多数据库与业务代码层面的优化甚至是业务拆分才能达到预期需求的，或者是针对国产数据库的特性重构或新建业务系统。

所以对于客户来说使用国产数据库带来了以下额外成本：

1. 应用代码改造

2. 业务逻辑改造

3. 研发难度提升

4. 服务器用量上升

5. 维护压力提升

2 融合向前

对于客户来说，业务场景是在不断发展的，以最近几年流行的AI大模型为例，客户非常希望AI能够赋能于业务场景之中并带来收益。从数据库层面来看，就是要能够存储AI向量数据同时能够与原有结构或非结构化数据进行混合查询，以更加快速的方式获取更精准的结果，这样就需要数据库实现多模融合。当然也可以使用多种专用数据库构建一个较为复杂的数据库体系来支撑，只不过这也需要更多的技术投入并解决数据交互带来的精度、复杂度、传输等问题。

多模融合是已经在多款国外商业与开源数据库中实现了的功能，能给客户带来更加统一的数据库管理与使用体验，简化业务开发难度，提升数据流转与交互效率，降低维护难度与复杂度同时不少的业务之中也有落地。但是纵观当前的国产数据库，提供的功能特性相对单一且独立，一些已经有多模融合的特性的数据库但功能支持也不是太好、BUG多也没有落地。

对于客户来说，业务在不断向前发展，但是似乎，数据库的国产化却是在向另一个方向“拖后腿”，而且这个差距在短时间内是无法缩短还可能越拉越大的，这也从另一个方面让客户需要在数据层面增加更多的投入来尽可能弥合这个差距带来的问题。

3 屎山代码

在很多场合中，都听到过一些数据库从业者对Oracle的不屑，特别是对其代码量的吐槽，称其为屎山代码，又臭又长又多。但是我认为在一个优秀产品中的海量代码并不一定是累赘，举个白鳝老师提的例子，在去年PAB之后，白鳝老师单独和Oracle产品经理讨论了关于SQL执行计划变化后管理、告警的相关需求，然后Oracle在很短的时间在基于SPM的基础上完成了Real-time SQL Plan Management的新版特性，并在白鳝老师建议的基础上做到了更多的扩展，实现过程简洁而优雅。这是不是从另一个角度来看，一个管理得当的“屎山代码”，不是累赘，而是长时间业务支撑中的经验与积累，这是一笔宝贵的财富，对其进行良好的梳理，做好迭代控制，完成代码量与功能之间的平衡，才是一个优秀的系统工程产品需要做到的。

反观为什么有些人不喜欢代码多的数据库产品，一方面可能就是单纯觉得占太多空间了，另一方面可能是认为实现一些功能不需要这么多代码，当然我觉得最根本的原因还是接触的业务场景太少，压根没有那么多积累的机会。

总结

随着数据库国产化进程逐渐进入深水区，暴露出来的问题也越来越多，数据库是一个用出来的产品，需要足够的场景打磨，所以也希望大家给国产数据库更多的包容、理解与支持，在各方面做好权衡利弊。