从 Milvus 技术实践探讨如何从 0 到 1 做一款向量数据库｜InfoQ《极客有约》

随着人工智能技术的飞速发展，大模型成为了这个领域里的热点。而在这个大模型的背后，向量数据库扮演着至关重要的角色。它们是大模型中的核心组件，为这些模型提供着海量的向量数据，从而支撑着各种应用场景的实现。

向量数据库是一种专门设计用来存储和查询向量的数据库，它通过将文本、图像、音频和视频等数据转换成向量形式，实现了对这些数据的统一处理。在大模型中，向量数据库可以提供高效的数据检索和服务，使用户能够快速地获取所需的数据。

以自然语言处理领域的大型预训练模型为例，这些模型通常需要处理数亿甚至数十亿的语料库，将它们转换成向量形式，并进行计算和分析。在这个过程中，向量数据库的高效性和准确性对于模型的训练和推理至关重要。如果没有向量数据库的支持，这样的处理任务几乎是不可能完成的。

据统计，目前全球范围内已经有超过 200 家公司推出了向量数据库产品，其中包括一些知名的大公司如谷歌、亚马逊和微软等。这些产品在性能、可扩展性和易用性等方面都有了显著的提升，为用户提供了更加高效和可靠的数据服务。

以开源向量数据库产品 Milvus 为例，它已经成为了当前最流行的开源向量数据库之一。Milvus 可以支持亿级别的向量存储和检索，并提供多种语言的接口，使得用户可以方便地使用 Python、Java 等语言进行向量计算和数据分析。

那么，Milvus 向量数据库的研发过程中有哪些技术难题？每次迭代背后的思考又是什么？在大模型如此火热情况下，该如何从 0 到 1 构建一款向量数据库？带着这些问题，我们邀请到了 Zilliz 合伙人兼技术总监栾小凡，与他一起探讨业内关心的向量数据库的相关话题。

InfoQ：观众朋友们大家晚上好，欢迎来到 InfoQ《极客有约》，本期我们邀请到 Zilliz 合伙人兼技术总监栾小凡来到我们直播间，和大家聊聊如何从 0 到 1 做一款向量数据库。先请小凡老师简单做下自我介绍。

栾小凡：大家好，我是栾小凡。目前担任 Zilliz 的技术合伙人，同时也是开源数据库 Milvus 的主要维护者。很高兴能在这里与大家相聚。最近，无论是在社区还是在公司内部，都取得了许多令人振奋的进展。对于关注我们社区动态的朋友们来说，可能已经了解到，就在上周，我们刚刚发布了 Milvus 2.3 版本，这也是我们 2.0 系列的全新版本。经过近 5 到 6 个月的努力，我们推出了这个版本，其中包含了许多令人期待的新功能，以及一些性能的优化。

“押宝”向量数据库赛道背后的思考

InfoQ：您能分享下当初为什么选择向量数据库这个赛道呢？

栾小凡：我们公司专注于向量数据库大约可以追溯到 2018 年左右。当时，向量数据库的概念并不广泛。我们的 CEO 力排众议，认为这个领域有巨大潜力，因为这与我们的愿景高度契合。我们的公司定位是构建一个能够在云上处理非结构化数据的基础设施产品。经过大量调研，我们意识到向量检索可能是未来处理非结构化数据语义和信息的关键。

另外一个重要的因素是，向量数据库与模型相比具有明显的区别。我们早在此前就认识到，处理非结构化数据需要依赖人工智能，需要模型的支持。然而，那时的模型与现在的 ChatGPT 等大型模型相比，性能有限。作为初创公司，如果我们专注于开发模型方向，可能难以取得今天的成就，也难以像 ChatGPT 这样发布出色的产品。因此，我们决定将注意力放在基础设施上。鉴于我们团队成员都具备基础设施的背景，我们设想了一个能够有效支持高维数据处理的基础设施产品，即向量数据库的概念。

从 2019 年开始，我们便着手开发这个产品。当时，我们已经吸引了许多关注，尽管当时社区用户主要集中在传统的应用场景，如图像搜索和 NLP 领域的问答机器人。直到去年，随着大型模型的兴起，数据库的使用场景和用户需求发生了重大变化，也带火了向量数据库的需求。这个现象表明数据库的第一应用场景正在演变，用户对能力的需求也发生了显著改变。

InfoQ：请您展开说明下哪些需求推动了这个更新和迭代。

栾小凡：这个问题需要深入讨论大模型与向量数据库之间的关系。从去年 ChatGPT 推出时这个问题就开始引发我们的思考。在当时，我们敏锐地意识到这将是一个机遇。然而，在国内，这个概念的认知需要更长的时间。我个人在去年四五月份的美国之行中注意到，数据库在美国已经是一个非常热门的话题，但在国内似乎还没有得到广泛认知。所以，我们需要从向量数据库与大型模型之间的关系入手。

