Milvus 社区的各位搭档：
大家早晨好！欢送来到 Milvus 2.3.0 文字发布会！
作为整个团队的匠心之作，Milvus 2.3.0 历经 8 个月的设计与打磨，无论在新性能、利用场景还是牢靠度方面都有不小的晋升。
具体来看：Milvus 2.3.0 不仅蕴含大量的社区呼声很高的新性能，还带来了诸如 GPU 反对、Query 架构降级、更强的负载平衡调度能力、新的音讯队列、Arm 版本镜像、可观测性、运维工具降级等能力，这标记着 Milvus 2.x 系列从 production ready，走向成熟、牢靠、生态凋敝、运维更敌对的倒退门路。
接下来，我将从 7 个方面带大家深刻理解 Milvus 2.3.0。
01. 架构降级
GPU 反对
早在 Milvus 1.x 版本，咱们就已经反对过 GPU，但在 2.x 版本中因为切换成了分布式架构，同时出于对于老本方面的思考，临时未退出 GPU 反对。在 Milvus 2.0 公布后的一年多工夫里，Milvus 社区对 GPU 的呼声越来越高，再加上 NVIDIA 工程师的鼎力配合——为 Knowhere（Milvus 索引引擎）减少了最新的 RAFT 算法反对，使得 Milvus 不仅加回了 GPU 反对，而且还以最快的速度反对了业界最新的算法。经测试，GPU 版本相较于 CPU HNSW 索引有了 3 倍以上的 QPS 晋升，局部数据集有近 10 倍的晋升。
下表是 GPU-IVF-FLAT 和 HNSW 在 Milvus E2E 上的 QPS 数据，host 的 size 是 8c32g，NVIDIA A100 GPU。NQ 为 100：
Arm64 反对
随着 Arm64 CPU 的遍及水平越来越高，泛滥云厂商也纷纷公布了基于 Arm64 CPU 的实例。为此，从 Milvus 2.3.0 开始，Milvus 不仅会公布 Amd64 镜像，也会公布官网 Arm64 镜像，这一优化也可能帮忙 macOS 用户更地开发测试 Milvus。
QueryNodeV2
QueryNode 是继 QueryCoord 之后，第二个重写的服务。
为什么要重写 QueryNode？老版本有哪些问题？开展来讲能够写成万字小作文。简略来说，QueryNode 承当了整个 Milvus 零碎中最重要的检索服务，其稳定性、性能、扩展性对 Milvus 至关重要，但 QueryNodeV1 存在状态简单、音讯队列反复、代码构造不清晰、报错内容不直观等问题。在 QueryNodeV2 的新设计中，咱们从新梳理了代码构造、将简单的状态改为无状态的设计、移除了 delete 数据的音讯队列缩小了资源节约，在后续继续的稳定性测试中，QueryNodeV2 的体现更加优异。
IndexCoord 和 Datacoord 合并
Indexcoord 和 Datacoord 在 2.3.0 版本中被合并，这简化了 Milvus 部署的复杂度，也升高了元信息在不同 coord 之间通信的老本。在接下来的版本中，datanode 和 indexnode 的局部性能也将被合并。
基于 NATs 的音讯队列
Milvus 是基于日志的架构，音讯队列的扩展性、性能、稳定性对 Milvus 而言至关重要。此前，为了疾速实现 2.x，咱们抉择了业内支流的 Pulsar 和 Kafka 作为外围的 Log Broker。在理论运维的过程中，咱们也发现了不少外置音讯队列的局限性，一是在多 topic 场景下的稳定性问题，二是大量反复音讯时的去重以及空载时的资源耗费问题，三是二者都与 Java 生态绑定较严密 Go SDK 保护不是很踊跃。
在此状况下，一个更合乎 Milvus 需要的 Log Broker 显得至关重要，通过调研和测试，咱们选定 NATs + Bookeeper 的形式作为自研的 Log Broker，这更贴合 Milvus 的应用场景。目前，NATs Log Broker 还处于试验阶段，欢送有趣味的同学尝试以及反馈问题。
02.New Feature
Upsert 性能
反对用户通过 upsert 接口更新或插入数据。已知限度，自增 id 不反对 upsert；upsert 是外部实现是 delete + insert 所以性能上会有肯定损耗，如果明确晓得是写入数据的场景请持续应用 insert。
Range Search 性能
反对用户通过输出参数指定 search 的 distance 进行查问，返回所有与指标向量间隔位于某一范畴之内的后果。例如：
// add radius and range_filter to params in search_params
search_params = {"params": {"nprobe": 10, "radius": 10, "range_filter" : 20}, "metric_type": "L2"}
res = collection.search(
vectors, "float_vector", search_params, topK,
"int64 > 100", output_fields=["int64", "float"]
)该例子中就会返回间隔在 10~20 之间的向量。须要留神的是不同的 metric 计算间隔的形式不同，所以值域、排序逻辑各异，须要具体理解每个 metric 的特点之后再应用此性能。此外，RangeSearch 仍然具备最大返回后果不超过 16384 条的限度。
Count 接口
为了计算 collection 中的数据行数，很多用户会应用 num_entities 接口，然而此接口须要手动调用 flush 之后能力计算精确，但频繁 flush 会造成大量小文件刷盘，对 Milvus 的性能和稳定性都有较大影响。所以在此版本中提供了 count(*) 表达式，能够实时计算精确的 collection 行数。count 操作较为耗费资源，不倡议大量并发调用。
Cosine metrics
Cosine 间隔在大模型畛域有着宽泛的利用，尤其是在大模型畛域，Cosine Metrics 简直是掂量向量近似度的事实标准。Milvus 2.3.0 版本原生反对了 Cosine 间隔，用户不再须要通过向量归一化计算 IP metrics 来应用 cosine 间隔。
查问返回原始向量
出于查问性能的思考，之前的版本中 Milvus 不反对返回原始向量，此版本中补齐了该性能。须要留神的是，返回原始向量会有二次查问产生，所以对性能会产生较大影响，如果是性能 critical 场景，倡议应用 HNSW、IVFFLAT 等蕴含原始向量的索引。
目前，局部量化的索引，如 IVFPQ，IVFSQ8 不反对获取原始向量，对于具体哪些索引反对返回原始向量请参考 https://github.com/zilliztech/knowhere/releases.
ScaNN 索引
Milvus 目前反对了 Faiss 中的 FastScan 算法，在各项 benchmark 中有着不俗的体现，比照 HNSW 有 20% 左右晋升，约为 IVFFlat 的 7 倍，同时构建索引速度更快。ScaNN 在算法上跟 IVFPQ 比拟相似，聚类分桶，而后桶里的向量应用 PQ 做量化，区别是 ScaNN 对于量化比拟激进，搭配上 SIMD 计算效率较高，然而精度损失会比拟大，须要有原始向量做 refine 的过程。
下表是 ScaNN、HNSW 和 IVFFLAT 在 Cohere1M（768 维）的数据集下的性能体现，数据来自于 VectorDBBench。
Iterator
Pymilvus 中提供了 iterator 接口，能够通过迭代器的形式拉取数据，Query 和 Range Search 场景下，通过迭代器能够获取超过 16384 条数据限度的数据。Iterator 相似于 ES 的 scroll 接口和关系数据库中的 cursor，比拟适宜后盾批量解决数据。
Json Contains
Milvus 2.3.0 反对了 Json 数组 contains 表达式，能够反对判断一个 json 数组是否蕴含了一个元素或者一组元素。具体文档请参考 https://milvus.io/docs/json_data_type.md。
CDC 反对
Change Data Capture 是数据库系统中很通用的性能，能够用于跨机房主备数据同步、增量数据备份、数据迁徙等场景，得益于 Milvus 基于日志的架构很容易实现此性能。Milvus 的 CDC 代码在 https://github.com/zilliztech/milvus-cdc.
03.Enhancement
MMap 技术晋升数据容量
MMap 是 Linux 内核提供的技术，能够将一块磁盘空间映射到内存，这样一来咱们便能够通过将数据加载到本地磁盘再将磁盘 mmap 到内存的计划晋升单机数据的容量，通过测试应用 MMap 技术后数据容量晋升了 1 倍而性能降落在 20% 以内，大大节约了整体老本，对于老本敏感的用户欢送试用此性能。
filter 场景性能晋升
对于标量向量的混合查问场景，Milvus 的执行打算是先执行标量过滤再执行向量检索，这就意味着标量过滤之后会有大量的数据被过滤掉，如果过滤掉的数据过多会引起向量索引性能急剧下降，通过优化 HNSW 索引的数据过滤策略，2.3.0 中优化了此场景中的性能。除此之外，通过引入手动的向量化执行技术，标量数据过滤的速度也失去了大幅晋升。
Growing 索引
Milvus 的数据分为两类，别离为已索引的数据和流式数据。对于已索引的数据天然能够应用索引减速查问，但流式数据只能应用逐行暴力检索，对性能影响较大，为了解决此类问题在 2.3.0 中退出了 Growing index，主动为流式数据建设实时索引，保障查问性能。
多核环境资源利用率晋升
向量近似计算是计算密集型的工作，CPU 使用率是十分重要的指标，在 CPU 核数较多的状况下可能会呈现 CPU 使用率无奈超过 70% 的状况，通过优化 Milvus 2.3.0 可能更加充分利用好 CPU 资源实现性能晋升。
04. 稳定性
New load balancer
在 2.1.0 版本中，Milvus 反对了内存多正本，用户能够通过多正本的形式晋升 QPS。通过半年多的生产实践，收到了很多来自社区的反馈，其中次要集中在增加正本后 QPS 没有立即晋升、节点下线后零碎复原稳固工夫较长、节点之间负载不平衡、CPU 使用率不低等问题。这些问题归因到一起能够认为是负载平衡逻辑鲁棒性低，故障恢复能力较弱的问题，通过从新设计的负载平衡算法，采纳基于负载的动静负载平衡算法，可能及时的发现节点高低线、负载不平衡等景象及时调整申请调度。通过测试能够在秒级发现故障、负载不平衡、节点上线等事件，及时调整负载。
05. 可运维性
动静配置
批改配置是运维、调优数据库中的常见操作，从此版本开始 Milvus 反对动静批改配置项而无需重启集群，反对的形式有两种一是批改 etcd 中的 kv，二是间接批改 Milvus.yaml 配置文件。须要留神的是并不是所有的配置项都反对动静配置，详见 Milvus 文档 https://milvus.io/docs。
Tracing 反对
通过 tracing 发现零碎中的瓶颈点，是调优的重要伎俩，从 2.3.0 开始 Milvus 反对 Opentelemetery tracing 协定，反对此协定的 tracing collector 例如 jaeger 都能够接入观测 Milvus 的调用门路。
Error Code 加强
团队从新梳理了 Milvus 的 error code 以及设计了新版 error code 的架构，这次降级后，Milvus 的报错会更清晰。
06. 工具降级
Birdwatcher tool 降级
配套的 Birdwatcher 在这几个月中通过继续的演进，减少了泛滥性能，例如：
- 反对 restful API，更不便集成到其余诊断系统中
- 反对 pprof 命令，更不便的与 go pprof tool 集成
- 减少 storage analysis 命令剖析存储占用
- 与 2.3.0 的 event log 模式集成，反对通过结构化的数据分析 Milvus 外部事件，晋升剖析日志效率
- 反对批改 / 查看 etcd 中的配置
能够说，降级后的 Birdwatcher 性能泛滥，对须要深度运维 Milvus 的用户很有帮忙。将来，Birdwatcher 还会减少更加有用的命令，欢送大家试用。
Attu 降级
全新设计了 Attu 界面，用户体验更敌对：
07.Break Change
移出 Time travel 性能
因为 Time travel 性能简直没有用户应用，且 time travel 性能对 Milvus 的零碎设计提出了较大挑战，先临时废除。
移出 CentOS7 反对
因为 centos 官网对 centos7 的反对行将到期，而且 centos8、centos9 仅有 stream 版本，官网并未提供正式的 docker 镜像，所以 Milvus 放弃对 centos 的反对，改为应用 Amazonlinux 发行版进行代替。此外，基于 ubuntu20.04 的镜像仍旧是 Milvus 的主推版本。
删除了局部索引和 Metrics 反对
咱们删除了包含 Annoy 索引和 RHNSW 索引，以及 binary 向量下的 Taninato、Superstructure 和 substructure 间隔。
以上就是本次 Milvus 2.3.0 文字发布会的全部内容，如果大家还有不了解的中央，能够点击链接观看解析视频。
接下来咱们也会针对重点性能进行具体解读，欢送大家关注后续文章。当然，也期待 Milvus 的社区用户尝鲜，遇到问题尽快在 GitHub 提交 issue 反馈，心愿咱们独特把 2.3.0 版本打磨得更加杰出！
🌟「寻找 AIGC 时代的 CVP 实际之星」专题流动行将启动！
Zilliz 将联合国内头部大模型厂商一起甄选利用场景，由单方提供向量数据库与大模型顶级技术专家为用户赋能，一起打磨利用，晋升落地成果，赋能业务自身。
如果你的利用也适宜 CVP 框架，且正为利用落地和实际效果发愁，可间接申请参加流动，取得最业余的帮忙和领导！分割邮箱为 business@zilliz.com。
- 如果在应用 Milvus 或 Zilliz 产品有任何问题，可增加小助手微信“zilliz-tech”退出交换群。
- 欢送关注微信公众号“Zilliz”，理解最新资讯。
本文由 mdnice 多平台公布