⚡️ **成本与性能的挑战：** 随着非结构化数据爆炸式增长，传统内存型向量数据库的检索成本日益增高，已成为 AI 应用中的关键瓶颈，甚至可能超过大模型调用成本。AWS S3Vector 服务利用对象存储的低成本优势，为向量检索提供了一种经济的入门选择。

⚠️ **S3Vector 的局限性：** 实测表明，S3Vector 在成本上具有显著优势，但能力有限。其主要缺点包括：数据量上限（单个表最多 5000 万向量）、查询速度慢（冷数据需数百毫秒，热数据 QPS 限制）、写入速度慢（不足 2MB/s），召回率不稳定（正常情况 85%-90%，加过滤条件后骤降至 50% 以下），以及功能基础（topk 限制、附加信息大小限制、缺乏混合查询和多租户功能）。

💡 **Zilliz Cloud 分层存储方案：** Zilliz Cloud 推出的分层存储架构（内存 + 磁盘 + 对象存储）颠覆了传统全量加载模式，通过智能缓存实现动态分层。热数据缓存在内存，温数据存于磁盘，冷数据存于对象存储，从而以接近 S3 的成本提供企业级功能和高性能。该方案特别适合大规模多租户应用和大规模数据近实时分析场景，能显著降低成本并保障活跃数据访问体验。

🚀 **S3 Vector 数据迁移指南：** 文章提供了详细的 S3 Vector 数据迁移到 Zilliz Cloud 的教程，包括准备工作、迁移前验证、配置文件创建以及使用 VTS（Vector Transport Service）进行数据迁移的步骤。迁移完成后，用户可以在 Zilliz Cloud 控制台验证数据，并按需创建索引，实现数据的无缝过渡。

原创 黄浩原 2025-09-16 18:14 上海

内存 VS 对象存储，谁是向量数据库的未来？

向量数据库的摩尔定律时代，这次是真的来了。

先看两组关键数据：

未经索引优化的向量数据库，检索成本是传统 noSQL 的十倍。

AI 笔记软件里，向量检索成本已经高于大模型调用成本。

说的更直白一些：传统内存型向量数据库，面对激增的海量非结构化数据，成本已难以为继。

在这一背景下，AWS 推出了 S3Vector 服务。它借助对象存储的经济性，给出了高性价比的向量检索入门方案。

那么问题来了：

S3Vector 会取代向量数据库吗？

如果不能，如何将S3Vector与向量数据库搭配使用？

我们又如何将 S3Vector 的数据做好迁移？

本文将逐一解答这些疑问。

（彩蛋预告：Zilliz Cloud 最新分层存储方案，能以接近对象存储价格，搞定企业级功能与性能需求，详情见下文）

01 

S3Vector实测

对象存储能彻底替代内存吗

经过实测，我们发现，S3Vector 的特点十分明确：成本优势显著，但能力有限，绝非万能解决方案。

先说优点，极具竞争力的价格：

存储成本低至 $0.06/GB

存 4 亿向量，月查询 1000 万次，总成本仅 $1217

再讲缺点，S3Vector 的天花板”很明显，主要在 3 个方面：

（1）速度慢，有上限

collection size ：s3 单个表最多 50m vectors，最多支持 10000 个表放一个 bullet point.

查冷数据：100 万条要等 500 毫秒，1000 万条要等 700 毫秒；

查热数据：每秒最多查 200 次（200 QPS），超过就会限流；

写数据慢：每秒写不到 2MB（Milvus 能到每秒1 GB），不适用大量数据频繁变更的场景。

（2）召回率不够，还没法调

正常情况下Recall只有 85%~90%，没有可调的参数；

加过滤条件（比如 “只查 2024 年的数据”）后，召回率直接掉到 50% 以下；

如果删了一半数据，想查前 20 个结果（Top20），可能只能返回 15 个。

（3）功能太基础

一次最多查 30 个结果（topk 不超 30）；

每条数据的附加信息（比如备注、标签）有大小限制；

没有 混合查询、多租户 这些企业常用的功能。

也就是说，如果只是针对海量非结构化数据做最基础的检索与管理、查询速度要求不高、用得也不频繁（比如每天查几次），那它几乎没对手。

但如果有数据的冷热管理需求，或者有混合检索、多租管理这样的企业功能，那么就需要一个新的思路，将S3的低成本与传统向量数据库的企业级功能做一个结合。

02  

Zilliz Cloud 分层存储

兼顾低成本与企业级功能

近期，Zilliz 存储扩展型即将全新升级为“分层存储型”，推出冷热温三层存储架构，做到以接近S3的成本，兼顾企业级功能与性能（如有需求，可公众号后台留言）。

过去，在传统的 Zilliz Cloud 架构中，无论是性能型、容量型还是存储扩展型，都要求全量数据加载到：内存（性能型）或者磁盘（容量型）。全量加载模式虽能保证查询性能，但面对大规模数据时，资源成本极高。

分层存储架构（内存 + 磁盘 + 对象存储）直接颠覆这一模式，用智能缓存替代全量加载。

热数据：缓存在 EC2 实例内存，保障极致访问速度；

温数据：存于磁盘，平衡性能与成本；

冷数据：存于 S3 等对象存储，将存储成本压到最低。

它的核心优势是动态分层：将高频访问数据，自动升层到内存 / 磁盘，确保高性能；长期未访问数据，自动降层 到对象存储，降低成本。

更关键的是，我们没有采用简单的 LRU （最近最少使用）策略，而是让系统结合数据访问模式、用户行为、业务特征做智能预判。

比如多租户场景下，能提前识别潜在活跃用户及其活跃时间段，将数据预加载到高层存储。

最终实现：热数据保性能，冷数据降成本，存储成本逼近 S3，活跃数据访问体验不打折。