在我看来，这个关系解决了人工智能领域中两个重要问题：生成和检索。一开始，很多人在争论是否可以通过对大型模型进行微调来获得领域知识。向量数据库与大型模型的结合是否合适？现在越来越多的观点表明，微调主要带来了一些规则性的认知，而真正的知识需要外部存储来补充。这就引发了对向量数据库的需求。

在上述背景下，我们提出了一个名为“CVP Stack”的概念，其中“V”代表向量数据库（vector database），“C”代表 ChatGPT，"P"代表 prompt。在我们看来，大型模型代表推理能力，向量数据库则补充了它的知识，而 prompt 代表控制逻辑，用于实现特定语义。这三者的结合可以实现出色的业务效果。

既然向量数据库在大型模型和存储之间扮演存储角色，就出现了对向量数据库的多重需求。首先，大模型需要存储海量数据，可能需要像传统数据库一样进行分布式部署，尤其是在云环境中。

其次，成本问题也变得十分重要，因为通常情况下，计算资源相对较昂贵，而存储资源较为廉价，向量数据库也不例外。过去，向量数据库主要是内存驱动的，成本较高。但随着大模型的结合，未来非结构化数据量会越来越大，这将带来存储成本的需求。

第三，我们可以预见许多功能上的需求。随着大型模型的发展，用户对向量数据库的需求不再局限于简单的操作。用户希望能够进行多向量操作，或者基于某些标量字段进行过滤、分组等。这些需求演化出了对向量数据库多样化功能的需求。

InfoQ：您刚刚提到了许多内容，我们对于向量数据库的需求变得越来越多，市场上也出现了很多厂商推出自己的数据库解决方案。然而，我注意到一种趋势，就是很多厂商将向量引擎添加到传统数据库上，从而转变成所谓的向量数据库。我想了解您对这种“插件版”向量数据库与从零开始构建的向量数据库之间的区别有何看法？这种基于传统数据库添加向量引擎的方式，与我们从一开始就构建的向量数据库相比，存在哪些差异？

栾小凡：我一直坚持一个观点，即并非所有基于向量的解决方案都应被统称为向量数据库，尽管它们的能力在某些方面可以与之匹敌。从我的观点来看，例如 pgvector 或 Elasticsearch，它们都是非常出色且成熟的产品，在特定场景下，确实可以很好地满足用户需求。在数据量很小的情况下，使用 Elasticsearch，结合标量检索，已经足以满足业务场景。或者，如果你的原始数据完全存储在关系型数据库，然后基于 pgvector 操作去进行几十万甚至 100 万数据的搜索，这样也是完全可行的。但是一旦数据量变大，你会发现很多业务场景会受到传统数据库设计的限制，无法很好地扩展。

实际上，在讨论向量数据库提供哪些能力时，我认为有几个关键点无法回避，包括算法、算力和调度。作为一个向量数据库，这几个方面都需要经过特殊设计。我一直提到的一个例子是，如果你只想进行近邻检索，你完全可以写个 ANN，也许只需要不到 10 行代码就能实现你所需的近邻检索功能。但是大家选择不这样做的原因，在很大程度上考虑了性能和成本因素。从这个角度看，一旦性能、成本和可扩展性对你至关重要，许多传统的数据库可能无法满足需求了。

Milvus 从 0 到 1 技术实践

InfoQ：Zilliz 是如何从 0 到 1 做一款向量数据库的？经过了哪些升级和迭代？

栾小凡：这实际上是一个颇具曲折性和难得性的故事。由于我自己是在公司中间加入的，从 2.0 版本开始参与了 Milvus 的构建，而我们公司在向量数据库领域已经有大约 5 年的历史了。

最初，我们看到了这个机会，并意识到有诸如 Faiss 等引擎在处理向量检索方面已经非常成熟，许多大型厂商也在使用它们。因此，我们的第一个版本设计非常简单，仅在 Faiss 上增加了一些持久化的日志，以及一些基础的 RPC。当时很多人认为 Milvus 只是在 Faiss 上做了一层封装，这是最早对 Milvus 的看法，实际上，这个结论现在可以套用在大多数正在创业的向量数据库上，它们目前架构与我们最早的 1.0 架构几乎没有什么区别。

