又见版本升级！一句话概括 Milvus 2.2.4：资源隔离、多云、高效

作者：Zilliz 首席工程师 焦恩伟

Milvus 2.2.4 来啦！

经过几周的开发，Milvus 2.2.4 版本于近期正式上线。Milvus 2.2.4 是 Milvus 2.2.0 的一次小版本升级，版本虽小，却为社区带来了不少实用的新特性，包括基于命名空间的资源分组、集合级别的物理隔离和集合重命名等，同时新版本原生支持了 GCP，其他云的原生支持也在紧锣密鼓的进行中。

此外，Milvus 2.2.4 还解决了与滚动升级、故障恢复和负载均衡相关的若干问题。这些问题的修复有助于提高系统的稳定性、可靠性以及缩短故障恢复时间。

总结下来一句话——资源隔离、多云、高效！

新特性

资源组

很多用户把 Milvus 作为向量中台 或 AI 中台的重要组成部分，作为中台来说，必不可少的功能就是多租户和资源隔离、故障隔离。在没有资源组功能之前，很多用户为了保障资源、故障隔离，会为每一位业务用户启动一套 Milvus 集群，这无疑是一种浪费资源的表现，因此资源组和多租户的需求在社区中一直呼声很高。作为 Milvus 的用户肯定希望一步到位，如果 Milvus 能直接把资源组功能做好是最理想的状态，但是资源组是更偏平台、管理的功能，而且需求繁多、众口难调。

Milvus 作为一款数据库产品，通过资源组对外提供资源隔离的能力，平台侧基于资源隔离的能力对业务用户提供多租户的能力，是一种很好的集成方式。关于资源的详细介绍，详见文档 https://milvus.io/docs/resource_group.md

Collection Rename

在生产使用数据库的过程中，表 Schema 变更是个常见的运维操作，Milvus 在 2.2.4 版本中先是支持了 collection rename 操作，后续更细粒度的 Schema 变更，如加减 Column、改变 Column 的信息等能力正在设计和开发过程中，会在后续版本中持续迭代。Rename Collection 的使用方式见文档 https://milvus.io/docs/rename_collection.md

Search 和 Query API 的新选项

在 Milvus 的数据架构中，数据分为 Growing 数据和 Sealed 数据，顾名思义，Sealed 数据是已经持久化并且建好索引的数据块，而 Growing 数据则没有索引，在查询时对于 Growing 数据使用暴力搜索的方式查找 TopK，再和 Sealed 数据中的 TopK 结果进行合并。

不难发现如果 Growing 的数据很多或写入频率过高的话，势必会对查询性能有较大的影响。对于追求低延迟、查询结果稳定的用户来讲，Growing 数据的多少直接影响了系统的可用性。在不少用户场景中，他们对于实时数据没有那么高的要求。基于以上需求，我们在查询参数中新增了跳过 Growing 数据的选项，启用此选项将跳过对所有 Growing 数据的搜索，在搜索插入场景下提供更好的搜索性能。

支持 Google Cloud Storage

Milvus 现在支持 Google Cloud Storage 作为对象存储，使用 Google Cloud 的用户可以无缝对接 GCP 的对象存储。

系统优化

性能提升

通过性能剖析，我们发现了众多性能优化点，通过这些优化，Milvus 2.2.4 版本在性能上又有了长足的进展：

1. 在查询阶段跳过计算 count all bitsets

2. Collection load 过程中减少内存拷贝

3. 查询过程中跳过为长度为 0 的数据申请内存

4. 升级 Knowhere 至 1.3.9，加速 IVF 查询

5. 优化查询结果合并策略

6. 优化对象存储访问的 IO，减少与对象存储间的 rpc 调用

内存优化

在内存优化方面，我们也进行了相应的提升：

1. 增加了 datanode 内存占用过大时，强制 flush 的策略

2. 按照 16MB 切割 index 文件，防止内存占用过大 其他优化 此外，我们也对新版本做了其他优化：

3. 调整 RockMQ page 大小至 256 M，减少 standalone 模式下的磁盘占用

4. 调整 etcd 超时时间至 20 s，减少故障恢复时间

问题修复

在升级新版本的过程中，Milvus 2.2.4 也努力修复了一些问题，数量超过 40，在此仅 highlight 一些 critical 的问题（感谢测试团队能在发布前发现如此多的问题）：

1. 修复在 DiskANN 索引下，QueryNode 无法重启问题

2. 修复 DataCoord 在 watch etcd 事件时的一系列超时问题

3. 修复由于负载均衡策略导致的 QueryCoord panic 问题

4. 修复空 segmen t 情况下，DataCoord 读取 panic 的问题