黄东旭：“向量数据库”还是“向量搜索插件 + SQL 数据库”？

作者： Billmay 表妹原文来源：https://tidb.net/blog/3f52c021

本文由 PingCAP 黄东旭撰写，讨论了数据库技术在 2023 年的快速变革，并对 2024 年的数据库发展趋势进行了预测。文章重点关注了 GenAI 时代对数据库的影响，提出了在数据库选择上的两种路径：“向量数据库”和“向量搜索插件 + SQL 数据库”。文章强调了个性化数据服务的重要性，以及数据库在实时交互和弹性方面所起到的关键作用。

如果我们用一个词来总结 2023 年的数据技术领域，那个词无疑是“急速变革”。我们见证了数据库内核技术与云原生架构的融合演进，AI+Data 的浪潮涌现，以及用户工作负载的深刻转变。GenAI 时代的到来，就像一股不可抗拒的潮流，推动着数据技术的每一朵浪花，朝着更智能化、更灵活化的巨浪之海奔流。

2023 年，我们的眼前充满了夺目的 AI Demo 与炫技，你追我赶。转眼间，当我 们步入 2024 年，这个年份将因为 “AI 在从 Demo 到真实场景落地”的急剧转变而被人们记住。随着开源大模型成本的加速下降，企业和开发者对数据的关注也急剧上升，对数据的关注度将很快取代对模型的关注度。有预测认为，在 2023 年，用户愿意在 AI 模型上投入 80% 的预算，然而在未来这一两年里，随着模型成本的降低，这一比重可能会逆转，用户将更多的投资（甚至大于 80%）倾向于数据，数据处理和分析能力变得更加重要。

毫无疑问，AI 将会对数据处理提出非常多新的诉求，数据技术领域也会面临着多重挑战与机遇，AI 正在重塑数据技术的全新生态。我们不禁要问：在 GenAI 的大潮中，选择 “向量数据库”还是“以 SQL 数据库作为核心，添加向量搜索插件”？数据库如何应对 Gen AI 对数据库扩展性和实时交互的诉求？浪涌般海量数据的实时查询会不会带来巨大的成本压力？AI 带来的自然交互方式催生怎样的开发者体验 ？这些问题将在本文中一一解答

预测一

“向量数据库”还是“向量搜索插件 + SQL 数据库”？这是一个答案很明确的问题。

如果说过去 CRUD 应用是对数据库访问的静态封装，那么随着 GenAI 的普及，尤其是 Chatbot 或 Agent 的产品形态，对数据的使用会是更加灵活和动态的。过去，集中的数据存储和应用是因为技术的局限，很难为个人提供个性化的服务，尽管现代的 SaaS 其实很希望往这个方向发展，但是为每个用户都提供个性化的体验对算力和开发的挑战太高，而 GenAI 和 LLM 将提供个性化服务的成本降得很低（可能就是几段 Prompt），以至于对于数据库而言，带来几个变化：

○ 个人（或一个组织）产生的数据价值会变得越来越高，但这类数据通常不会很大

○ GenAI 会使用更加动态和灵活的方式直接访问数据，这样效率最高

○ 对数据的访问从边缘发起（从 Agent 或者 GenAI 直接发起）

一个很好的例子是 GPTs， GPTs 支持通过的自定义的 Prompt 和用户提供的 RESTful API 来创建自己的 ChatGPT，基础的 ChatGPT 会在它认为需要的时候以灵活的方式调用你给定的 Action。这个调用发生方式和参数是后端的 Action 提供者无法预料的。而且可以预料的是很快 GPTs 将会提供标记个人身份信息的机制，这样对于 Action 的提供者来说，相当于后端的数据库有了最重要的索引：UserID，剩下的就很好理解了。

这里你可能会提出质疑，RAG 不是标准的做法吗？但现有的 RAG 构建的方式几乎都是静态的，而知识应该是可以实时被更新的，这里不得不提到向量数据库。

对向量的支持，在去年是数据库迭代的一个热门方向，产生了很多专门的向量数据库， 但是我认为，更丰富的数据访问接口，使得向量搜索成为标配，然而 SQL 仍然是基石。向量搜索并不值得专门使用一个独立的数据库来支持，更应该是现有的数据库中的一个功能，就像 ：