在这个过程中，我们从 0.1 到 1.0 版本进行了许多尝试，主要受到最早一个重要客户的影响。虽然我不提及客户的名称，但他们最初使用了 Milvus 的早期版本，即 0.1 版本，来处理 1000 万数据集，效果非常好，他们很满意。然而，他们发现随着数据量的增大，Milvus 的扩展性无法满足他们的需求。他们希望处理更大规模、达到 10 亿甚至更大的数据集，但这需要面临着诸多挑战。为此，我们采取了许多技巧，包括特殊的优化方法、更大的机型，以解决 10 亿数据的问题。

从那时起，我们认识到向量检索（在 2020 年底至 2021 年早期）的性能和扩展性是非常关键的问题。因此，我们开始着手构建 2.0 版本的核心能力。

InfoQ：那您能介绍下，每次版本迭代，背后的思考是什么吗？

栾小凡：在整个 2.0 设计过程中，有几个关键点是我们从一开始就在思考的。

首先，我们考虑如何实现扩展性。

其次，我们考虑了云原生或者说关注数据库的重要点，这包括弹性和数据的隔离性。因为在 1.0 版本时，用户在构建索引时查询性能会相互影响。因此，我们的目标是有效地将索引构建和查询隔离开来。第三个考虑因素是数据的实时性。在 1.0 版本中，我们的一个用户因为一致性保障较弱，插入了大量数据，但在查询时却无法找到。我们花费了很多时间排查，最终发现插入的数据没有及时构建索引，未能在线上提供服务，而用户完全不知道这一点。

为此，我们在构建 2.0 版本时关注了实时性，保障用户插入数据后能够及时使用，最理想的情况当然是强一致性，即写入后立即可以查询到。然而，某些场景下，可以接受一定的延迟，但保障是必不可少的。因此，我们在 2.0 版本中花费了很多精力开发流式数据的写入能力，如何将流数据与传统批量导入的数据结合起来，包括如何对数据进行更新和删除。这些问题在我们的 2.0 版本中，尤其是在云原生架构下，变得相当复杂。大家或多或少都了解，与数据湖相关的问题，早期的产品也没有更新和删除的能力，这些能力是在后来引入的。因此，2.0 版本的设计非常大程度上关注于如何解决实时性问题。

大约在 2021 年 6 月左右，我们发布了第一个 RC 版本。然而，实际上如果现在回顾当初的版本，它是相当不成熟的，包括缺乏删除支持，负载均衡能力也非常薄弱。通过大约两年左右的不断打磨，现在有了一个稳定、高效的版本。

对于我们来说，下一个更大的挑战可能是如何将这个开源系统更好地运行在企业环境或云端环境中。虽然 2.0 版本已经具备云原生的特性，但对于开源和商业环境而言，最大的区别在于我们对资源的更多控制权。

因此，在我们的向量数据库服务中，我们经常思考如何将正确的资源分配到正确的位置上。例如，如果用户的请求 QPS 不足，如何增加计算资源？如果用户内存不足，如何增加内存？在简单的开源向量数据库或传统数据库中，这种资源管理是不存在的。只有在云原生分布式的向量数据库中才能有更多调度的可能性。

InfoQ：云原生分布式向量数据库的优势有哪些？

栾小凡：首先解释一下什么是分布式，什么是云原生。分布式的概念相对容易理解，就是系统的各个组件在不同的节点上进行协作和分工，以实现更大规模和更高性能的处理。而云原生并不仅仅指运行在 Kubernetes（K8s）上或在公有云上的服务。在我的理解中，分布式云原生意味着系统首先是一个资源池，不仅包括计算资源，还包括数据和其他资源。举个例子，向量检索在构建索引阶段通常需要大量的计算资源，但是一旦索引构建完成，这些计算资源就被浪费了。在传统方法中，可能需要额外的管理和优化来避免浪费。然而，在分布式原生系统中，可以将资源共享给多个租户，从而提高资源的利用率。这也意味着，对于某个用户而言，可以通过共享的资源池加速索引构建过程。

这就是资源池的概念，它可以让多个租户共用同一个计算资源池，提高资源的复用率。从用户的角度来看，在相同资源投入的情况下，或者在相同成本的情况下，通过利用这个资源池，可以更多地分配资源，从而加快索引构建的速度。这样做可以在保持相同资源开支的前提下，提升效率，因为资源的价值可以通过单位时间内的使用量来度量。通过这种资源池的弹性分配，用户可以在同等成本下获得更多资源，从而缩短任务执行时间，提升用户体验。

在构建云原生系统时，这是一个需要仔细设计的方面。为了实现这一点，存储和计算的分离是必要的。在现代数据库领域，比如 OLAP 等，存储和计算分离已经成为一种共识。在向量数据库领域，据我所知，我们可能是第一家也是唯一一家在开源中实现了存储与计算分离的数据库。没有存储和计算分离的能力，云原生的概念很难得以实现。

