Milvus

具体内容参考：https://github.com/milvus-io/milvus/issues/26701 我先尝试重启了几次 etcd 然而没用，我就把长久化卷给删除了，删除之后，整个 milvus 的汇合都不见了 为什么？因为 milvus 集群把有哪些汇合等元信息记录在 etcd 中

答案是 255 个字符

应用上面的 docker-compose 脚本，能够一键启动能够应用 milvus 单机版 version: "3.5"services: etcd: container_name: milvus-etcd image: quay.io/coreos/etcd:v3.5.0 restart: always environment: - ETCD_AUTO_COMPACTION_MODE=revision - ETCD_AUTO_COMPACTION_RETENTION=1000 - ETCD_QUOTA_BACKEND_BYTES=4294967296 - ETCD_SNAPSHOT_COUNT=50000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd logging: driver: "json-file" options: max-file: "1" max-size: "50m" minio: container_name: milvus-minio image: minio/minio:RELEASE.2022-03-17T06-34-49Z restart: always environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin ports: - "9001:9001" volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data command: minio server /minio_data --console-address ":9001" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] interval: 30s timeout: 20s retries: 3 logging: driver: "json-file" options: max-file: "1" max-size: "50m" standalone: container_name: milvus-standalone image: milvusdb/milvus:v2.2.2 command: ["milvus", "run", "standalone"] restart: always environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus ports: - "19530:19530" - "9091:9091" depends_on: - "etcd" - "minio" logging: driver: "json-file" options: max-file: "1" max-size: "50m" zilliz_attu: container_name: zilliz_attu image: zilliz/attu:v2.2.4 restart: always environment: HOST_URL: http://192.168.38.191:8000 MILVUS_URL: 192.168.38.191:19530 ports: - "8000:3000"networks: default: name: milvus留神，把其中的 192.168.38.191 换成你本人的机器的本地 IP ...

应用上面的 docker-compose 脚本，能够一键启动能够应用 milvus 单机版 version: "3.5"services: etcd: container_name: milvus-etcd image: quay.io/coreos/etcd:v3.5.0 environment: - ETCD_AUTO_COMPACTION_MODE=revision - ETCD_AUTO_COMPACTION_RETENTION=1000 - ETCD_QUOTA_BACKEND_BYTES=4294967296 - ETCD_SNAPSHOT_COUNT=50000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd minio: container_name: milvus-minio image: minio/minio:RELEASE.2023-03-20T20-16-18Z environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data command: minio server /minio_data healthcheck: test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] interval: 30s timeout: 20s retries: 3 standalone: container_name: milvus-standalone image: milvusdb/milvus:v2.2.6 command: ["milvus", "run", "standalone"] environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus ports: - "19530:19530" - "9091:9091" depends_on: - "etcd" - "minio" zilliz_attu: container_name: zilliz_attu image: zilliz/attu:v2.2.4 restart: always environment: HOST_URL: http://192.168.38.233:8000 MILVUS_URL: 192.168.38.233:19530 ports: - "8000:3000"networks: default: name: milvus留神，把其中的 192.168.38.233 换成你本人的机器的本地 IP ...

Q：milvus 应用 l2 欧式间隔计算向量的间隔，计算出来的间隔的最大值是多少？A：归一化之后，最大值是4 Q:归一化的是怎么操作的？调用 collection.search 之后取得的向量，曾经是归一化了吗？还是须要本人对 milvus 的搜寻后果再做归一化？ A:须要本人的对向量做归一化 Q:有样例代码吗A:能够用np.linalg.norm Q:归一化是查问之前做，还是获取查问后果后，对间隔做归一化？A:查问之前做，查问的向量，和入底库的向量，都须要做归一化 import numpy as npimport milvus# 连贯 Milvus 服务器client = milvus.Milvus(host='localhost', port='19530')# 定义查问向量query_vector = np.array([0.1, 0.2, 0.3, 0.4, 0.5], dtype=np.float32)# 查问向量归一化query_vector_norm = query_vector / np.linalg.norm(query_vector)# 构建查问参数search_param = { "metric_type": "L2", "params": {"nprobe": 16}}# 在 milvus 中查问向量search_result = client.search(collection_name='my_collection', query_records=[query_vector_norm.tolist()], top_k=10, params=search_param)# 解决查问后果for result in search_result: print(result.id, result.distance)

