从 OpenAI 收购实时分析数据公司看未来数据库长什么样？

前不久，OpenAI 宣布收购了一家以数据索引及查询功能而闻名的实时分析数据库 Rockset。消息一出，数据库领域和 AI 圈一片哗然。

据悉，Rockset成立于 2016 年，创始团队成员大多来自 Facebook，还有几位成员来自谷歌、雅虎、甲骨文和 VMware 等公司，尤其是 Rockset 的联合创始人 & CTO Dhruba Borthakur，他曾是 Facebook 数据库团队的工程师，也是 RocksDB 数据存储的创始工程师。此前在雅虎，他是 Hadoop 分布式文件系统的创始工程师之一，还是开源 Apache HBase 项目的贡献者，无论是在 NoSQL 还是在数据库领域都有着深厚的技术积累。

OpenAI 之所以盯上了这支由一群数据库背景的技术大佬组成的团队，是因为OpenAI已经认识到，实时数据的访问和处理技术已经成为当前 AI 军备竞赛中的重要一环，要想在这场硬仗中赢得胜利，数据库尤其不能拖后腿。

近日，InfoQ 采访了 PingCAP 联合创始人兼 CTO 黄东旭和副总裁刘松，和他们一起探讨了 AIGC 时代下，什么样的数据库才能跟得上 AI 技术发展的步伐，在 AI 技术加持下，数据库又将拥抱哪些新变化。

TiDB 在向量检索引擎上的探索

事实上，在 OpenAI 出手 Rockset 收购之前，解决大模型数据的访问和存储问题时，业内普遍的解决方案是给大模型外挂一个知识库，也就是过去一年火出圈儿的向量数据库，几乎每个向量数据库厂商都试图以“大模型 记忆”进行营销。

但市面上众多的向量数据库产品中，却没有一款目前真正可重复的堆栈来将所有数据（结构化或非结构化）传输到企业需要的运营和分析存储中。人工智能需要的内存形态是一种类似于人类的记忆的东西，人类的记忆不只是记住事情，还会把这些记忆总结并将它们相互联系——并在使用之前进行分析，而通用的、具有向量检索能力的实时分析数据库是最接近这一点的东西。

过去一年，PingCAP 在这方面没少下功夫。

InfoQ：可以和我们介绍下，过去一年 PingCAP 如何将 AI 元素，比如向量检索等能力融入 TiDB 产品中吗，你们做了哪些具体的工作？

黄东旭：在 Gen AI（通用人工智能）时代，AI 对数据库的需求发生了很大变化，AI 原生应用的崛起也给数据库带来了新挑战。例如大语言模型和 Chatbot 这种形式的 AI 应用，它们对数据的访问变得更加灵活和动态。传统的数据应用往往由人编写 SQL 并封装成固定功能的应用程序，但 AI 应用需要能够根据用户的实时对话内容动态调整数据访问模式。这就要求数据库具备高度的灵活性和可扩展性，以支持 AI 生成和查询 SQL 的灵活接口。

此外，AI 应用的访问往往从边缘产生，而非传统的集中式服务器模式。每一次用户与 AI 的对话都可能触发数据库的访问，这进一步增加了数据库处理的复杂性和实时性要求。

另一个挑战是，每个用户都可能拥有个性化的数据存储需求，这导致了极端多租户的场景。数据库平台需要能够提供轻量、可扩展的租户支持，以满足海量用户的个性化需求。

针对这些挑战，TiDB 在 AI 领域的工作主要集中在以下几个方面：

• 增强灵活性：TiDB 是本身就具有 Serverless 能力的，其强大的可扩展性能够适应 AI 应用的动态需求。

• 支持极端多租户：TiDB 能够支持极端多租户场景，为海量用户提供个性化的数据存储和访问服务。

• 向量搜索能力：为了解决非结构化数据的检索和使用问题，我们在 Serverless 架构的基础上加入向量索引功能，实现了向量搜索的能力。

InfoQ：您提到的向量检索能力是在 TiDB 中加入了一个向量检索引擎吗？这款向量检索引擎是你们自研的还是用的开源版呢？