InfoQ：您提到 Zilliz 是第一家，可能也是唯一一家做存算分离的数据库架构，它的技术难点您觉得在哪里？

栾小凡：在过去的两年多里，我们走过了一段技术探索的旅程，但事实上我们在这个过程中遇到了许多挑战。因为通常情况下，存储和计算分离的架构主要用于 OLAP 数据库。在传统的 OLAP 数据库中，数据的更新频率相对较低。虽然一些 OLAP 数据库支持更新操作，但更新和删除的能力相对有限。此外，OLAP 数据库通常要求较低的查询延迟，查询几秒钟或几十秒钟，满足前端业务需求即可。然而，向量数据库与此完全不同。

首先，向量数据库需要支持频繁的更新操作，而且这些更新可能是大规模的批量操作。因此，对于向量数据库而言，必须拥有能够支持流式更新的强大存储能力。其次，向量数据库在应用场景上与 OLAP 数据库有很大的区别。不同的应用场景对查询延迟有着不同的要求。例如，在推荐系统中，用户可能需要几毫秒甚至最多几十毫秒的查询延迟。这就要求在存储和计算分离的架构下，需要有高效的缓存机制，包括本地磁盘缓存和内存缓存。同时，在调度资源时，还需要考虑如何在扩容和缩容时避免请求抖动，以确保稳定性。

在我们的探索过程中，团队始终在不断摸索，时至今日，我们并不认为自己的方案已经达到了完美的程度。这也是为什么我们的大版本从 2.3 升级到 2.4 时，我们会进行一些架构的调整。我们意识到作为行业的探索者，必须付出一些代价。从整个中国的开源社区来看，许多社区通常会效仿美国或其他全球优秀社区的实践方法。

在向量数据库这个领域，特别是在三大数据库领域，Milvus 是最进一步探索的向量数据库产品之一。我不仅仅强调技术和能力是否最出色，更重要的是我们在探索道路上走得最远。在这条道路上，我们没有太多的前辈引路，因此一直在根据用户的反馈和自己在线上运维的经验来不断调整和优化。然而，至少从目前来看，我们的产品已经达到了可以投入生产使用的标准，并且我们对未来的发展方向也有相对明确的规划。

InfoQ：Milvus 一直在不断进行演进和版本迭代，如何判断是否增加某个功能，依据的是什么？是客户的需求、用户的反馈，还是对市场趋势的判断呢？

栾小凡：我认为需要将其分成两类情况。首先，从产品角度来看，我们必须聆听用户的声音。了解用户的需求、他们对产品的哪些方面感到不便，这是至关重要的。我们始终需要紧跟用户的反馈，因为用户的需求对产品的发展具有重要影响。当然，我们选择将产品开源，以及为什么要提供云服务，实际上也是为了获取更多的反馈和输入。我们希望不断完善产品，使其成为一个全球范围的优秀产品，而不仅仅局限于中国市场。

从另一个角度来看，作为技术领导者，我有一个原则，即在技术层面上，我不仅仅听从用户的声音。举个例子，就像在汽车出现之前，人们可能只会想到需要改进马车。类似地，在 ChatGPT 出现之前，很少有人能够预见到大型模型和 AI 会以何种方式改变我们的生活。因此，在向量数据库的未来发展方向以及如何将其性能提升 5 倍或 10 倍等技术问题上，用户的意见或许无法为我们提供明确的指导。这些是我们作为技术人员需要自己解决的问题。

InfoQ：当前，向量数据库市场正受到广泛关注，不过也有一些声音持怀疑态度。有人认为，我们可能不需要专门开发一款向量数据库，而是可以在现有的数据库基础上添加一层封装，实现向量搜索功能，从而避免创建全新的向量数据库。您对此有何看法？

栾小凡：我认为答案是这样：如果你的数据量只有 100 万条或者几十万条，无论使用何种数据库都可以解决这个问题，甚至不用使用向量数据库也可以达到目标。就像为什么要使用 MySQL 一样，如果你只有 100 条数据，可能在 Excel 中进行简单处理就足够了。因此，必须从数据量的角度来考虑才有意义。

真正有意义的向量数据库是针对更大、更加生产型的场景。当你面临生产规模的需求，无论是数据链路还是 QPS，如果需要处理千万级别的数据，或者需要进行一些特殊的向量操作，那么向量数据库才能发挥其核心作用。

从另一个角度来看，未来所有传统数据库都会支持向量，这将成为一种标准的能力，就像现在许多传统数据库都支持 JSON 一样。但是，虽然 PostgreSQL 和 MySQL 都支持 JSON，但这并不意味着 MongoDB 就失去了存在的价值。因为在 JSON 领域，如果你的核心业务需要强大的 JSON 数据库支持，大家第一时间会考虑 MongoDB。