coord 是一个过程 node 也是一个过程 比方一个 datanode 要承受来自内部的写入，写入都须要通过 datacoord 转发给 datanode 吗？ 相干文档：https://milvus.io/docs/four_layers.md Q：milvus 的 coord 和 node 是什么关系？ 比方一个 datanode 要承受来自内部的写入，写入都须要通过 datacoord 转发给 datanode 吗？ A：在 Milvus 中，coord和node是指不同的组件。coord是协调节点，次要负责协调集群中不同组件之间的通信，例如indexcoord、datacoord和querycoord之间的协调。而node是数据节点，次要负责存储和治理数据。 在 Milvus 中，数据写入操作须要先通过datacoord进行转发，而后由具体的datanode进行接管和解决。datacoord负责管理数据的划分和调配，决定哪个datanode应该接管哪些数据，并且把写入申请发送给相应的datanode，最终实现数据的写入。因而，在进行数据写入时，数据须要通过datacoord的转发，而后由相应的datanode进行接管和解决。 kafka或者pulsar在 Milvus 中次要作为音讯队列，用于数据的异步写入。在数据写入时，Milvus首先将写入申请发送给pulsar或者kafka，而后再通过datacoord转发给相应的datanode进行接管和解决。通过这种形式，Milvus实现了数据的异步写入，进步了数据写入的效率和吞吐量。 Q：milvus 的 coord 是单点的吗？ 比方对于 datacoord 和 datanode，datanode 能够有多个，datacoord也能够有多个吗？ A：在 Milvus 中，每个 Coord 节点都是单点的，也就是每个 Coord 只有一个实例在运行。然而，每个 Coord 类型的节点都能够有多个实例，以进步零碎的可用性和性能。 在 Milvus 2.x 中，能够有多个 DataCoord 实例和多个 IndexCoord 实例来进步零碎的可用性和性能。多个 DataCoord 实例独特负责写入数据，并通过相互之间的协调来保证数据一致性。多个 IndexCoord 实例独特负责管理索引，并通过相互之间的协调来保障索引一致性。 对于 QueryCoord，它是作为查问的入口节点，每个查问申请都须要通过 QueryCoord 进行路由和调度。目前 Milvus 中只反对一个 QueryCoord 实例。 ...

Milvus 2.x 反对程度扩大，能够通过增加新的 DataNode 和 IndexNode 来实现。具体步骤如下： 启动新的 DataNode 和 IndexNode，确保它们与现有节点的配置雷同，包含 CPU、内存、存储等。将新节点的 IP 和端口增加到现有节点的配置文件中，配置文件位于 Milvus 装置目录的 conf 目录下，如 milvus.yaml。重启现有节点，使其加载新的节点配置。应用 Milvus Python SDK 或者其余语言的 SDK 连贯到 Milvus 集群，并将新节点的地址增加到 SDK 的连贯参数中。注意事项： 每个节点的版本必须统一，否则可能会导致不兼容的问题。增加新节点时，须要确保节点之间的网络互通，能够通过 ping 命令或者其余网络工具来查看。增加新节点时，须要留神数据迁徙的问题。如果须要将数据从旧节点迁徙到新节点，能够应用 Milvus 提供的数据迁徙工具 milvus_data_migrate。在数据迁徙期间，须要确保集群的稳定性，防止对业务产生影响。milvus2.x 的 Querycoord 能够程度扩大吗？ 在 Milvus 2.x 中，QueryCoord 不反对程度扩大。QueryCoord 作为一个负责查问协调的组件，通常只须要部署一个实例，因而不须要扩大。如果须要进步查问能力，能够减少 DataCoord 的实例数以及降级硬件等形式来进步整个零碎的查问性能。 milvus2.x 集群是 master-slave 架构吗？ Milvus 2.x 采纳的是分布式架构，没有 master-slave 架构。在 Milvus 2.x 中，数据被宰割为多个分片，并调配给不同的 DataNode 进行存储。每个 DataNode 都是平等的，没有主节点和从节点之分。查问申请则由 QueryNode 负责解决，每个 QueryNode 都能够解决查问申请。同时，还有 IndexNode 负责管理索引，每个 IndexNode 同样也是平等的。整个集群的治理和协调则由 etcd 进行治理。 ...