黄东旭：是我们完全自研的。作为专业的数据库开发者，从纯技术实现的角度来看，构建一个向量索引和搜索能力相较于构建一个完整的数据库系统来说，确实要简单许多。因此，当我们拥有一个强大的数据库内核研发团队时，拓展出向量搜索能力就相对容易了。当然，也不是说这项工作十分简单，只是把两者的复杂度和工作量对比起来，就高低立判了。

InfoQ：我们观察后不难发现，作为 AI 的基础设施之一，目前市面上很多向量数据库走的都是传统数据库加上向量检索引擎的技术路线。就拿国内某大模型头部公司来说，支撑其大模型的底层 Infra 就是 ElasticSearch+FAISS 的组合方案。但事实上，真的只是把两者简单叠加起来就可以了吗？您能否介绍一下，PingCAP 在自研这款向量引擎的过程中，是如何将传统的数据库能力和向量检索能力更好地融合在一起的？

黄东旭：首要的核心点在于一切要基于 SQL 进行。从用户使用的角度来看，目前操作数据最主流、最便捷的方式仍然是 SQL。因此，我们在 SQL 引擎中引入了新的数据类型，如向量列（Column type），用户只需按照传统的 SQL 编写方式，即可将向量数据直接写入数据库，并在 SQL 层面进行搜索操作，如使用“SELECT FROM TABLE WHERE 距离相近”这样的子句，这非常符合开发者的使用习惯。此外，基于 SQL 的另一个优势是能够轻松交叉关联不同数据。例如，原始数据和向量数据分别存储在两张表中，用户可以通过一条 SQL 语句直接进行关联查询，无需调用多个系统或编写复杂的应用程序逻辑。这是 TiDB 在实现向量索引时的一个重要优势和特点，这样做极大地简化了用户的操作流程。

另一个我们努力做到的是进一步提高 TiDB 的扩展性和高可用性。在当前 AI 应用和企业级应用中，客户常常面临海量数据处理和扩展性受限的问题。TiDB 提供的基于十亿级文档的检索能力，能够迅速满足企业级应用的需求。同时，TiDB 还具备权限管理、事务一致性等企业级特性，这些在现有的向量数据库使用方案中往往缺失，但对于构建企业级 AI 数据服务来说至关重要。因此，TiDB 的这些企业级能力为 AI 应用提供了有力的补充，成为其一大亮点。

此外，还有一点值得强调的是，在企业级应用中，除了基本的数据处理能力外，还需要考虑多种其他关键能力，比如权限管理与事务一致性。这些能力在现有的许多向量数据库使用方案中往往被忽视或支持不足。但在构建企业级 AI 数据服务时，这些能力是尤为重要的。

尽管多模数据错综复杂，但还未到数据架构变革之时

技术的每一次迭代都是为业务和场景服务的，TiDB 也不例外。

随着全社会数字化转型的深入，大数据和多模态数据处理成为企业面临的重大挑战。企业各个业务所产生的文本、声音、视频等数据如一盘散沙，散落在各个角落里，这些不同类型的数据在企业内部大量积累，往往因存储杂乱无章而难以有效利用。

就比如在许多保险公司的内部，他们有很多客户的数据，包括客户的个人信息、保单信息、理赔记录等等。这些数据以文本、声音和视频等形式存在，散落在 CRM 系统、语音通话记录系统和视频会议记录等各个系统中。由于这些数据没有得到有效地整合和管理，当保险公司需要依据这些数据做客户服务、风险管理和业务决策时，很难迅速找到有用的数据并高效利用起来，那这些数据虽然存在系统中，却发挥不了任何价值。

InfoQ：我们知道，大模型兴起后，AI 应用产生的数据几乎全是多模态数据，TiDB 是否有一套解决方案能把这些复杂的、多模的数据梳理好并有效利用起来？

黄东旭：这里其实就体现了向量检索（特别是 embedding 技术）的重要性。这种技术能够将不同类型的数据转换成统一的嵌入表示，即“embedding”，这就是一个将不同类型杂乱无章的数据进行归一化处理的过程。这一过程打破了传统关系型数据库在处理非结构化数据（如视频、图片）时的局限性。过去 TiDB 应对这类数据时也会比较吃力，因为传统的结构化数据库主要擅长处理结构化数据，面对多模态数据时往往力不从心。

