数据库管理-第261期 什么是多模融合（20241112）

数据库管理-第261期 什么是多模融合（20241112）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、年度墨力之星，ITPUB认证专家、专家百人团成员，数盟会长老会成员，OCM讲师，PolarDB开源社区技术顾问，HaloDB外聘技术顾问，OceanBase观察团成员，青学会MOP技术社区（青年数据库学习互助会）技术顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

书接上回，这几周比较密集的参加了多场数据库综艺，有一个很明显的趋势，即大多数国产数据库都在朝着多模融合的方向发展，这里限定一下，主要指的是数据库支持多种类型数据的存取，包括但不限于传统关系型数据、JSON文档数据、XML数据、GIS数据、图数据、时序数据以及AI向量数据等。

1 数据使用需要结合

数据的融合运用，或者说数据库支持多种类型数据的混合查询是未来数据应用的大势所趋，为什么这么说呢，首先非精确匹配的数据（尤以AI向量数据为主）要尽可能提高查询结果的准确度，是一定会与标量数据进行关联的，假设我们使用一个专用关系型数据库和专用向量数据库来解决问题，那么我们首先需要现在向量数据库中进行近似查询，这时候由于没有附加的过滤条件，在向量数据库中我们往往需要消耗更多的资源得到不那么精准的数据集，然后再去关系型数据库中匹配标量数据（也可以反过来，先关系后向量，但是很可能获取不到最接近的向量数据），这个2步走的查询流程本身就比较复杂，假设如果还有JSON数据并使用专用的文档数据库那么查询将更加复杂，不仅消耗各个数据库的本地资源，也会大量消耗网络资源。这时我们还需要考虑在不同的查询条件下，是先以关系型数据过滤还是以JSON数据过滤抑或是向量数据过滤，再考虑剩下两种数据的过滤顺序以达到匹配精确度和较好的查询性能与较低的资源消耗之间的平衡。

2 国产数据库是怎么做的

最近沟通过或了解过的已经做了部分多模融合或者计划做多模融合的数据库厂商，在近期给出的方案大多都是将一种类型数据的专用数据库以组件或存储引擎的方式加入到自己的数据库中，可以通过统一的访问接口（一般是同IP不同端口）实现多种类型数据的存取操作，而各个类型数据的使用方式还是按照之前专用数据库的方式提供，我认为这边并不算是这正的多模融合。
首先，虽然看似多种类型数据都在一个数据库之中，但是数据的使用方式没有显著变化，数据与数据之间仍然是隔离的，不同类型数据底层存储之间并没有打通；其次数据库中融入了更多不统一的组件，增加了数据库本身的维护复杂度，当出现一些问题的时候排查难度也会增加。
因此我还专门和某国产头部分布式数据库厂商的工程师专门吐槽过融入Redis的问题。

3 老大哥是怎么做的

这里的老大哥肯定指的是Oracle，先来一张来自于IDC对23ai（23c）JSON关系二元性视图的赞许：

Oracle的JSON关系二元性也许是20年来信息科学领域最重要的创新之一

对于JSON关系二元性视图不大熟悉的同学可以去翻阅第130、184、185期，这里不做详细介绍了，简单来说就是通过视图声明的方式将关系表的数据以JSON方式输出，对数据的操作可以通过底层表也可以通过视图。类似的数据处理也出现在Oracle Property Graph（属性图）中（详见第186-188期），同时Oracle还将PGQL（Property Graph Query Language）提交至最新的SQL标准之中。

这才是我认为的多模融合，无论是标量数据还是非结构化数据都可以通过SQL进行操作，而不是使用为每一个专用数据库设计的独立语言；统一的底层存储还使得多种类型数据的混合查询简写且可以以极高的精度完成匹配。这简化了数据层的IT架构与应用开发难度，数据操作的统一使得开发者可以专注于创新而不是集成。这即源自于Oracle想到了创新性的多模数据解决方案，也是因为Oracle有足够的技术与经验的积累。

总结

其实本期算是上一篇的延续，我们本就在数据库的基础上有一定差距，追赶多模融合更是难上加难，还是需要磨练与积累。当然正如白鳝老师所说的一样，摸着Oracle过河，何尝不是一个优秀的道路。
老规矩，不知道写了些啥。