Milvus 的可能性远超你的设想！ 近期，Zilliz 在杭州举办了 2023 年首期 Arch Meetup，在现场，Zilliz 客户工程师张翔、Milvus 社区 Committer 嵇斌、知衣科技研发负责人胡海滨进行了干货满满的分享，Zilliz 云平台研发总监谢宇在演讲的同时更是走漏了 Zilliz 行将在国内提供 SaaS 服务的最新动向。从他们的分享中，咱们看到了 Milvus 在不同维度的更多可能性。 杭州 Arch Meetup 流动现场 01.Milvus ：更快、更稳、更高 流动伊始，Zilliz 客户工程师张翔形象地借用冰箱存储食物来比喻结构化数据和非结构化数据在计算上的不同，从而引出了在 AI 时代非结构化数据可能转为向量检索计算的话题，在此状况下，数据的价值得以被开掘，Milvus 作为根底工具能够更好地为 AI 赋能。 张翔示意，2022 年以来，Milvus 2.X 共迭代 3 个大版本 8 个小版本，在保障版本和性能疾速迭代过程的同时，着重在性能和稳定性层面进行了大量优化迭代。这种疾速、高效、稳固、易用的能力会在后续的版本迭代中始终加码。张翔走漏，后续 Milvus 还将退出 GPU 反对、SQL 反对、主备容灾、Schema 更改等性能。 此外，张翔也同步了对于社区倒退的状况，据悉，目前 Milvus 社区在 GitHub 的 Star 数量曾经超过 15.3k，微信用户数量超 3k，Slack 用户数超 2k。他示意在开源技术的背地，离不开社区搭档的共同努力，心愿彼此能够互帮互助、共同进步，让 Milvus 社区更上一层楼。 02.需要造就的社区 Committer Milvus Committer 嵇斌和 Milvus 结缘于 1.1.0 版本，最后嵇斌所在的公司心愿在外部做一个改善代码品质的外部我的项目，须要用一些模式特色对历史的代码做比对，其中须要用到向量比对技术。为此，嵇斌和团队尝试了各种开源计划，机缘巧合下理解到了 Milvus。 ...

【What's New】 Milvus benchmark 白皮书公布[1] 。 与 Milvus 2.1 相比，Milvus 2.2 在 cluster 模式下的 QPS 减少了 48％ 以上，在 standalone 模式下减少了 75％ 以上。 【Core Updates】 其一，#22583[2] 在 2.3 版本中，Milvus 反对读取多个配置文件，别离是 user.yaml、default.yaml、milvus.yaml，优先级是 user > defualt > milvus，这个设计带来的益处是，用户只需将自定义配置记录在 user.yaml 中，不必批改 milvus.yaml，就不会受到 Milvus 降级、配置变更等场景的影响。 其二，#22376[3] 在 2.3 版本中，Milvus 会原生反对阿里云 OSS 对象存储。 其三，#22501[4] #22672[5] #22698[6] 在 2.3 版本中，错误码重构曾经开始，根底框架曾经搭建结束，会继续对现有错误处理进行重构。这次设计参考了 CockroachDB 的错误处理教训，咱们首先定义了 Leaf Errors。Leaf Error 是零碎与外界交互的边界处，不可合成的 error，下层的 error 通过 wrap leaf error 与其它信息组合失去。具体能够参考代码: internal/util/merr/errors.go 【Knowhere】 对于 Knowhere，#717[7]#721[8] GPU 反对继续迭代中，预计在 Milvus 2.3 版本中一起公布。 ...

