一,背景
信息通信技术(ICT)正经历着前所未有的变革浪潮,以大模型和生成式人工智能(GenAI)为代表的技术突破,正在引发全球产业体系的深刻变革,成为驱动企业技术架构革新和商业模式转型的关键引擎。
得物是广受年轻人喜爱的品质生活购物社区。在 AI 鉴别、图搜、算法、安全风控等场景下都广泛使用了 GenAI 技术。
向量数据库作为 GenAI 的基础设施之一,通过量化的高维空间数据结构(如 HNSW 算法),实现对嵌入向量(Embeddings Vector)的高效存储、索引和最近邻搜索(ANN),支撑包括多模态数据表征在内的复杂智能应用。
二,认识向量数据库
向量数据来源和存储

一般向量数据库中向量的来源是将图片、音频、视频、文本等非结构化数据,将这些非结构化数据通过对应的量化算法计算出一个多维度的向量(生产使用一般向量维度会大于 512),并且将向量数据持久化在特定的存储上。
向量数据库是如何工作

向量数据库在查询的时候一般会将需要查询的非结构化数据通过量化,计算成一个多维度向量数据,然后在数据库中搜索出和查询向量相似的数据。(需要注意的是这边查询的是相似的数据而不是相同的数据)。
三,向量数据库对比传统数据库


向量数据库在数据结构、检索方法、擅长领域与传统数据库有很大的不同。
传统数据库
结构是处理离散的标量数据类型(例如数字和字符串),并通过行和列来表达组织数据(就是一个表格)。传统数据库主要为了解决结构化数据的精确管理和高效查询问题。并且传统数据库通过 B 树索引、哈希索引等数据结构,能够快速定位到精确匹配的记录。更重要的是,传统数据库通过 ACID 事务特性(原子性、一致性、隔离性、持久性)确保了在数据中数据的绝对准确性。
向量数据库
为了解决非结构化数据的语义搜索问题,解决如何在海量的高维向量数据中,快速找到与查询向量最相似的结果。比如在推荐系统中找到与用户喜好相似的物品,或在图像库中检索出与查询图片最相近的图片。这类问题的特点是:
-
查询的不是精确匹配,而是相似度排名。
-
数据维度极高(通常 128-2048 维)。
-
数据规模庞大(可能达到十亿级别)。
-
传统数据库的精确查询方式在这种场景下完全失效,因为:
-
无法为高维向量建立有效的 B 树索引。
-
计算全量数据的精确相似度代价过高。
-
无法支持"相似但不完全相同"的搜索需求。
四,如何选择向量数据库
向量数据库比较
下面我们通过 10 个不同维度来比较一下不同向量数据库的区别

从上面表格可以看到:
-
自 2016 年起 ,向量数据库逐渐崭露头角,成为 AI 和大数据领域的重要基础设施。而到了 2021 年之后 ,随着深度学习、大模型和推荐系统的迅猛发展,向量数据库正式迈入爆发式增长时代 ,成为现代数据架构中不可或缺的核心组件。
-
超过半数的向量数据库均采用分布式架构设计,并且这些支持分布式部署的系统普遍具备弹性扩缩容能力,能够根据业务需求实现资源的动态调整。
-
当业务需要处理亿级甚至更高规模的向量数据时,推荐以下高性能、可扩展的向量数据库:Vespa、Milvus/Zilliz、Vald、Qdrant。
-
当前主流的向量数据库普遍采用模块化、插件式的设计理念。其核心引擎大多基于 C/C++ 开发,以追求极致的性能表现。与此同时,Go 和 Rust 也正在这一领域崭露头角。
-
在向量数据库领域,HNSW(Hierarchical Navigable Small-World)和 DiskANN 正逐渐成为主流索引方案。其中 HNSW 主要以内存搜索为主,DiskANN 主要以磁盘搜索为主。值得注意的是,Qdrant 在优化 HNSW 的基础上,进一步实现了 基于磁盘的 HNSW 检索能力。
选择流行的索引
在向量数据库技术领域,有 HNSW 和 DiskANN 作为两大主流索引方案,各自展现了独特的技术优势。我们从以下关键维度进行专业对比分析。

