Milvus 2.x 与 1.x 全面对比：云原生分布式架构如何重塑向量数据库的扩展性与一致性

Milvus 2.x 与 1.x 全面对比云原生分布式架构如何重塑向量数据库的扩展性与一致性【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvusMilvus 是一套为规模化向量近似最近邻ANN搜索而设计的高性能云原生向量数据库项目描述见 README.md。本文基于仓库根目录下的官方对比文档 milvus20vs1x.md系统梳理 Milvus 2.x 相对 1.x 在架构、扩展性、持久化、一致性、数据类型、索引与 SDK 等维度的代际差异并结合当前仓库源码验证 2.x 的关键实现。读完本文你将理解 2.x 选择云原生架构的技术动因、各维度能力边界的演进脉络以及这些设计如何在代码层面落地。一、为什么需要一次架构级重写从共享存储到云原生Milvus 1.x 采用共享存储架构所有节点共享同一份数据视图写能力被限制为单写节点读节点最多扩展到 32 个。这种设计在早期验证了向量检索场景的可行性但面对“十亿级向量、数万 QPS”的生产需求时存在明显的单点瓶颈与扩容天花板。Milvus 2.x 将系统重构为云原生架构计算与存储彻底分离各组件以无状态微服务形式运行于 Kubernetes 之上按流量模式独立横向扩容——读密集时单独扩展查询节点querynode写密集时单独扩展数据节点datanode。官方对比文档给出的节点规模上限为500 节点与 1.x 的“32 读节点 1 写节点”形成数量级差距。当前仓库的部署编排文件可以直观印证这一架构单机模式deployments/docker/standalone/docker-compose.yml 中standalone服务以milvus run standalone启动同时拉起 etcd 与 MinIO 两个基础组件可见即使单机部署也遵循“元数据etcd 对象存储MinIO Milvus 服务”三层结构集群模式deployments/docker/cluster-distributed-deployment 下的 Ansible 编排按角色拆分为deploy-proxy、deploy-rootcoord、deploy-querycoord、deploy-datacoord、deploy-indexcoord、deploy-querynode、deploy-datanode、deploy-indexnode以及 etcd、MinIO、Pulsar 等基础设施角色正是 2.x 微服务化架构在部署层的直接体现。二、Milvus 2.x 与 1.x 官方对比总览下表完整保留自官方对比文档 milvus20vs1x.md逐项列出两个大版本的能力差异对比维度Milvus 1.xMilvus 2.x架构共享存储Shared storage云原生Cloud native可扩展性132 个读节点且仅支持 1 个写节点500 节点持久化本地磁盘Local disk、网络文件系统NFS对象存储服务OSS、分布式文件系统DFS可用性99%99.9%数据一致性最终一致性Eventual consistency三级一致性Three levels of consistency强一致Strong、有界陈旧Bounded Staleness、会话Session、一致前缀Consistent prefix支持的数据类型向量Vectors向量Vectors、定长标量Fixed-length scalars、VARCHAR2.1 版本起支持支持的基本操作数据插入、数据删除、近似最近邻ANN搜索数据插入、数据删除、数据查询、ANN 搜索、RNN 搜索规划中高级特性Mishards、Milvus DM标量过滤Scalar filtering、Time Travel、多站点部署与多云集成、数据管理工具索引类型与算法库Faiss、Annoy、Hnswlib、RNSGFaiss、Annoy、Hnswlib、RNSG、ScaNN规划中、磁盘索引 On-disk index规划中SDKPython、Java、Go、RESTful、CPython、Node、Go、Java、RESTful规划中、C规划中发布状态长期支持LTS正式发布GA需要说明的是表中标注“规划中in planning”的能力反映的是对比文档写作时的状态从当前仓库源码看其中部分能力已经落地详见下文第四、五节。三、逐维度深度解读 2.x 的演进逻辑1. 架构与可扩展性微服务化带来横向扩容自由1.x 的共享存储架构决定了其扩展模式是“读多写一”所有写入必须经过唯一写节点读节点通过共享存储获得数据视图。这一模型在小规模场景可用却无法支撑写入热点和水平弹性。2.x 的云原生架构把系统拆分为协调层rootcoord、datacoord、querycoord、indexcoord与执行层querynode、datanode、indexnode中间以 proxy 对外统一暴露服务消息中间件如 Pulsar/Kafka负责日志与数据流转。从 deployments/docker/cluster-distributed-deployment 的部署角色清单可以确认2.x 的每个职责模块都是独立可部署的服务扩容即“加节点”缩容即“减节点”天然适配 Kubernetes 的弹性调度。2. 持久化从本地盘到对象存储与分布式文件系统1.x数据落在本地磁盘或 NFS 上容量受单机磁盘限制节点故障时需要依赖副本或重新加载持久化与可用性都较脆弱。2.x数据统一落在对象存储服务OSS或分布式文件系统DFS上。对象存储的无限容量与高冗余特性使得数据节点可以无状态化——节点本身不持有持久数据故障后只需从对象存储重新加载 segment 即可恢复这也是 2.x 可用性目标提升到 99.9% 的底层支撑之一。单机部署中 MinIO 作为对象存储被拉起见 deployments/docker/standalone/docker-compose.yml生产集群则可对接 S3、OSS 等兼容服务。3. 数据一致性从单一最终一致到四档可选一致性是 1.x 与 2.x 差异最显著的设计点之一。1.x 仅提供最终一致性2.x 在查询接口中显式暴露一致性级别选择用户可根据业务对“读到多新”的敏感度权衡一致性与性能。官方对比文档列出四个级别强一致Strong、有界陈旧Bounded Staleness、会话Session、一致前缀Consistent prefix。仓库源码在 Go SDK 侧提供了与之对应的常量定义见 client/entity/schema.goClStrong强一致读操作能立即看到已提交的最新写入ClBounded有界陈旧一致性源码注释明确其默认容忍 5 秒的数据陈旧窗口在一致性与查询延迟之间取得平衡ClSession会话一致性保证同一会话session内的读写互相可见ClEventually最终一致性追求最低查询开销ClCustomized自定义级别允许用户自行传入guarantee_timestamp精确控制可见性时间点。在 client/milvusclient/collection_test.go 的测试中可以看到默认创建 collection 时使用的即ConsistencyLevel_Eventually这印证了“一致性级别可在建集合或查询时逐次指定”的使用方式。2.x 的一致性本质上是基于时间戳timestamp与guarantee_timestamp机制实现的查询请求携带保证时间戳协调层据此决定查询是否等待数据推进到该时间点。4. 数据类型与基本操作从纯向量到向量 标量混合检索数据类型1.x 只支持向量2.x 在向量之外增加了定长标量Fixed-length scalars并从 v2.1.0 起支持 VARCHAR 字符串类型。这意味着 2.x 可以在一个集合里同时保存向量与其元数据如文本标题、ID、标签为带过滤条件的向量检索提供了数据基础。基本操作1.x 支持插入、删除与 ANN 搜索2.x 在继承这些操作的基础上新增了数据查询query即按标量条件精确检索实体并规划 RNN 搜索能力。值得注意官方对比文档将 2.x 的“数据删除”标记为规划中但从当前仓库源码看删除能力已实际落地——Go SDK 在 client/milvusclient/write.go 中提供了Delete方法实现测试用例见 client/milvusclient/write_test.go。这属于文档撰写时间与代码演进之间的时间差也说明对比表中的“规划中”标注需以具体版本发布说明为准。5. 高级特性标量过滤、Time Travel 与数据管理工具2.x 引入的几项高级特性本质都是“标量 向量混合处理”能力的延伸标量过滤Scalar filtering在 ANN 搜索前先用标量条件如price 100 brand A缩小候选集大幅降低无效计算仓库中对应实现集中在 internal/proxy 与查询节点的计划执行链路中Time Travel基于 2.x 统一的 TS/O 时间戳体系可以按历史时间点查询集合在该时刻的数据快照。当前仓库 internal/datacoord 下有完整的快照元数据与管理实现如 internal/datacoord/snapshot_meta.go、internal/datacoord/snapshot_manager.goSDK 侧亦有对应的快照操作支持多站点部署与多云集成由对象存储 无状态微服务的架构自然支撑数据管理工具如导入、迁移、备份等生态工具。作为对照1.x 的 Mishards分片中间件与 Milvus DM数据迁移工具解决的是共享存储架构下的水平分片与数据搬迁问题属于 1.x 时代的补丁式方案2.x 已将这些诉求内化到云原生架构本身。6. 索引体系与 SDK继承与扩展索引2.x 完整继承了 1.x 的 Faiss、Annoy、Hnswlib、RNSG 四类索引库支持并规划 ScaNN 与磁盘索引On-disk index——磁盘索引对应后续的 DiskANN 能力使超出内存容量的向量集也能被检索。从当前仓库的 client/index 目录看索引类型已细分为 auto、flat、ivf、hnsw、disk_ann、scann、sparse、scalar、rtree、minhash、gpu 等多个文件说明索引体系在文档基础上又进一步扩展。SDK 语言覆盖1.x 提供 Python、Java、Go、RESTful、C2.x 官方主推 Python、Node、Go、Java其中 RESTful 与 C 在当时标记为规划中。当前仓库的 client 目录包含 Go SDK 完整实现tests/python_client 与 tests/go_client 则分别维护着两套语言的集成测试用例。7. 发布状态与迁移意义1.x 处于长期支持LTS阶段2.x 已达到正式发布GA状态。对存量用户而言1.x 到 2.x 不是一次简单的版本升级而是数据模型纯向量 → 向量 标量、部署形态共享存储 → K8s 云原生、一致性模型最终一致 → 多级可选的系统性重构需要配套的数据迁移与部署改造。四、总结与选型建议从 milvus20vs1x.md 的对比表可以看出2.x 相对 1.x 的升级可以概括为四条主线架构共享存储 → 计算存储分离的云原生微服务支持 500 节点水平扩展存储与可用性本地盘/NFS → 对象存储/分布式文件系统可用性从 99% 提升到 99.9%数据能力纯向量 → 向量 定长标量 VARCHAR 的混合数据模型新增查询操作、标量过滤与 Time Travel一致性单一最终一致 → 强一致 / 有界陈旧默认 5 秒容忍/ 会话 / 一致前缀 / 自定义时间戳的多档可选。选型建议上若业务场景是单机、小规模、纯向量检索1.x 的共享存储架构足以胜任且部署简单若面向生产级、十亿级向量、要求弹性扩容与高可用则应以 2.x 云原生架构为基准。需要提醒的是对比表中的“规划中”能力RNN 搜索、ScaNN、磁盘索引、RESTful/C SDK 等在后续版本中已逐步落地具体以当前发布版本的官方说明为准。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考