很喜爱这样一句话：Be a serendipper，and find your own serendipity! 能够了解为：做一个长于发现美好事物的人，找到属于你本人的那些美妙。每个人的生存中都有 Serendipity，有时能被咱们一眼看到，有时又会藏在某个角落，期待被咱们发现。这个三八节，咱们想聊聊专属女性的 Serendipity。不同于以往，这次话题不仅有 4 位闪闪发光的女同事加入，也有 3 位长于发现身边女性闪光点的男同事退出，大家从各自的视角分享了一些与女性 Serendipity 无关的小故事。 【你不晓得的 Serendipity】 “女生不适宜学同传？”Technical Writer - Angela 我始终很喜爱英语，所以大学时果决抉择了英语专业，过后给本人定的小指标是研究生能抉择同声传译业余。大二实习的时候，所在公司的 leader 无心中聊起这个事件，他劝我不要，因为过后对于“同传对膂力耗费十分大，女生不适宜”的说法很是风行。听到这种话，我的第一反馈是不服气，因为同畛域内有做得十分胜利的女性。不过，leader 否定的态度在肯定水平上激发了我不服输的精力，过后就暗下决心，不论他人怎么看，我肯定要做本人想做的事件。 最终，我胜利申请到英国一所心仪学校的同传业余，起初还在联合国做过相干实习。直到现在，我也十分动摇地认为，同传不分性别。 说起身边的和女性相干的 Serendipity，我第一个想到的是妈妈。我的妈妈是一名老师，不是那种传统意义上“准点上班”的老师，她把很多精力都放在了学生身上。神奇的是，她仿佛永远能量满满，把工作、家庭的各种事件都打理得东倒西歪。每当我遇到一些难题，感觉进行不上来的时候，给妈妈打个电话，她传递出的能量总能感化我，让我感觉，也没什么大不了嘛。 “我是女生，但我喜爱打篮球”Software Engineer - 陈室余 我的他乡在云南，不晓得是什么起因，大家都很喜爱打篮球。能够设想一下，我和一群小伙伴打篮球打到挥汗如雨的样子。那时候的我，素来没有想过篮球是一项“偏差男性的静止”。直到上了大学，看到室友们得悉我打篮球时诧异的样子，才意识到这有多“特地”。 起初，我体育课选修了篮球，课堂上女生的数量寥寥无几。打篮球的时候的确会感觉不如之前在家那样畅快，不过侥幸的是，咱们的篮球老师是个很酷的女生，咱们会一起打球、打较量。男生对咱们的态度也还好，开始还会关照咱们一下，然而很快就进入状态、不分你我了。我当初仍然喜爱打篮球，尽管因为工夫起因很久没有体验了。不过，如果有机会，还是想和以前的小伙伴一起，来一场无关其余的篮球赛。 在我身边有很多“女性专属的 Serendipity”，印象比拟深的是我的一位好敌人，从她身上你能感触到对生存的继续酷爱。每周她都会跟我分享本人插花的照片，她的办公桌上永远摆着一束散发向上生命力的鲜花。而她自己也一样，踊跃阳光、生机满满，那是我很向往的状态。 “每个人身材的出厂设置都不同呀”Talent Acquisition Lead - Iris 我很喜爱练瑜伽，大部分的人对于瑜伽的刻板印象是拉伸为主，对女生的刻板印象也是比拟柔软却不足力量。而我恰恰相反，我的身材天生力量强于柔韧，所以一些倒立、手撑持的动作对于我来说不须要特意练习就能够实现；而一些看似简略的拉伸，却就十分苦楚了。有时候在朋友圈发一些拉伸的照片，会有人问“怎么练了那么久还是那么硬？”对此，我的答复是，因为每个人的身材出厂设置都是不同的呀^ ^。练瑜伽的过程，是一个自我了解、接收、革新的过程。当我分明为本人的身材花了多少工夫和致力、我的身材又将会有怎么变动的时候，“他人”的“刻板印象”对我来说，又有什么须要在意的呢？ 提起 Serendipity，我有一位十分喜爱的瑜伽老师，名叫 Christina。每次上课，她总是化着淡妆，梳着参差的头发，搭配着不同色彩的瑜伽服。她是风趣的，会在课前课后开一些小玩笑，让练习的气氛变得轻松起来；她是严格的，在课堂上她会揭示同学，如果老师帮你调整过一次动作，那么下次再做就要记住；她是谨严的，对本人课堂上给出的口令，有着完美主义的要求。我想，带给我力量的，素来都不是语言，而是老师在耳濡目染中的行为，让我向往的同时也缓缓修改本人。心愿将来也能够通过我这个载体把这份力量传递进来。 “文科生意外闯入技术新世界”PR Supervisor - Kiki 刚毕业的时候我在一家外资公关公司做高端生存形式流传工作，服务一些国内豪华酒店、卫浴品牌。做了一段时间感觉酒店业仿佛有些过于变化无穷了，可能十年前的酒店公关做的事件和当初没有什么区别。机缘巧合之下，我接触到了上海 Linux 开发者社区的一些线下 Meetup。在那里，大家每天都在探讨新的技术、产品和商业模式，我感觉这太乏味了，很想成为他们中的一员。于是，我果决跳槽去了一家总部在硅谷的科技公关公司，开启了我的技术品牌流传之路。在此期间负责过一家百年工业巨头转型成为智慧修建高科技企业的品牌降级，也帮忙过新兴的无人驾驶公司从零到一打造技术影响力，当初来看这些经验对我当初的工作都十分有价值。 我的 Serendipity 比拟特地，她是我在工作过程中意识的敌人。那时候，我刚进入 Startup 做市场类的工作，她会从销售的角度进去，带我去走访客户理解产品的场景和价值，一起实现了人生中第一场开发者 Meetup。在她的身上我意识到职场中的“ Girls help girls ”是实在存在的，不要总想着成就本人，有时候试着让你身边的人 look smart，比方为他人发明火花；在须要合作的中央适当放弃心田 ego 过于弱小的局部，简略来说就是在某些时候不要把本人的想法太当回事儿。 ...