老生常谈：开源 or 闭源？

InfoQ：您如何看待开源还是闭源的问题？

栾小凡：开源对我们来说是一种信仰。从最早开始研发向量数据库的时候，我们就相信应该让更多人了解并使用优秀的技术，这是我们选择做开源的原因。无论是在 AI 领域还是其他领域，我们希望技术不会被少数大公司垄断。在向量数据库问世之前，阿里、Meta 和 Google 等公司早就开始尝试向量搜索。但是，对于许多中小型公司来说，技术和算法上存在很多挑战，难以克服。开源初衷是使更多人能够更好地使用数据库。

另一方面，为什么我们还要提供云服务？当然，作为一家公司，盈利是重要目标。然而，我们还考虑到通过云服务，可以更快地获取用户的反馈，降低产品的使用成本和部署成本。云服务能够帮助很多人，特别是那些不希望自行维护复杂架构的用户。与之类似的例子是 OpenAI 将 GPT 模型开源，但实际上有多少人能够成功部署这个模型呢？通过 API 部署的方式能够触达更广泛的受众。

在 AI 领域，开源和云服务都有助于降低用户的门槛，而且面向的客户群体可能完全不同。对我们来说，有两个角色，一方面是开源维护者，致力于降低开源用户的使用成本；另一方面，我们也在思考如何更好地将开源与云服务结合起来。

在过去几年的发展中，我们注意到很多领域都有一个开源厂商和一个闭源厂商之间的竞争，比如 Snowflake 和 DataBricks 之间的竞争。我认为，在向量数据库领域，未来可能也会出现类似的情况，开源和闭源可能会长期并存。

InfoQ：开源数据库和云服务是否会产生冲突？

栾小凡：这方面肯定会面临一些挑战，我们一直在谨慎地把握平衡。

首先，我们的原则是不希望损害任何开源用户的权益。因此，我们内部有一个基本准则，即我们的开源版本和云版本一定会保持相同的接口和功能。绝不会出现中途放弃开源转向云产品，或是让开源和云版本分道扬镳的情况，否则这点在我们内部的人力投入、产品运维等方面都是不允许的。

然而，另一方面，我们也在考虑如何为付费用户提供更多的价值。除了降低产品的部署门槛和提升易用性外，我们还在思考其他方式。因此，云版本内部包含一个自研引擎，尽管在功能层面与开源引擎几乎完全相同，但从性能方面来看稍微更优。这意味着我们的付费用户可以获得更高的性能水平，这在性价比或性能优势方面也都会给他们带来所需的好处。

InfoQ：随着我们大模型的持续发展，以及向量数据库需求的增加，许多厂家在考虑开发大模型时也开始考虑应用向量数据库。关于在向量数据库的选型上，是选择自研还是引入外部解决方案，您对这个问题的看法是？

栾小凡：想要给出一个确切的答案可能有些困难，因为不同公司的价值定位以及个人的立场都有所不同，每个人站在不同的角度考虑问题。有些公司可能注重快速发展，而有些公司可能更追求封闭环境的能力。我认为这些不同的观点都有其合理性。但如果从我个人来选的话，我更倾向于相信开源社区的力量，尤其在三大数据库领域，共同参与一个开源社区可能会加快迭代速度。

举个例子，以 Milvus 项目为例，早在 2018 年至 2019 年，阿里和其他一些厂商都有自己的向量数据库产品，他们在当时对向量检索的理解可能比我们在 Milvus 项目上要高。经过这几年的发展，大家可以看到，从技术先进性、认知水平以及生态建设上，我们的开源产品已经全面超越了那些闭源的产品。因此，我个人认为，除非你在这个领域非常专业，否则相信开源可能更有优势。

另一方面，从我们公司的做事风格来看，我更偏向于专注做好一件事情。当我们构建云服务时，我们会采购第三方的一些服务，因为我们相信一个优秀的产品是建立在众多优秀产品的基础上的。现在社会分工已经很明确，没有人可以做所有事情，即使像 OpenAI 这样的公司，也会在某些领域保持克制，不会尝试做太多不相关的事情。所以我认为，尤其在公司规模较小的情况下，守住自己的领域，专注于自己最擅长的事情可能更为明智。

InfoQ：那对开发者来讲是自研好，还是购买第三方产品？

栾小凡：从我的观点来看，我更倾向于他们直接购买我们的服务。这实际上能够减少很多的麻烦，我说的并不仅仅是公司盈利或营收的问题。作为一个开源项目的维护者，我花费了大量的精力在社区中回答用户的问题，包括在我们的微信群里，我也经常回答问题。然而，由于开源的特性，用户的环境非常复杂，可能涉及不同版本的 Linux，不同的硬件平台，以及不同的云环境，这导致了用户体验可能不够理想。尽管我们花费了很多精力来帮助开源用户解决问题，但有时候这些问题可能很难完全解决。