PlaintextRust   INSERT INTO tbl (user_id, vec, ...) VALUES (xxx, [f32, f32, f32 ...], ...);   SELECT * FROM tbl WHERE user_id = xxx and vector_search([f32,f32,f32,f32 ...])

类似的访问可能是更符合开发者直觉的。

而 关系型数据库天然支持插入和更新 ，另外配合向量索引的搜索能力，便可以将 RAG 变成一个可以实时更新实时查找的正反馈循环（利用 LLM 引入进行二次的 Summary ，然后将更新的 Index 储存在 DB 中）。更重要的是， 关系型数据库的引入消除了向量数据库带来的数据孤岛的问题 ，当你可以将向量索引筛出来的数据关联（JOIN）到同一个 DB 中其他的数据的时候，灵活性带来的价值就得以显现。

另一个好处是，Serverless 的产品形态，同样也将数据的所有权归还给用户本人，大家思考一下，在我们熟知的 Web2 时代，我们的数据是隐藏在一个个互联网公司的服务背后的黑箱，我们没有办法直接访问；而在 GenAI 的应用场景下，数据的交互变成一个三角的关系，用户 - 数据 (RAG) - GenAI。很有意思的是，这个正是 Web3 的理想之一，GenAI 的普及很可能顺手也将 Web3 想实现的将数据的所有权交还给用户的理想，这在 Web2 时代是不可能实现的，这其实是一种技术理想的回归。

当然，我相信在未来 RAG 会成为数据库的很重要的一种新应用场景，在这种场景中 Serverless 形态提供的云数据库服务会变成标准化的。

预测二

由高价值数据驱动的应用成为 GenAI 应用的主流，弹性与实时交互成为数据库能力的基石。

在预测一里我们提到， GenAI 时代的应用要求知识和数据是可以被实时更新的，这对数据库的弹性以及实时交互提出了非常直接的需求。

数据库的可扩展性一直是过去十年间，业界关注的重点之一。根据我们的观察，大多数单一在线业务，100TB 已经是很大规模，而这个规模下的一般 OLTP 业务，已经可以被市场上很多系统自信的解决。

但这些数据库大多是 Shared Nothing 的系统，Shared nothing 的系统通常会有一个假设：在集群中的节点是对等的，只有这样数据和 Workload 才能均匀的分散在各个节点上。这个假设对于海量数据 + 访问模式均匀的场景没有问题，但是仍然 有很多的业务具有明显的冷热特征， 尤其是在 GenAI 带来的数据访问方式越来越动态和灵活的 2024 年及以后 。

我们最经常处理的数据库问题之一就是局部热点。如果数据访问倾斜是一个业务的天然属性的话，对等的假设就不再是合理的，更合理的方式是将更好的硬件资源倾斜给热点的数据，而冷数据库使用更廉价的存储，例如，TiDB 从一开始将存储节点（TiKV）/ 计算节点（TiDB）/ 元信息（PD）分离，以及在后来 TiDB 5.0 中引入自定义 Placement Rule 让用户能够尽可能决定数据摆放策略，就是为了尽可能弱化节点对等假设。

但是更终极的解决办法在云端，在基本的扩展性问题得到解决后，人们开始追求更高的资源利用效率，在这个阶段，对于 OLTP 业务来说，我想可能更好的评价标准是 Cost Per Request。因为在云端，计算和存储的成本差别是巨大的，对于冷数据来说，如果没有 Traffic，你甚至可以认为成本几乎为 0，但是计算却是昂贵的，而在线服务不可避免的需要计算（CPU 资源），所以 高效利用计算资源，云提供弹性将成为关键 。

另外，请不要误解 ，弹性并不意味着便宜，on-demand（ 随需提供的 ）的资源在云上通常比 provisioned（预分配）的资源更贵，持续的 burst 一定是不划算的，这种时候使用预留资源更合适，burst 那部分的成本是用户为不确定性支付的费用。仔细思考这个过程，这可能会是未来云上数据库的一种盈利模式，