在你眼中 Milvus 意味着什么？全球化的大型开源我的项目？AI 基础设施？SaaS 服务？还是应用场景丰盛的向量数据库？ 一千个社区用户眼中有一千个 Milvus，也带来了一千个与 Milvus 无关的故事。这背地或藏着对开源事业的激情，或带着 Milvus 在实战中的思考，又或是致力向 Milvus 用户及开发者提供更好服务的初心。 Zilliz 始终心愿凝听这些贵重的教训与思考，2023年的首期 Arch Meetup，咱们邀请到 Milvus 社区 Committer 嵇斌、知衣科技研发负责人胡海滨，他们将在现场分享在 Milvus 社区的经验以及 Milvus 在服装畛域的利用实例。同时，Zilliz 云平台研发总监谢宇也将来到现场，揭秘全托管 Milvus 服务 Zilliz Cloud 的最新进展。此外，如果你对 Milvus 的我的项目及社区有任何疑难，Zilliz 客户工程师张翔亦守候在现场，随时筹备答疑解惑。欢送各位开发者和用户来到现场，体验一场畅所欲言、思维火花四溅的 Milvus 之旅。 李白桃红，杭州等你！3月11日，咱们不见不散！ 流动工夫3 月 11 日下午 14:00-17:00 流动地点杭州市余杭区杭州西站负二层地铁 L 口 (火车西站地铁站步行 30 米) 幻想加空间 惊喜福利咱们为每位来到现场的开发者筹备了精美的签到伴手礼和茶歇，现场参加互动还将有机会取得 Zilliz 最新周边哦！ 【Arch Meetup】Arch Meetup 是 Zilliz 发动的专一探讨向量数据库与 AI 根底软件研发的系列技术沙龙。在 Arch Meetup，数据库、AI 等畛域的技术专家与开发者可能找到气味相投的搭档，自在分享最新的技术趋势、生产实践和 AI 利用在各行各业的落地案例，并通过现场互动为参会者答疑解惑。

/volumes/milvus/rdb_data 这个目录占用最多 次要是.sst文件 用docker-compose启动的 是 milvus2.1 的 bug 降级到 2.2 就好了

不反对 比方我当初一个汇合外面反对两个向量字段，会报错: pymilvus.exceptions.MilvusException: <MilvusException: (code=1, message=multiple vector fields is not supported, fields name: image_vector, image_vector2)>

01背景随着计算机技术及机器学习技术的倒退，特征向量作为一种多媒体数据（文本、语音、图片、视频）的形容形式，逐步成熟起来，而向量检索（向量类似计算）也逐步成为一种通用的需要。 向量检索在之家领有十分宽泛的利用场景，如举荐在线业务非明文召回场景，类似视频/图片/音频去重场景等等。截止到 22 年初，业务方部署了 9 个向量检索引擎去检索向量数据。不过，随着向量检索需要减少，许多问题也接踵而来： 资源节约每个业务线都会搭建本人的向量检索引擎，资源没有对立治理，会呈现不必要的资源节约。 保护老本保护向量检索引擎会有一些技术门槛，业务方无奈分心于解决业务，且Vearch社区不沉闷，基本上碰到问题都须要业务方本人去解决或者想方法绕过。 开发成本为了适配新的召回需要，每次上线新的向量接入需要都须要业务方定制化开发。无奈更敏捷地反对在线业务的需要变更。 性能Vearch的性能也越来越满足不了在线业务的需要，导致在线召回我的项目有较高的超时率，影响线上试验及模型成果。 02技术选型之家数据开发团队在 22 年初开始筹备搭建向量检索平台，通过一系列开源计划的调研选型后，咱们最终抉择了 Milvus 作为向量检索平台的底层引擎。Milvus 杰出的架构无论是在稳定性，高可用性，可维护性，功能性及性能等方面都有十分不错的体现。 咱们来看下 Milvus 2.x 版本的架构实现特点： 微服务Milvus 将服务拆成多个角色，每个角色职责划分绝对独立，这样每个角色的源码浏览起来非常容易。简略介绍下 Milvus 的角色职责： ETCD:负责存储元数据对象存储:负责存储向量数据Proxy: Milvus 对立的拜访层DataNode/DataCoord: 负责向量的写入IndexNode/IndexCoord:负责向量索引的构建QueryNode/QueryCoord: 负责向量的查问RootCoord: 负责解决 DDL 去协调其余 Coord，全局工夫散发，保护以后元数据快照其中IndexNode/QueryNode/DataNode 这些角色是理论工作的 Woker 节点，IndexCoord/QueryCoord/DataCoord 是负责协调 Woker 节点，是将工作 handoff 给其余角色的节点。 反对云原生Milvus 服务自身是没有状态的，数据存储在对象存储，元数据会寄存在 ETCD。原生反对 K8s 部署集群部署，咱们能够依据集群或者个别角色的负载去动静扩缩资源。 向量操作读/写/建索引之间过程级别隔离如上图，向量读/写/建索引都是通过不同的节点实现，这样操作之间都是通过过程之间隔离，不会抢占资源，相互影响。 此外，Milvus 还能够在查问的时候指定不同的一致性级别。在实在的业务场景中，一致性要求越强，查问对应的响应工夫也会变长。用户能够依据本人的需要抉择不同的一致性级别。除了 Milvus 杰出的架构能力之外，Milvus 十分沉闷的社区及其背地优良的商业公司 Zilliz 也是咱们抉择 Milvus 的重要起因。 03向量检索平台介绍目前向量检索平台曾经日益成熟，反对了 30 多个离/在线需要。在性能，稳定性，资源节约方面都十分不错的晋升。 基础设施部署咱们通过革新 Milvus 原生的部署形式，将 Milvus 集群部署在之家云 K8s 集群中。因为 Milvus 服务自身是无状态的，在 K8s 上，咱们能够依据业务的查问写入需要，灵便地扩缩 Milvus 的服务节点，节约服务器老本。 ...