作为一个开发者，如果你希望产品能够快速迭代，或者更专注于自己的业务逻辑，我强烈建议你选择云服务。另一方面，如果你的业务数据量非常大，对成本敏感，或者有线下部署的需求，那么可以选择一个开源的向量数据库。

在如何选择合适的向量数据库方面，我认为可以从几个角度出发。首先，要考虑你的业务场景。如果你的业务规模较大，性能和扩展性将是你需要关注的重点。其次如果你只是需要在较小的业务场景中使用向量数据库，那么你首先应该关注产品的易用性。易用性包括文档质量、功能丰富程度，以及部署和运维的便利性。需要考虑是否有图形界面和监控报警等功能，这些都是在选择向量数据库时需要密切关注的方面。

未来规划

InfoQ：Milvus 今后的计划演进的方向，技术更新迭代有哪些？

栾小凡：不久前，我们刚刚推出了 Milvus 2.3 版本。接下来的 2.4 版本，我们将更加贴近人工智能的使用场景。在这个版本中，我们将提供多向量的支持，这种功能可以满足大型模型和实时数据结合的需求。因为我们注意到许多人在搜索文本时的常见做法，例如将摘要做成 embedding，将具体内容分成多个 embedding，并在搜索时给予不同的权重，比如摘要权重较高，每段内容的权重较低，然后进行混合打分。从 2.4 版本开始，我们将支持这种场景。此外，随着拥有多个不同的打分、多个 embedding 字段和多个不同的打分方式，我们将继续探索基于多个字段进行排名的能力，这与人工智能的紧密结合有关。

除此之外，在 2.4 版本中，我们还将增加一些传统数据库应具备的能力。在过去，Milvus 仅支持按主键进行删除，这给用户带来了不便。在 2.4 版本中，我们将支持根据表达式进行删除的能力。

2.4 版本中将进行大规模的存储更新。过去，Milvus 的存储依赖于我们自己编写的存储格式，存储效率和查询效率存在一些问题。而且，由于这个存储格式并不通用，因此与其他系统的整合可能会比较困难。在 2.4 版本中，我们将把 Milvus 的存储作为一个独立的项目进行更新，从而更好地与外部系统进行集成。

最后，我认为最关键的一点是在向量索引能力的建设方面。在 2.3 版本中，我们已经进行了许多关于过滤检索的优化。未来，我们还将继续在现代向量索引的性能方面进行大量工作。我认为这也是大家在比较不同现代数据库时应关注的方向。我们还开源了一个 Vector DB Benchmark 工具，可以用来比较不同向量数据库的性能。我们为用户提供了多种数据集，涵盖了不同大小规模的场景和过滤情况。

打个小广告，我们为用户提供综合的排行榜，大家也可以根据自己的需求运行测试。如果您对线上数据库性能有研究兴趣，不妨了解一下我们的Vector DB Benchmark工具，这个工具已经在 Github 上开源。在这个工具中，除了我们自己的产品，也包括了 Zilliz Cloud、开源的 Milvus，还有许多其他开源和商业竞品的数据。

此外，我想借此机会呼吁一下，无论是传统公司还是创业公司，既然我们都在向量数据库这同一赛道上，为什么不一起参与这个榜单呢？我们开源这个榜单的目的实际上也是出于相同的诉求。我们希望为更多的开发者和决策者提供更多参考信息。说实话，我们并不是专业评测机构，所以可能会存在一些公平和公正的问题。因此，也更希望在一个公平的规则下，每个人都可以自行测试自己的产品，这样可能更有说服力。

InfoQ：有观众提问以后会考虑集成 Elasticsearch 那种倒排索引功能吗？

栾小凡：这个计划已经在我们的日程中了，当然，这是一个比较长期的目标。正如刚才简要提到的，2.4 版本中，我们想要提供一些新的能力，尤其是我们引入了多向量和 Ranking 方面的功能。而在之后的版本中，尤其是 3.0 版本，我们认为最为重要的两个功能分别是 SQL 支持和类似于 Elasticsearch 倒排索引的支持。

为什么要做这些呢？实际上，我们看到稠密嵌入和稀疏嵌入之间的搜索是相互补充的。在不同的检索理念和场景下，两者能够搜到不同的内容，从而在最终的召回效果方面有很大的提升。