从上表格我们可以得到,HNSW 和 DiskANN 适用于不同的场景:
-
HNSW :以 内存优先 的设计实现高性能搜索,适合 低延迟、高吞吐 要求严格的场景,如实时推荐、广告检索等。
-
DiskANN :以 磁盘存储优化 为核心,在保证较高召回率的同时 显著降低硬件成本 ,适用于大规模数据下的经济型检索需求。
随着数据规模的持续增长,HNSW 和 DiskANN 的混合部署模式 或将成为行业标准,让用户能根据业务需求灵活选择 "极致性能" 或 "最优成本" 的检索策略。
综合比较和选择

从表格中可以得到:
如果数据流比较小,并且自身对 Redis、PG、ES 比较熟悉,就可以选择 Redis、PG、ES。如 DBA 团队就比较适合。
如果数据量比较大,并且前期人力不足可以使用云托管方案。选择 Zilliz、Pinecone、Vespa 或者 Qdrant,如果后期计划从云上迁移到自建可以选择 Zilliz、Vespa 或者 Qdrant。
得物选择 Milvus 作为向量数据库
我们的需求
社区图搜和 AI 鉴别需要大量的数据支持,得物业务场景要求能支持十亿级向量数据搜索,有如下要求:
-
大数据量高性能搜索,RT 需要在 90ms 以内。
-
大数据量但是性能要求不高时,RT 满足 500ms 以内。
需要支持快速扩缩容:
满足上面 2 点就已经锁定在 Milvus、Qdrant 这两个向量数据库。如果从架构复杂度和维护/学习成本的角度考虑,我们应该优先选择 Qdrant,因为它的架构相比 Milvus 没有那么复杂,并且维护/学习成本没有 Milvus 高,重要的 Qdrant 可以单独集群部署,不需要 k8s 技术栈的支撑。
Milvus 和 Qdrant 架构比较
Milvus 架构:

Milvus 部署依赖许多外部组件,如存储元信息的 ETCD、存储使用的 MinIO、消息存储 Pulasr 等。
Qdrant:

Qdrant 完全独立开发,支持集群部署,不需要借助 ETCD、Pulsar 等组件。
选择 Milvus 的原因
※ 业务发展需求
业务属于快速发展阶段,数量的变化导致扩缩容频繁,使用支持 k8s 的 Milvus 在扩缩容方面会比 Qdrant 快的多。
※ 技术储备和社区良好
对 DBA 而言,向量数据库领域需要持续的知识更新和技术支持。从问题解决效率来看,国内技术社区对 Milvus 的支持体系相较于 Qdrant 更为完善。
※ 契合得物 DBA 开发栈
Milvus 使用的开发语言是 Go,契合 DBA 团队技术栈,在部分运维场景下,通过二次开发满足运维需求。例如:使用 milvus-backup 工具做迁移,部分的 segment 有问题需要跳过。自行修改一下代码编译运行即可满足需求。

五,Milvus 在得物的实践
部署架构演进
小试牛刀
初始阶段,我们把 Milvus 部署在 K8S 上,默认使用 HNSW 索引。架构图如下,Milvus 整个架构较为复杂,外部依赖的组件多,每个集群需要部署自己的 ETCD、ZK、消息队列模块,多套集群共享着同一个存储。

存储拆分,每个集群独立存储
共享存储瓶颈导致稳定性问题凸显。
随着业务规模扩展,集群数量呈指数级增长,我们观测到部分集群节点出现异常重启现象,经诊断确认该问题源于底层共享存储存在性能瓶颈。


最低0.47元/天 解锁文章
385

被折叠的 条评论
为什么被折叠?