近日，Milvus 2.2.0 公布，新版本里反对了许多激动人心的性能，包含：磁盘索引（DiskANN）、从文件中批量导入数据（bulk_insert）、基于角色的访问控制（RBAC）、汇合生存工夫（TTL）等。不少社区的小伙伴对新版本都曾经蠢蠢欲动。不过与以往版本间接降级镜像的简略操作相比，因为 2.2 和 2.1 的元数据产生了变动，以及接口侧的一些行为产生了扭转，所以降级的手续要比以前多一丢丢了。上面就让咱们来看看如何优雅地将 Milvus 从 2.1.x 版本升级到 2.2.x 版本。 整个降级过程次要波及两局部的变更，别离是部署侧和接口侧。部署侧次要是镜像和元数据的变更，接口侧次要是 sdk 的行为变更，从而须要在原来的业务代码上做一些调整。接下来咱们会对这两局部别离介绍。本文以 Milvus 2.1.4 降级到 Milvus 2.2.0 为例进行介绍，因为 2.1.0 到 2.1.4 之间的所有版本，数据和接口都是兼容的，所以其余 2.1.x 版本的降级都是相似的。 01部署侧降级Milvus 2.2.0 以前，RootCoord 同时负责管理汇合的元信息以及索引的元信息，IndexCoord 只负责索引工作的调度。为了让索引元信息与 RootCoord 解耦，Milvus 2.2 决定把原来由 RootCoord 治理的索引元信息转移到由 IndexCoord 治理。所以，部署侧降级的外围工作就是将 Milvus 2.1.4 的元数据结构批改为 Milvus 2.2.0 的元数据结构，并用新的 Milvus 2.2.0 镜像启动 Milvus 的各个组件。 因为 Milvus 具备单机和分布式两种状态，部署模式反对 docker compose、Helm、k8s operator，为了表述更加清晰，咱们应用表格来阐明各自的操作步骤和注意事项。 因为 APT/YUM 和 Ansible 不是社区举荐的支流部署模式，所以本次的降级实际暂不探讨这两种部署模式。 单机版 分布式 02接口侧降级API 层面，为了对立社区三大官网 SDK（Python SDK、Java SDK、Go SDK）的行为，以及对立用户对 Milvus 的应用标准，Milvus 2.2.0 对 create_index()、drop_index()、load()、release()、flush() 这几个接口做了限度和补充。归纳起来分为索引和数据加载以及数据落盘(flush)两大类。索引和数据加载 ...

01QueryCoord 组件介绍QueryCoord 是 Milvus 中查问集群的核心调度节点，在用户将一个 Collection Load 到内存中时，QueryCoord 负责将该 Collection 的 Segment 调度到 QueryNode 集群中，以反对后续的查问。 QueryCoord 最外围的操作有4种： Load：将资源加载到 QueryNode 中Release：将资源从 QueryNode 开释Handoff：应用新的 Segment C 替换旧的 Segment A，BBalance：在 QueryNodes 之间挪动 Segment此外，在 Milvus v2.1.0 咱们退出了内存多正本的性能，通过减少 Segment 在内存中的正本数量来晋升性能，进步可用性。 02为什么必须重构在 Milvus v2.1.x 中，咱们遇到了很多与 QueryCoord 相干的问题，其中不少问题无奈在现有的设计上彻底解决，也有不少问题因为此前的设计耦合，在修复时很容易引入其它问题。此前，有两类问题是最为常见，也最为辣手的： QueryCoord 在某个操作之后长时间无响应QueryCoord 有时无奈通过重启复原服务咱们在 Milvus v2.1.x 的开发过程中破费了大量的工夫去解决无响应相干的问题。这个问题并不只是代码的问题，从基本来说是 QueryCoord 试图提供的接口语义过于弱小，以至于根本无法简略实现咱们冀望的语义。 根本原因此前的 QueryCoord，试图为每一个接口都提供最终实现的语义，只有申请达到 QueryCoord，即便后续呈现谬误，QueryCoord 也会试图最终将这些申请实现。 此外，QueryCoord 会记录每个 Segment 所处的节点地位，并将这一信息长久化。当产生 Balance 之类的操作时，依据 RPC 是否胜利来决定是否要批改记录的地位信息。 咱们很快意识到这一做法是无奈做到精确的，因为 RPC 会有 false failure，QueryCoord 被动跟踪资源地位，并以 RPC 后果作为资源地位变动的根据，是必定会产生资源透露的。 ...