在过去，我们更多地关注向量本身，特别是在相同向量集合下，如何从数据层面获得更高的召回率。我们的召回率更多地集中在向量数据集本身。如果我们将视角放得更高一点，例如对文本进行召回，那么除了在向量召回效果方面的提升外，还有很多其他方法可以尝试。例如，您可以通过排名的方式进行，也可以使用一种类似于倒排索引的方法，以搜到一些特殊的结果，然后再进行合并。这些是接下来 Milvus 社区希望探索的方向。

InfoQ：您看来还有哪些值得开发者和所有从业者们去关注的未来发展趋势？

栾小凡：向量数据库现在确实备受瞩目。然而，我相信那些尝试过向量数据库的直播观众会发现其实效果有时并不如他们所想象的好。因此，对于向量数据库而言，首要的事情是对嵌入算法本身进行更多的探索。虽然向量数据库能够解决快速检索的问题，但在整体检索效果方面，首先是模型的重要性，其次是有许多技巧。

因此，我也希望所有致力于向量数据库或大模型的同行能够共同努力来进行市场教育。我们需要告诉用户如何以何种方式使用向量数据库，想要充分利用它，需要深入了解许多关键点和诀窍，只有这样才能取得良好的业务效果，远非现在所谈论的那样简单。

另一方面，我认为向量数据库与传统数据库的进一步融合也是非常重要的。关于传统数据库是否适合处理向量数据的问题，我刚刚也给出了一些答案，针对大模型的情况下，传统数据库肯定会有其特殊性，而在这种结合下，传统数据库的迭代速度会更快。然而，我们也必须看到这个趋势，即分久必合，合久必分。最终向量数据库要逐渐朝着传统数据库发展，加强很多传统数据库的能力。就像刚刚有用户问到的备份能力，这正是典型的传统数据库能力。然而，根据我目前的观察，目前向量数据库仍然没有充分考虑这些问题，包括数据安全性、弹性以及易用性等方面，也包括刚刚提到的 SQL 支持。因此，我认为传统数据库与现代数据库之间未来将会出现融合的趋势。

InfoQ：在传统数据库的领域，如果有人想朝向向量数据库方向发展，那么他们应该具备哪些能力呢？他们应该朝哪些方向培养技术？比如说，需要掌握哪些编程语言？需要了解哪些算法和技术？您是否能给予一些建议呢？

栾小凡：就产品定位而言，虽然不同产品有不同的定位，但产品开发者之间的界限并不是特别明确。就我个人而言，我背景是传统数据库，曾在 Oracle 和阿里云从事 NoSQL 数据库领域的工作，所以我认为这些领域的划分并不是那么严格的。

要做好向量数据库，与做分布式数据库类似，首先需要掌握各种基本原理，例如数据库的编译器、执行器，存储设计，以及数据分片等。这些基础知识是通用的。

如果要说有什么不同之处，我认为主要有两点。首先，你需要深入了解不同的应用场景。与传统数据库不同，向量数据库面向的是算法工程师和前端开发人员，因此，如何设计产品更易用、如何理解他们的业务场景，以及如何让数据模型更加灵活，这些方面存在较大差异。

其次，你需要掌握一些人工智能的知识。向量数据库与传统数据库的另一个区别在于，它并不要求百分之百的精准匹配。这意味着向量数据库更像是一个既支持 AI 的数据库系统，也是一个 AI 对数据库进行加持的使用案例。从我们 Milvus 数据库的角度来看，我们近期进行了许多实验，利用模型能力来提升向量数据库性能。因此，掌握一些基本的机器学习和算法知识，有助于思考如何更快速地优化向量数据库的性能。

InfoQ：对于那些希望从其他数据库领域转向向量数据库领域的开发者们，您有什么建议吗？需要重点培养哪些能力？

栾小凡：首先，不要过于畏惧转换赛道。向量数据库与其他数据库一样，也是一种数据库类型。从传统的 TP 数据库转向现代的 AP 数据库，你无需过度焦虑。然而，在这个过程中，你需要了解向量数据库的发展历程，了解竞争对手，了解各家的价值定位，了解他们的架构和 API 设计。这与从传统的 SQL 转向 NoSQL 数据库的情况类似，大家都会熟悉 Bigtable 和 Snowflake 这样的论文。同样，阅读相关论文以及其他竞争产品的相关论文，甚至是业界最新的研究，都能帮助你更好地理解数据库领域的情况。

其次，要掌握 AI 的基本能力。了解 Transformer、CNN（卷积神经网络） 等基本概念，对于向量数据库领域是非常有帮助的。尽管一开始你可能对这些内容不甚了解，但学习这些基本概念是迈向向量数据库领域的必经之路。尤其是对于数据库开发者而言，AI 和模型方面的知识将成为你不可或缺的基础。这将有助于你更清晰地定位数据库功能，并能更轻松地将上下游打通，从而实现优化。

