GitHub Star 突破 25,000、集众多特性于一体的 2.3.0 版本重磅发布、Docker Hub Milvus 镜像下载量突破 1000 万……过去一年，Milvus 社区取得了很多激动人心的进展，而 Milvus 技术交流群作为众多开发者交流分享的重要阵地，今年的规模也突破了 5000 人。

我们将 2023 年所有 Milvus 技术交流群的聊天历史做了整理分析，得到了如下的一张词云图：

按照热度，排名前十的关键词依次为：版本、查询、内存、插入、配置、日志、集群、文档、 部署、删除。今天，我们先来扒一扒前五大关键词！

01.「版本」：AIGC 需求的快速变化，催生了向量数据库的超高速迭代

对于“版本”成为热度排名第一的关键词，我开始是有点意外的，仔细一想似乎也在情理之中。2023年，是 AIGC 大爆发的一年，LLM 展现出了强大的分析、推理、归纳、总结能力。但是，由于缺乏最新的和特定领域的训练数据，大模型“幻觉”成为困扰 AIGC 开发者的一大难题。随着 RAG 技术的发展，LLM 和向量数据库这对黄金搭档开始走到一起，成为幻觉问题的通用处理范式。

Milvus 作为全球最流行的开源向量数据库，大量 AIGC 开发者涌入 Milvus 社区，给 Milvus 提出了诸多新的需求。在无数开发者的期盼下，Milvus 去年一共发布了 20 个版本，支持了 partition key、Dynamic Schema、Array Data Type 等大量 AIGC开发者需要的功能，关于版本的讨论几乎一整年没有停过。搜索“版本”这个关键词，常见的讨论有：

• “Milvus后面有版本可以无限创建 collection 么”

• “新版本的 Milvus 里的一个 collection 支持多个 vector 嘛？”

• “新版本我记得好像可以单独 load partion 到内存里，不需要 load collection”

大家对于版本的讨论，主要集中在 Milvus 各个版本的 feature 和 bugfix 情况。Milvus 的小版本平均 2 周发布一个，大版本平均半年发布一个。单 2.2.x 系列的版本，目前已经有 16 个了，所以完全记下每个版本的 feature 和 bugfix 几乎不太可能。但是，所有版本的发布信息都会在 Milvus 官网的 Releases 页面（https://milvus.io/docs/release_notes.md）非常清晰地展示，包括大家最关心的 feature、bugfix，同时还有一些 improvement 以及 breaking change。如果你关心这些 feature 或者 bugfix 的实现，还可以去看背后的 pr。强烈建议，大家有任何关于版本的疑问，都可以去 Releases 页面寻找所需信息。

除了常见的 feature 和 bugfix 讨论外，针对“版本”这个关键词，我们也经常遇到如下提问：

• “请问现在哪个版本最好用？”

• “这个版本大概什么时候发布呢？”

关于版本选择，Milvus 目前仍处于快速迭代的阶段，建议大家尽量使用最新的版本。因为新版本不仅包含了之前所有已知问题的 bugfix，还拥有最全的功能、最好的性能。很多问题，尤其是 Milvus 早期的 bug，都可以通过升级到最新版本解决。

至于新版本的发布时间，则取决于 Milvus 的功能研发和测试进度，比较难给出准确时间，可以参考 Milvus 官网的 Roadmap 页面。

02.「查询」：始于向量，不止于向量

Milvus 作为一个向量数据库，查询是用户使用频率最高的操作。最早的时候，Milvus 只支持纯向量的 Top-K 近似查询，随着社区的壮大，用户对于查询能力的需求也逐渐增多。

目前，Milvus 最新版本（v2.3.4）已经支持了非常丰富的查询能力，Top-K 近似查询、表达式过滤近似查询、RANGE 近似查询。在火热的 RAG 应用浪潮中，不少开发者还提出让 Milvus 支持关键词检索的需求，在这里也给大家剧透一下，这个功能将在 Milvus 的下一个大版本(v2.4.0)上线。

对于“查询”这一关键词，大家讨论的话题比较多样化，例如：

• “200 万特征用的是 FLAT，查询 Top100 大概每次耗时 500 多毫秒，这个性能正常么？”

• “Milvus 在查询之前怎么实现属性过滤呢？”

• “请问查询的索引能设置为阈值吗？例如，返回相似度大于等于 0.85 的结果。”

• “Milvus 支持使用类似传统 Elasticsearch的BM25 查询算法吗？目前在 rag，单纯向量检索片段效果不好，想着增加传统的关键字检索。如果 Milvus 支持 bm25 的话，就不需要再单独建 es 了，也不需要数据写 2 份了.”

这些多样化的讨论，实际上可以总结为 3 类：查询性能、查询功能、查询原理。

性能问题，社区之前有一篇文章《浅谈如何优化 Milvus 性能》，已经讲了比较详尽的分析方法，八成的性能问题，都可以通过文章里的方法去优化。

功能方面，想要了解某项查询能力是否具备，最简单的方法就是打开 Milvus 官网的 User Guide —> Search and Query 页面寻找，上面有十分详尽的接口说明和代码示例。如果在官网上面没有搜到的查询功能，建议先去 Milvus 的 GiHub issue 里面搜索相应关键词，看一下社区里面有没有类似的需求，以及这类需求是否有其他解决方案。如果在 issue 里面也没有找到，不妨创建一个类别为 feature request 的 issue，把你想要的查询功能详细描述出来，并说明其对应的使用场景，说不定下个版本里面就有你要的功能了。

最后，一些小伙伴如果想更深入地了解 Milvus 里面某些查询功能的实现原理，以下三处一般会有你需要的内容：