一、手写动静链接Milvus 代码库分为了 C++ 和 Go 两个局部，Go 局部负责零碎主体架构、分布式系统、存储/查问链路等，C++ 局部负责查问、索引引擎专一于单机场景下的高性能，两者之间通过 cgo 接口调用。 为了保护两种语言的代码，就须要退出两种语言的生态。Go 作为一个年老、古代的语言，开箱自带包治理、自动化测试框架和丰盛的规范库；而经典的 C++ 就走向了另一个极其，尽管有极致的性能和可控的内存治理，但生态过于碎片化。幸好在 build system 畛域，CMake 有成为事实标准的趋势。 Milvus 很天然的抉择 CMake 作为 C++ 构建零碎，通过编写 CMakeLists.txt 形容要生成的 library 和 headers，而 Go 则通过 cgo 接口链接到相应的 library，在晚期版本里是这样写的： /*#cgo CFLAGS: -I${SRCDIR}/../core/output/include#cgo darwin LDFLAGS: -L${SRCDIR}/../core/output/lib -lmilvus_segcore -Wl,-rpath,"${SRCDIR}/../core/output/lib"#cgo linux LDFLAGS: -L${SRCDIR}/../core/output/lib -lmilvus_segcore -Wl,-rpath=${SRCDIR}/../core/output/lib#include "segcore/collection_c.h"#include "common/type_c.h"#include "segcore/segment_c.h"*/import "C"import ( "errors" "fmt" "unsafe" "github.com/milvus-io/milvus/internal/util/cgoconverter")不难发现这样写有几个问题： 1. 不同操作系统须要指定不同的编译参数 2. hard code 库文件门路，耦合重大，不利于保护 以上两个问题绝对容易解决，在应用第三方 go library 时，问题会更难解决，例如 Milvus 应用了 https://github.com/tecbot/gorocksdb 作为 Go 的 rocksdb 接口。 ...

文档更新于 2.1.4 版本公布之际，很快乐和大家分享 Milvus 的新变动和产品的成长。Zilliz 合伙人兼技术总监 栾小凡继年初公布 Milvus 2.0 版本之后，在数百位 Milvus 社区贡献者六个月的共同努力下，咱们在早些时候公布了 Milvus 2.1 版本，通过两个月的数次迭代，版本趋于稳定，被国内外头部厂商信赖和抉择应用。 在此次大版本更新中，最为重要的两个关键词莫过于：易用性和性能。 为了可能买通算法工程师笔记本到海量向量召回生产场景的“最初一公里”，在这个令人激动的版本中，咱们除了在程序性能、可扩展性、安全性、可观测性方面做出了诸多改良之外，还减少了以下新个性：字符串数据类型、Kafka 音讯队列、Embedded 形式运行 Milvus。 性能晋升：3.2 倍只是开始相较于传统 KNN 检索，Milvus 此前提供的 ANN 检索形式尽管曾经带来了质的飞跃。然而，当用户面向亿级大规模向量数据的召回场景时，吞吐量和提早仍旧存在很大的挑战。 在 Milvus 2.1 中，咱们次要进行了五个方面的性能改良和性能晋升。 更高效的路由协定：5ms 检索提早在 Milvus 2.1 中，咱们设计了全新的路由协定，并在检索链路中去除了对音讯队列的依赖，让小数据集场景下的检索提早失去了大幅升高。结果显示，以后版本的 Milvus 在百万数据规模的测试中，提早可能达到 5ms 左右，足以满足搜寻、举荐等在线要害链路对于提早的刻薄要求。 更高性能的并发模型：3.2 倍性能晋升在 Milvus 2.1 中，咱们对并发模型也进行了调整。在以后版本中，咱们引入了新的代价评估模型和并发调度器。实现了两个要害能力：并发管制和小查问合并。 前者保障了咱们既不会存在大量并发申请争抢 CPU 和缓存资源的状况，也不会因为并发太少而导致 CPU 无奈被齐全利用；后者则是通过在调度器层面智能地合并申请参数统一的小 nq 查问，可能解决在查问 nq 较小、并发又十分高的场景下 Milvus 的性能压力。在这个场景下，业务不须要批改任何一行代码就可能取得 3.2 倍的性能晋升。 残缺的性能测试报告目前曾经在官网公开：《Milvus 2.1 Benchmark Test Report》。 平安高效的内存多正本机制在 Milvus 2.1 中，咱们引入了内存多正本机制。除了可能晋升零碎在小数据规模下的扩展性和可用性之外，还可能解决读 QPS 较高场景下的性能压力。 ...