但后来在TiDB中引入 embedding 技术后，也就弥补了传统关系型数据在处理多模态数据时捉襟见肘的窘境。通过 embedding 的方式，企业能够实现对不同类型数据的统一索引和检索。拿 TiDB 来说，这意味着，即使视频、图片等数据存储在如 S3 这样的对象存储系统中，企业也能利用 TiDB 的向量检索功能快速定位所需信息。举个例子，用户可以通过关键词或图片本身进行搜索，系统则能在庞大的数据集中迅速找到匹配项，并返回相关数据的源信息，进而从对象存储中加载出具体的视频或图片文件。

InfoQ：在关系型数据库中使用向量索引检索多模态数据时，体验是否会很流畅？

黄东旭：这是肯定的。我也会用 TiDB 自身的向量所以去做一些有趣的尝试。比如我们在搜索上有些 Demo 叫“以图搜图”。通过将图片通过嵌入化转换为向量索引并存储在 TiDB 中，用户只需输入关键词或上传相似图片，系统便能迅速检索出所有包含相关图片的数据源信息，然后就可以将这些图片存在 S3 里再把它下载出来。这种体验不仅提升了数据检索的效率，还极大地丰富了数据应用的场景和可能性。

InfoQ：在 TiDB 所面对的不同应用场景中，哪些场景对你们来说最具挑战性？你们是如何识别这些挑战并采取相应的措施来克服它们的？

黄东旭：几个月前，我们面临的最大挑战之一是 TiDB 当时尚不具备向量搜索能力。为了解决这一挑战，我们团队引入了向量搜索功能，并与 LlamaIndex 和 LangChain 等应用开发框架进行了深度整合。这么做对于开发者来说是个利好，因为这大大降低了他们开发 AI 应用的门槛，他们使用 TiDB 时也就变得更加简单和便捷。以前，用户可能需要自行构建向量索引，但现在，随着这些功能的内置，用户能够更轻松地实现其应用需求。

InfoQ：数据库产品总在不断进化，您认为当前的数据架构是否也需要升级？在引入 AI 技术如向量检索后，未来的架构是否会有重大调整？

黄东旭：AI 作为一种新兴应用，目前尚未对主流数据库设计产生颠覆性影响。当前，云原生和企业级需求是推动数据库架构变化的主要动力。向量检索等 AI 相关能力，虽然看似新颖，但归根结底仍是数据库基础操作的延伸，如增删改查，因此它们对数据库内核的需求仍在可控范围内。

我个人认为，更大的挑战在于如何依托云的基础设施设计未来的数据库架构，以实现更大规模、更易用的用户体验。这种设计将自然支持 AI 应用的更好运行，而非 AI 应用本身驱动数据库架构的变革。

InfoQ：也就是在您看来，目前还未到大规模调整技术架构的时候，是因为 AI 应用尚未全面兴起吗？

黄东旭：确实如此。目前，我们仍处于探索阶段，且以当前的探索规模来看，现有的数据基础设施足以支撑当前的 AI 应用需求。

InfoQ：您是否能预测下，当 AI 应用达到何种体量时，会催生数据架构的重大变化？

黄东旭：预测未来总是充满不确定性，但我可以分享一些观点和战略方向。拿我们 TiDB 来说，我们目前正重点投入于 Serverless 技术、大规模多租户系统以及完全依托于云的低成本数据库产品。这些努力是基于对 AI 应用趋势的理解，即边缘访问、个性化数据访问需求以及低成本要求将驱动数据库架构的变革。虽然无法确切预测何时会发生这一变化，但觉得可以确信的是，当那一天到来时，我们的技术架构是已经足够 Ready 的，并且这种架构将高度依赖云环境。

押注 RAG 技术，面向未来才能走得更远

InfoQ：在当前 AIGC 技术崛起的背景下，有哪些新的应用场景是 TiDB 之前未曾涉及的？