• Milvus Enhancement Proposals (MEPs)

• Zilliz B 站视频

• Zilliz 公众号 Milvus Tech Zone 专栏

03.「内存」：省一点，再省一点

“partition key 也是很多人在一个集合里吗？可不可以一个人一个人的释放占用的内存”

“因为我在插入数据到时候报错内存不足，所以我想算一下需要多少。”

“标量是不是不建议 load 内存中，感觉几十 G 的内存几下就用完了。”

“数据如果一直都有写入，那 load 后的集合会越来越占内存，不知道其他人有没有什么好的方案能在内存和查询速度上做出平衡？”

以上是关于“内存”关键词的相关讨论。向量作为一种新的数据类型，天然具有维度高的属性。为了获取优异性能，向量被读取到内存做计算也成了通用的做法。但是，随着数据规模的增加，内存余量逐渐见底，在全行业都在降本增效的时代，如何省更多内存成为了所有开发者的心声。当然，直至今日，Milvus 对于内存的优化也从未停止，社区的目标永远都是“省一点，再省一点”。

但是，作为一个数据库系统，不可能同时满足内存低、性能好、精度高的条件。一般都需要牺牲性能或者精度，来换取内存开销的降低。可以用下面这张图来表示目前常见降低内存使用的方法：

前文也提到，2023 是 AIGC 应用爆发的一年，在做 LLM 应用开发的过程中，大家能直观感受到大模型的响应时间是比较慢的，一般是几百毫秒到几秒。在这样的背景下，开发者对 Milvus 的性能要求一般不会特别苛刻，在几百毫秒内返回便能满足大多数场景。所以，MMap 和 DiskANN 是大多数 AIGC 开发者节省内存的更优选。

04.「插入」：丝滑入库是影响开发体验的第一步

除了查询之外，“插入”应该是使用最多的一个数据库操作，所有后续的工作也是建立在数据成功插入的基础上。丝滑的入库体验，是影响开发体验的第一步，也是至关重要的一步。

Milvus 社区对于“插入”的讨论，主要集中在数据插入的实践经验上：

• “插入的速度怎么优化啊？”

• “分批插入数据，是每一批 collection.flush()，还是最后再 collection.flush()？”

• “这个设置成主键之后，为什么还可以继续重复插入相同的值？”

关于这一关键词，和大家分享 3 点关于数据插入的心得：

1. 批量插入快于单条插入，文件导入（bulk_insert）快于批量插入（insert）。普通 insert 接口，数据入库需要经过 Proxy—>MQ—>DataNode—Object Storage 这样较长的一套流程。但是文件导入 bulk_insert 的入库流程仅为：Proxy—>DataNode—Object Storage，可以减少耗时较长的 MQ 环节。对于大批量（千万以上）的数据导入，强烈建议使用 bulk_insert 接口。

2. 插入数据时，不要每一批都调用 flush()接口，Milvus 内部会定期调 flush() 接口，所有数据都插入完成之后，再调用一次 flush 即可。插入数据后，频繁调用 flush，会产生大量碎的 segment 文件，为系统带来较大的 compaction 压力。

3. Milvus 用 insert 接口做数据插入时，不会做主键去重，如果希望主键去重，可以使用 upsert 接口。但是，由于 upsert 内部多做了一次 query 操作，插入性能会比 insert 更差。

05.「配置」：半数使用问题是配置问题

• “Milvus 配置用户名密码进行校验，需要怎么开启呢？”

• “这个服务通过 k8s 已经起来的，我在不想关闭他的情况下应该怎么修改配置文件呢？”

• “ etcd 如果独立部署的话，这块儿的配置有推荐的参考值吗？”

Milvus 作为一个分布式向量数据库，除了自身有较多的功能模块，同时还依赖对象存储、消息队列、etcd 等第三方组件。为了保证 Milvus 集群在不同应用场景中均能发挥出最佳性能，Milvus 暴露了大量的配置参数。但是面对这些配置参数，“调哪个”“怎么调”“调多大” 成了很多用户所遇到的难题。可以说，如果把 Milvus 的配置参数调明白了，Milvus 一半的使用问题都解决了。

关于“调哪个”的问题，我认为是配置这三个问题中最难的，不同的使用场景下，要调的参数都是不同的。就拿性能优化这件事情来说，搜索性能优化的参数和插入性能优化的参数肯定是不一样的，这就比较依赖于实际使用的经验。Zilliz（Milvus 原厂）的官方公众号上，有很多 Milvus 的资深研发同学和 Milvus 深度用户写的技术文章，里面提到了很多配置调优经验，大家可以将这块的资源充分利用起来。

此外，Milvus 社区里会经常举办一些线上线下的交流活动，每次活动都会邀请一些社区大牛来做分享，这种当面直接的交流机会，大家也可以去把握一下。总之，社区的交流通道还是非常开放的，只要你主动一点，总是能找到解决方案的。

当我们知道“调哪个”以后，后面的问题就好办很多。关于“怎么调”，《稍作修改便能更丝滑？Milvus 的秘密藏不住了》里详细讲了对于不同的部署方式，如何去修改配置参数。同时补充一点，Milvus 从 2.3.0 版本开始，就开始支持动态调整参数，具体操作方法参考：https://milvus.io/docs/dynamic_config.md，以后再也不用担心改完配置需要重启才生效了。

最后，对于“调多大”，一般在解决“调哪个”问题的时候就会顺带知道“调多大”的答案。假使不知道也没关系，Milvus 官网的“Configure Milvus”章节花了大量篇幅介绍每个配置参数的含义，配合动态更新的能力，可以快速进行测试做一些验证，然后找出最佳的参数值。

未完待续……