InfoQ：有观众提问，新的 2.0 版本有提供可靠的备份方案吗？数据冗余的能力如何？

栾小凡：我们一直非常关注数据的可靠性问题。在 Milvus 3.0 版本之前的设计中，所有数据都是以实战和分离的方式存储。这个设计的第一个保障是，所有存储本身都有三个副本的保障。如果数据库部署在云上，像阿里云的 OSS 或 AWS S3，它们的冗余保障非常高。

在 Milvus 2.0 的早期阶段，确实存在一些稳定性问题。因此，从大约 22 年开始，我们推出了一个名为“Milvus Back Up”的新工具。这个工具可以将 Milvus 中的数据备份到对象存储，或者备份到其他地方。在最新版本中，我们还引入了一个新的能力，叫做“change data capture”，它可以备份增量数据。在增量备份和存量备份的情况下，即使集群出现问题，数据丢失的可能性也非常小。

我需要提醒大家的是，最近我在社区里看到了一些情况，有些操作可能会将 Milvus 的元数据和存储分开进行备份，然后在回放时可能只恢复其中的某一部分，导致表丢失或底层的数据文件丢失。因此，大家需要格外注意这一点。目前来看，我们正在进行大量的测试，在过去的一段时间里，并没有太多关于对象存储或 Milvus 本身导致数据丢失的问题，绝大多数情况可能是因为误操作。

InfoQ：在使用 Milvus 的时候大家在操作上需要特别注意哪些问题呢？

栾小凡：当考虑部署时，首先建议按照社区的指南进行操作，包括遵循最小规格要求以及硬件要求。例如，在我们的文档中明确提到，像 ETCD 需要使用 SSD 磁盘。遵循这些需求在部署过程中可以规避很多潜在的风险。

其次，在实际的运维过程中，建议做几件事情。首先是配置监控，确保系统的运行状态可以被监控到。其次是记录 Milvus 的日志，这对于问题排查至关重要。有很多用户在向社区寻求帮助时，却无法提供详细的日志，这给问题的排查带来了困难。

另外，在进行数据加载或创建索引时，务必要合理估算和管理内存。许多 Milvus 的索引依赖于内存，所以在加载数据时，如果内存不足，容易出现内存不足或无法加载的问题。在社区中，我们有一个“Calculator”的工具，可以帮助你估算物理资源能够加载多少数据。因此，建议在加载数据之前进行预估，特别是对于标量数据，因为当前 Calculator 工具仍然以标量数据为准。

对于大模型的场景，尤其是在用户倾向于将原始文本存储在数据库中的情况下，需要额外注意。目前，这种方式可能会对数据库的性能造成挑战。如果你有像 MongoDB 等更适合存储数据的地方，建议将数据暂时存放在其他地方，这将有助于提高数据库的稳定性。数据的合理存放非常重要，特别是在向量数据库的情况下。然而，当涉及存储非常长的文本字段时，尤其是那些几十 KB 级别的超长字段，从性能和内存使用的角度来看，向量数据库并不是最优选择。

InfoQ：日志部署有哪些需要特别注意的？

栾小凡：关于日志模块，我们在 Milvus 中支持两种不同的日志类型，一种是 Kafka，另一种是 Pulsar。我个人更倾向于使用 Pulsar，因为它从我们设计系统的一开始就融入了许多的设计理念，例如存算分离和支持的分区数目。不过，由于系统设计是插件化的，我们也支持了 Kafka，因为 Kafka 是一个非常受欢迎的消息队列。在选择时可以根据实际情况来决定使用哪种。

在我们的生产环境和用户环境中，这两种日志类型都有广泛的应用。需要注意的是，对于那些喜欢创建大量表的用户，有一个小提醒。在 Milvus 2.2 版本中，如果你的表数量非常多，可能会对整个消息队列造成较大的压力。我们并不推荐这样做，建议用户将表格数目控制在 100 以内。在 Milvus 2.3 版本中，我们进行了很多优化。如果你确实有大量表格的情况，我建议你仔细思考一下，是否真的需要这么多表格？我们的社区中有许多其他功能可以避免创建过多的表格。

InfoQ：好的，感谢老师精彩分享。

嘉宾介绍：

栾小凡，Zilliz 合伙人兼技术总监，同时是 LF AI & Data 基金会技术咨询委员会成员。在加入 Zilliz 前，他在阿里云担任研发经理，负责 NoSQL 数据库 Lindorm 的研发工作。此前，他曾先后在美国甲骨文公司和软件定义存储公司 Hedvig 担任软件工程师。栾小凡拥有康奈尔大学计算机工程硕士学位。