黄东旭：基于RAG的应用是以前 TiDB 没有涉及过多的场景。RAG技术是大语言模型发展中的重要一环。目前几乎所有的 AI 应用都试图解决一个关键问题：如何让大模型生成的答案与特定数据或上下文保持高度相关性。尽管大模型本身具备强大的能力，无论是开源还是闭源，它们都缺乏一个直接连接用户特定上下文的机制。

RAG 技术的核心就在于弥补了这一空白。通过与 LangChain 或 LlamaIndex 等 AI 应用开发框架的深度整合，TiDB 能够利用其向量检索能力和文档存储能力，轻松地支持 RAG 应用的开发。这种整合使 AI 应用能够基于 TiDB 存储的数据和上下文，生成更加精准和相关的回答。近期我们目前正重点投资于GraphRAG应用的开发，这是一个相对较新的领域，对于企业垂直领域更精准的理解知识有巨大的潜力。

InfoQ：那关于 RAG 技术，TiDB 在长文本处理能力方面有哪些具体的优势或特点？

黄东旭：TiDB在设计之初便充分考虑了对海量文本数据的支持能力，这也是我们的特点之一：我们在设计产品时总是面向未来的。就文本存储的数量而言，TiDB 有很强的扩展性，这也是我们的核心优势所在。可以自信地说，无论文本数据的规模有多大，TiDB 都能轻松应对，确保数据的完整性和高效存取。

当然，长文本的处理能力还受到大模型本身 context window（上下文窗口）大小的限制。在 TiDB 这一层面，我们能确保数据库本身具备良好的可扩展性，无论用户需要存储多少个文档，TiDB 都能稳定、可靠地满足需求，为 RAG 技术以及其他需要处理长文本的应用场景提供坚实的后盾。

InfoQ：回到数据库本身，其实除了这些新迭代的功能外，我了解到在应用场景上 TiDB 还是扎根于金融领域更深入些。金融行业特别是银行在数字化转型的道路上处于领先地位，对技术的要求极为严格，甚至超过美国，远胜于东南亚。国内的银行系统要求高度稳定，很少有业务中断超过半小时的情况，这在东南亚相对常见。刘松老师方便介绍下目前 TiDB 在金融行业，尤其是在银行业的一些落地实践案例吗？

刘松：今年的情况比去年好很多，金融银行业都在加快国产替代的步伐。记得 2023 年上半年，很多城商行还在担心，是否能顺利完成核心系统的替换，甚至担心资源是否充足。但到了今年，大家已经在技术层面上达成共识，国产数据库在城商行甚至股份制银行的核心系统中，技术上已经没有问题。但在工程实践方面，我们还在探索是否采用云原生架构，以及全国产化是否彻底。一些中小城商行仍然在担心两个主要问题：一是技术路线是否正确，二是资源是否充足。

因为在核心系统迁移过程中，银行通常需要经历长达一年多的并行阶段。但现在，大家认为技术路线的选择至关重要，大家都需要选择先进的、能够延伸到未来的技术。而且，随着成功案例的出现，市场信心得到了提升。客户在策略规划方面，需要考虑走哪条路线、选择哪种技术，以及应用架构如何设计。如果这些都做好了，再加上相对充足的预算，数字化和国产化进程在 2024 年以后将会明显加速。

根据金融行业的时间表，我们可以预见，在 2025 年甚至 2027 年，这种加速的速度将会更加明显。实际上，中小城市商业银行在技术资源上相对较少，有些机构还在使用 Oracle 和 DB2 这样的传统数据库。而且，他们的应用不一定是自己开发的。这就带来了最大的难题：如何确保应用面向国产数据库迁移的平顺性？例如，杭州银行的应用是自己开发的，他们可以自信地说，他们的应用架构采用了云原生架构。这样，他们最难的部分都是透明的，控制在自己手里，因此可以有一个明确的业务创新和国产化推进的节奏。

但并不是所有机构都敢大刀阔斧地去替换。对于中小城商行来说，他们面临的挑战主要有三个：一是应用的可控性是否在自己手中；二是技术路线的选择，这需要前瞻性的思考；三是否有足够的人力和财力资源，这些都是需要去克服的挑战。