共计 2755 个字符，预计需要花费 7 分钟才能阅读完成。
相熟咱们的敌人都晓得，在 Milvus 和 Zilliz Cloud 中，有一个至关重要的组件——Knowhere。
Knowhere 是什么？如果把向量数据库整体看作漫威河汉护卫队宇宙，那么 Knowhere 就是货真价实的总部，它的次要性能是对向量准确搜寻其最近邻或通过构建索引进行低提早、近似的最近邻搜寻（ANNS）。
Knowhere 2.x 版本自 2022 年 7 月开始重构，通过屡次计划探讨、设计、开发和测试的迭代，终于随着 Milvus 2.3 和各位见面了。对于用户而言，相较于 1.x 版本，Knowhere 2.x 版本提供了更标准的接口以及更丰盛的性能，例如反对 GPU 索引、Cosine 相似性类型、ScaNN 索引和 ARM 架构等。对于开发者来说，降级后的 Knowhere 能够更不便地减少新的索引算法，利于前期保护。
接下来我将具体为大家介绍 Knowhere 2.x 的新性能、优化及设计理念。
反对 GPU 索引
Zilliz 始终都十分欢送内部开发者提出想法和奉献代码，此前，英伟达（Nvidia）公司在 Knowhere 2.x 版本奉献了其向量搜寻库 RAFT 中的 GPU_FLAT 和 GPU_IVFPQ 索引。GPU 强劲的算力在一些场景下能够显著地减速索引搜寻的过程。相较于 CPU 版本，Milvus 端到端性能在 Nvidia A100 上的吞吐量有了显著晋升（SIFT1M 近 70 倍）。GPU 索引具体内容请拜访 https://milvus.io/docs/install_standalone-gpu-docker.md。
反对 Cosine 相似性类型
在 Knowhere 1.x 版本上，如果想应用 Cosine 相似性类型，用户须要应用 Inner Product 相似性类型并在插入向量前进行归一化操作，使得其在数学上是等价的。这不仅对于用户有更高理论知识的要求，也减少了应用的老本和接入的难度。
Knowhere 2.x 版本原生反对 Cosine 间隔并在库外部主动归一化传入向量并适配对应的索引类型，大大减少了了解老本，晋升了用户体验。
反对 ScaNN 索引
Faiss 实现的 ScaNN，又名 FastScan，应用更小的 PQ 编码和相应的指令集能够更为敌对地拜访 CPU 寄存器，从而使其领有优良的索引性能。该索引在 Cohere 数据集，Recall 约 95% 的时候，Milvus 应用 Knowhere 2.x 版本端到端的 QPS 是 IVF_FLAT 的 7 倍，HNSW 的 1.2 倍。
反对 ARM 架构
ARM 架构比照 x86 架构，尽管其性能弱于后者，但因为更简略的设计和指令集，ARM 架构的能效和功耗更低，所以价格更为便宜。在 AWS 云平台雷同 CPU 规格，如 1 vCPU，16GB 内存的状况下，ARM 实例比 x86 实例的价格低 15% 左右。Knowhere 2.x 版本反对了 ARM 架构，使得用户能够在此架构上运行和搭建下层服务。
反对 Range Search
最近邻问题包含 K 近邻问题 (KNN) 和范畴搜寻 (Range Search)。前者解决的问题是给定一个向量汇合 X，参数 k 和查问向量 q，索引返回在向量汇合 X 中由相似性类型定义的离查问向量 q 最“近”的 k 个向量。范畴搜寻则不给定参数 k，它须要给定一个范畴 (radius)，索引返回在向量汇合 X 中与查问向量 q 的间隔在范畴内的所有向量。
Knowhere 2.x 为库中的多个索引提供了范畴搜寻的性能，例如 HNSW，DiskANN 还有 IVF 系列等。不同于 K 近邻问题，范畴搜寻返回向量的数目是事后不可知的。这对于后果的返回也提出了更高的要求，试思考查问范畴取查问向量 q 与向量汇合 X 中最远向量的间隔，后果将尝试返回整个向量汇合。对此，Milvus 提供了对查问后果分页的性能，具体可参考 https://milvus.io/docs/within_range.md。
优化过滤查问
在向量查问中，可能存在有局部向量曾经被删除的状况。或者在标量与向量的混合查问中，有一部分向量曾经被标量查问后行过滤，例如数据库中有日期的标量列，并且用户只心愿在满足特定日期的向量中进行查问。在大部分向量被过滤的场景下，Knowhere 2.x 针对 HNSW 的过滤向量查问进行了优化，使其相较于之前版本有至少 6 到 80 倍的性能晋升。
优化代码构造和编译
Knowhere 2.x 版本简化了 C++ 类之间的继承关系，缩小了函数调用；应用代理模式来标准新索引的接入，使得谬误应用的危险更低；重构了 Config 模块，应用起来更为方便快捷；应用 conan 作为包管理工具，简化和减速了编译流程；应用 Folly 中的线程池来取得对于线程更为精准的把控。
反对 MMAP
MMAP (Memory Mapping) 将文件或设施映射到内存，即过程的地址空间。一些用户可能数据量较大但苦于没有足够的内存空间搁置索引。用户之前能够尝试应用磁盘索引 DiskANN，当初也能够尝试应用 MMAP。用户抉择开启后，Milvus 和 Knowhere 2.x 会主动将大文件进行内存映射，从而能够在内存不足的状况下应用大索引数据。
反对从索引取得原始向量
用户在搜寻实现后，可能须要通过返回的 ID 获得原始向量，进一步进行定制化的计算或筛选。在之前版本的 Milvus 中，须要通过从例如 S3 或其余近程存储中取得。Knowhere 2.x 版本反对从索引中间接取得原始向量。因为索引自身曾经被加载到内存（除 DiskANN 以外），该操作的延时会远低于从 S3 获取。值得注意的是并不是所有索引都反对，例如 IVFPQ 对原始向量进行了量化解决，从而失落了这一信息。具体索引反对的表格详见 https://github.com/zilliztech/knowhere/releases/tag/v2.2.0。
至此，咱们列举了局部 Knowhere 2.x 重要的新性能和优化。心愿本文能帮忙大家对此有更为清晰的意识，也欢送大家在 Knowhere 仓库的 issue https://github.com/zilliztech/knowhere/issues 中提出贵重的意见和倡议。同时，Milvus 2.3 系列解读会继续更新，下一篇的主题是 Milvus 最新的音讯队列 NATS，敬请期待！
🌟「寻找 AIGC 时代的 CVP 实际之星」专题流动行将启动！
Zilliz 将联合国内头部大模型厂商一起甄选利用场景，由单方提供向量数据库与大模型顶级技术专家为用户赋能，一起打磨利用，晋升落地成果，赋能业务自身。
如果你的利用也适宜 CVP 框架，且正为利用落地和实际效果发愁，可间接申请参加流动，取得最业余的帮忙和领导！分割邮箱为 business@zilliz.com。
- 如果在应用 Milvus 或 Zilliz 产品有任何问题，可增加小助手微信“zilliz-tech”退出交换群。
- 欢送关注微信公众号“Zilliz”，理解最新资讯。
本文由 mdnice 多平台公布