这套架构，精准匹配两大核心场景：

场景一：大规模多租户应用

这类应用的典型特征：租户总量大（千万级），但活跃率低（仅 1%-5%），有明确活跃时间段。典型代表是 AI 编程助手（每个订阅即租户）、情感聊天应用（每个用户即租户）。

分层存储的价值的在于：企业不用为全量租户付高价，就能以高性能支撑大规模用户基数。

95% 不活跃租户数据：存于接近 S3 成本的底层存储，大幅压低成本；

5% 活跃租户数据：享受接近性能型 / 容量型的服务质量，保障用户体验。

场景二：大规模数据近实时分析

自动驾驶数据、机器人大模型训练、创新药研发等领域，都有一个共性：数据总量极大，但查询频率极低（每天仅极少数人做十几次到上百次的查询，远低于在线推荐系统每秒数千次的强度）。

这类场景对成本极度敏感，研发团队愿接受秒级甚至 10 秒级响应，换取成本下降。

分层存储正好契合需求：将存储成本降到纯内存方案的几分之一，同时提供可接受的查询性能，完美平衡 低成本与 可用性能。

03 

迁移教程

既然 Zilliz Cloud三层存储，可以做到与 S3 Vector 基本持平的成本，并兼顾企业级功能与性能，那么如何把 S3 Vector 的数据迁移到 Zilliz Cloud ？

我们假设您已经在 AWS 的 us-west-2 区域的 vector 桶的 books Index 下存入了 200 条书籍信息数据，每条数据包含：

768 维的内容向量

书名作为主键（key）

作者信息存储在元数据（metadata）中

开始前的准备工作

在开始迁移之前，请确保满足以下先决条件：

Docker 已经正确安装。

运行 VTS 的节点能够访问 S3 Vector 和 ZIlliz Cloud。

IAM 用户或角色具有 s3vectors:ListVectors 权限

迁移前验证

在部署和启动 VTS 服务之前，建议先验证 S3 Vector 中的数据和访问权限。

import boto3

import os

aws_access_key_id = os.getenv("AWS_ACCESS_KEY_ID")

aws_secret_access_key = os.getenv("AWS_SECRET_ACCESS_KEY")

s3vectors = boto3.client("s3vectors", region_name="us-west-2", aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key)

resp = s3vectors.list_vectors(vectorBucketName="vectors", indexName="books", returnMetadata=True, returnData=True)

for vector in resp["vectors"]:

    print(vector)

您应该可以看见 200 条数据结果

{'key': 'First foot situation land bad.', 'data': {'float32': [0.7183347940444946……]}, 'metadata': {'author': 'Wendy Jones'}}

{'key': 'Face industry bit true.', 'data': {'float32': [0.9061349630355835……]}, 'metadata': {'author': 'Steven Smith'}}

{'key': 'Republican agreement probably home choose see.', 'data': {'float32': [0.26946496963500977……]}, 'metadata': {'author': 'Misty Lynch'}}

{'key': 'Before arrive design soon finally discuss.', 'data': {'float32': [0.35728317499160767……]}, 'metadata': {'author': 'Mark Johnson'}}

…………

开始迁移

拉取最新的 vts 镜像，使用 1.2.0 及以上的版本。

docker pull zilliz/vector-transport-service:v1.2.0

创建一个配置文件

vim ./s3-vector_to_milvus.conf

写入如下内容，根据实际情况改写

env {

  execution.parallelism = 1

  job.mode = "BATCH"

}

source {

    S3Vector {

        region = "us-west-2"

        vector_bucket_name = "vector-bucket" # 向量桶名

        index_name = "books"  # 向量索引名

        ak = "ak" # aws_access_key_id

        sk = "sk" # aws_secret_access_key

    }

}

sink {

  Milvus {

      url="https://in01-***.<region>.zilliz.com.cn:19530" 

      token="***"  

      database="default"  # 目标 database

      batch_size=1  # 每次插入的批量，批量大速度快，但使用更多的内存

    }

}

配置好后保存。

使用 vts 镜像启动容器，并把配置文件映射到 docker 容器中。

docker run -v ./s3-vector_to_milvus.conf:/config/s3-vector_to_milvus.conf -it zilliz/vector-transport-service:v1.2.0 /bin/bash

在 docker 容器里使用如下命令启动 vts 进程。

./bin/seatunnel.sh --config /config/s3-vector_to_milvus.conf -m local

等待 vts 进程运行结束。

迁移后验证

进入 ZIlliz Cloud 控制台。

Vts 会自动探测 metadata 里的数据，并为每一个属性创建一个列，并使用 key 作为 pk 列。

接下来，按需给向量列创建一个索引。

操作 Load Collection ，即可在控制台上预览数据。

数据条数和内容都和迁移之前一致。

尾声

放眼当下，非结构化数据市场正持续增长，需求不断攀升。

Zilliz Cloud 的分层存储架构，给出了理想解法：既保留 S3 的低成本存储优势，又具备专业向量数据库的高性能，企业级功能。

无论你是刚接触向量检索，还是想从 S3 Vector 升级到更专业方案，都不妨做一下尝试。

迁移只是起点，Zilliz Cloud完整的的性能优化、功能设计，都将为您的业务带来持续价值回报。

推荐阅读

实战|CLIP+Milvus，多模态embedding 如何用于以文搜图

ES vs Milvus vs PG vector :LLM时代的向量数据库选型指南

Embedding无敌，是做文档RAG最大的幻觉（含LangExtract+Milvus教程）

Word2Vec、 BERT、BGE-M3、LLM2Vec，embedding模型选型指南

全面测评LangChain vs LangGraph：谁是agent落地最优解

阅读原文

跳转微信打开