作者：栾小凡 编者按： Deep Dive 是由 Milvus 社区发动的代码解析系列直播，针对开源数据库 Milvus 整体架构开放式解读，与社区交换与分享 Milvus 最外围的设计理念。通过本期分享，你能够理解到云原生数据库背地的设计理念，了解 Milvus 相干组件与依赖，理解 Milvus 多种利用场景。讲师简介： 栾小凡，Zilliz 合伙人、工程总监，LF AI & Data 基金会技术咨询委员成员。他先后任职于 Oracle 美国总部、软件定义存储守业公司 Hedvig 、阿里云数据库团队，曾负责阿里云开源 HBase 和自研 NoSQL 数据库 Lindorm 的研发工作。栾小凡领有康奈尔大学计算机工程硕士学位。 视频版解说请戳 https://www.bilibili.com/vide... 本期分享分为四个局部： 咱们为什么须要 Milvus ？为什么它被称为下一代人工智能基础设施？Milvus 2.0 的设计理念Milvus 2.0 的概览与模块划分Milvus 代码浏览注意事项咱们为什么须要 Milvus？非结构化数据处理流程Milvus 为解决非结构化数据的检索问题而生：海量的非结构化数据个别会存储在分布式文件系统或对象存储上，之后通过深度学习网络实现推理，将这些非构造数据转化成 embedding 向量，并在向量空间内实现近似性检索，从而发现数据背地的一些特色。 整个数据处理流程如下图所示。比方，有很多原始的食物图片，通过卷积神经网络做训练和推理，为每一幅照片得出一组向量，再把这些向量依照空间中的近似维度做排序，最初失去这样的后果：最下面一排是一些长得像薯条的货色，两头都是一些长得像拉面的货色，底下都是长得像寿司的货色。也就是说，图片这种非结构化数据，通过深度学习解决之后，转化成了embedding 向量，并通过在向量空间的近似度比对来表征其相似性，这在很大水平上能跟人类了解的近似度是高度一致的。 向量与标量传统的标量数据和 Milvus 面向的向量数据之间，到底有哪些不同呢？ 从基本操作上来讲，对于标量数据，针对数值类数据个别会做加减乘除的操作；对字符串类型的数据个别会做一些 term 的匹配， 或者一些相似 like 的近似匹配，抑或一些前缀匹配。 而针对向量数据而言，很少进行这种 100% 的齐全匹配，更多是看近似度，也就是高维空间下的间隔。较常见的间隔示意有余弦间隔、欧式间隔等。空间中向量之间的间隔，很大水平上能示意非结构化数据之间的类似度。 除了对数据的操作会有很大不同以外，数据的组织形式也会有很大不同。如，传统数据很容易比拟大小，无论是数值类，还是字符串，都能够通过二叉树或者 skip list 的形式排列组合，而后做二分查找。对于向量数据来讲，则更加简单，因为它维度较高，很难像传统的数值类数据一样通过排序的形式做减速，往往须要一些非凡的索引构造和存储形式。 常见的向量索引形式常见的向量的索引形式有哪些呢？ 1） FLAT file，也就是大家常说的暴力搜寻，这种形式是典型的就义性能和老本换取准确性，是惟一能够实现 100% 召回率的形式，同时能够较好地应用显卡等异构硬件加速。 ...

✏️ 编者按： 在历经六个月、9 个 RC 版本的迭代与寰球 1000 家用户的实战验证后，咱们隆重发表 Milvus 2.0 GA 版本正式公布。Milvus 研发总监栾小凡撰文，解析正式版本的八大新性能并展望未来倒退方向。 Dear Members and Friends of the Milvus Community: Today, six months after the first Release Candidate (RC) was made public, we are thrilled to announce that Milvus 2.0 is General Available (GA) and production ready! It's been a long journey, and we thank everyone – community contributors, users, and the LF AI & Data Foundation – along the way who helped us make this happen. ...