与弹性同样重要的需求就是实时交互 。GenAI 时代的应用需要数据库不仅要有强大的数据处理能力，还需要有高效的实时数据广播和同步机制。这不只是让数据能够实时更新，而是确保数据流能够实时流动，让数据库能即时捕捉到每一次交互，每一个查询，确保每一个决策都是基于最新、最准确的信息。（就是用户愿意为更高价值的实时交互付钱，想想股票实时交易和直播电商的场景就知道了）

于是整个系统——从数据的产生到处理、再到存储和检索——都必须要在实时的框架下工作，能够在毫秒级别做出实时响应，这也需要数据库能实时在事务处理（OLTP）和分析处理（OLAP）之间无缝同步。这样的实时交互能力，将会是现代数据库区别于传统数据库的决定性因素之一。

预测三

成本分析已经成为所有人关心的问题，在云数据库的可观测性中成为独立新视角。

今天我还想谈的一点是云数据库的可观测性，尤其是它是否能让我的云消费更透明。对于数据库云服务来说，可观测性的要求会更高，因为对于开发者来说，服务商提供的 Dashboard 几乎是唯一的诊断手段。介绍可观测性的文章也很多，相似的部分因为篇幅关系我也不打算说太多。

与传统的可观测性不一样的是： 在云上，一切 Workload 都会成为客户的帐单的一部分 。对于用户来说一个新的问题便是：为什么我的帐单看起来是这样？我需要做什么才能让我的帐单更便宜？账单的可解释性做得越好，用户体验也就越好。

但是如果计费测量的粒度过细，也会影响产品本身的性能以及增加实现的成本。这里面需要平衡。但可以确定的是，在思考可观测性产品的方向上，成本分析可以作为一个独立的新视角。

成本分析可以帮助用户发现系统运行中的潜在问题，并采取措施予以优化。例如，如果用户观测到某个数据库实例的 CPU 使用率较低，但成本却很高，就可以考虑将该实例的规格调整为更低的级别。

AWS 今年发布的 Cost and Usage Dashboard 和 Reinvent 上 Amazon CTO Dr. Werner 的演讲专注于成本的架构艺术也同样可以看到这个趋势。他提出了 “俭约架构” 七大法则来在云的环境中打造更加高效、可持续的系统，为我们提供了一个系统性的指导框架。

预测四

当 GenAI 时代的各种应用和工具变得越来越轻巧，开发者体验将成为现代数据库设计的核心目标之一。

数据库平台化不仅仅是漂亮的 Web 管控界面以及一些花哨的功能堆砌。我很喜欢 PlanetScale 的 CEO Sam Lambert 在他的个人 Blog 里面关 Develop Experience 的描述他引用了乔布斯的一句话“Great art stretches taste, it doesn’t follow tastes（ 伟大的艺术拓展审美边界，而不是刻意迎合。）”。

好用的工具之所以好用，是因为其中是饱含了设计者的巧思和品味，而且这个设计者也必须是重度的使用者，这样人们才能体会到那些细微的快乐与痛苦，但是又不至于沉浸其中使其盲目 ，其实这对负责开发者体验的产品经理来说是极高的要求。

数据库管理工具作为一种频率不算高频、但每次使用都很严肃的工具，在 AI 和云的时代，我认为有一些与体验紧密相关的设计原则是需要遵守的：

API First, 数据库平台应该提供稳定的 / 前向兼容的 API，一切在管控平台里能干的事情，API 都要能做到，最好你的管控平台是基于你的 API 构造的。这为你提供一个功能齐备的好用的 CLI Tool 也是关键的必要条件。

使用统一的认证体系，在设计阶段将管控的认证和用户体系与数据库内部的认证体系打通，传统的数据库基于用户名和密码的权限体系在云的时代是不够的。这为了后续与云的 IAM 和 Secret 管理体系对接打下基础。

对不同的功能构建不同的 / 稳定的小工具 (Do one thing, do things well)，但是通过一个统一的 CLI 入口和语义系统进行调用。比较好的例子是 rustup, 甚至 git 也是个很好的例子。

稍微总结一下，2024 年，数据和数据库技术仍然处于巨大的变革期，谁也没办法预测未来，因为我们就身处这么一个不确定性巨大的时代。但好的一面是，创新仍然层出不穷。我今天预测的，很可能过几个月就会被我自己全部推翻，也是很正常的事情，如果能给当下的你有所启发，那就够了。