为什么向量数据库/数据向量化很重要？

我们在之前的文章中提到向量数据库的概念，其中我们特别提到了向量数据库：Milvus。

我们今天用简单的语言，深入浅出的了解一下数据和AI时代的向量数据库。

为什么要有「向量数据库」

向量化存储为什么在AI时代如此不可或缺主要有以下原因：

1. 数据形式发生变化

随着大数据和大模型技术的快速发展，每天都会产生数十亿张图片、视频、文档和音频文件，人工对非结构化数据进行分类根本无法扩展。

简单的说，除了文字要存储，图片、文档和音频文件也需要存储。

1. 查询方式变化

图像、文本、语音等非结构化数据被转化为高维空间中的点，即向量表示。当数据进入高维空间，与传统数据库基于精确匹配的查询方式不同，向量数据库通过向量距离算法执行模糊查询，常见的算法包括曼哈顿距离、欧氏距离、余弦距离等。

在索引构建方面，传统数据库的B树或哈希表索引方法不适用于高维向量。

1. 高性能要求

高维向量数据的维度通常很高，占用大量存储空间，给数据库的存储容量带来巨大压力。随着数据量的增加，传统数据库在索引构建和维护上也会变得非常困难，难以快速定位到所需数据，无法满足实时操作的需求。

更为关键的是语义理解能力的缺失。传统数据库的操作符是精确匹配和预定义关系，而人类对内容的理解是细微的、上下文的和多维的，这就是所谓的 "语义鸿沟"。

上面就是向量化存储的背景和必要性了。

当前的向量数据库有哪些？

当前向量数据库领域呈现"专业向量数据库"与"传统数据库扩展向量能力"两大技术路线并行的格局。

专业向量数据库

专为高维向量数据的存储、索引和相似性搜索设计，架构上深度优化向量处理性能，支持千亿级向量规模及低延迟查询，是AI原生场景（如RAG、多模态搜索）的核心选择。

主要成员包括：

• Milvus

• Pinecone

• Qdrant ....

这其中Milvus是开源的，也是其中的佼佼者，大家可以直接进入官方网站了解：https://milvus.io/docs/zh/overview.md

传统数据库向量能力扩展

• OceanBase

• Elasticsearch（向量增强版） ...

这类数据库基于成熟的传统数据库架构（关系型/分布式），通过扩展向量数据类型、索引及检索能力，实现"结构化数据+向量数据"的一体化存储与查询。

Milvus 为什么强？

Milvus 采用共享存储架构，存储计算完全分离，计算节点支持横向扩展。从架构上来看，Milvus 遵循数据流和控制流分离，整体分为了四个层次，分别为接入层（access layer）、协调服务（coordinator service）、执行节点（worker node）和存储层（storage）。各个层次相互独立，独立扩展和容灾。

其次：

• 功能性：Milvus不仅支持基本的向量相似性搜索，还支持稀疏向量、批量向量、过滤搜索和混合搜索功能等高级功能；

• 灵活性：Milvus支持多种部署模式和多个 SDK，所有这些都在一个强大的集成生态系统中实现；

• 性能：Milvus采用HNSW和DiskANN等优化索引算法以及先进的GPU加速，可确保高吞吐量和低延迟的实时处理；

• 可扩展性：其定制的分布式架构可轻松扩展，从小型数据集到超过100亿向量的Collections都能轻松应对。

接下来我们不讨论Milvus本身的使用，我们通过对比 Milvus 和 OceanBase，来对比一下两种技术路线下，我们做技术选型主要考虑的因素。

Milvus VS. OceanBase向量增强版

技术路线

我们先说Milvus：

Milvus 遵循数据平面和控制平面分解的原则，采用分层解耦的分布式架构，由四个主要层组成：访问层、协调器服务、工作节点和存储层，这些层在可扩展性和灾难恢复方面相互独立。这种共享存储架构具有完全分解的存储层和计算层，可实现计算节点的横向扩展，同时将 Woodpecker 作为WAL（Write-Ahead Log）层实施，以增强弹性并减少操作开销。

在技术实现上，Milvus 构建在 Faiss、HNSW、DiskANN、SCANN 等流行的向量搜索库之上，支持数据分片、流式数据摄取、动态 Schema、结合向量和标量数据的搜索、多向量和混合搜索、稀疏向量等高级功能。Milvus 2.0 采用存储与计算分离的架构设计，所有组件均为无状态组件，极大地增强了系统弹性和灵活性。

目前Milvus最新版本为2.6，Milvus 2.6重点关注核心架构改进，包括更简单的部署、更少的依赖性、更快的数据摄取管道、更低的存储成本、更好地处理大规模数据操作、更高效的标量和全文搜索，以及支持最新的 Embeddings 模型。

在未来的3.0版本中，将引入向量数据湖系统，支持无缝集成人工智能服务、更高级别的搜索功能、更强大的数据管理，以及更好地处理海量离线数据集。

回到OceanBase向量增强版：

在向量数据库领域，OceanBase基于其强大的原生分布式架构，通过在存储层加入Vector向量数据类型，并在索引层加入向量索引，使得OceanBase数据库具备向量检索能力，并且这一功能拓展未对内核层及相关工具体系的使用造成影响。

OceanBase的向量能力架构设计具有独特的优势。在数据类型兼容方面，OceanBase的架构不仅可以兼容KV文档及向量数据，还支持JSON、GIS、Bitmap 等多种数据类型。企业可以将所有的多模数据集中整合至单一的 OceanBase 数据库中，避免因不同类型数据存储于不同数据库而产生的数据孤岛问题。

在索引支持方面，OceanBase提供了丰富的索引类型。OceanBase 不仅支持向量索引，还支持标量索引、半结构化索引（如多值索引、空间索引），以及全文索引，并且支持同时访问多路索引，为复杂的数据检索需求提供了坚实保障。OceanBase 支持的索引类型包括 HNSW、IVFFlat、DiskANN 等多种索引类型，距离算法涵盖 L2、IP、COSINE、Jaccard 等常用距离算法，确保在向量检索时能够精准计算相似度。

OceanBase与Flink、Spark等众多生态工具紧密协作，可以读取其他数据库、关系型数据库管理系统（RDBMS）以及外部文件等各类数据源的数据，并将所有数据进行统一整体计算。这种一体化架构设计使得 OceanBase 能够提供AI应用场景所需的海量向量处理、混合检索能力，通过极简技术栈与超强压缩能力助力运维与存储降本。

在技术发展方面，OceanBase 正在推进两方面优化：一方面将稀疏向量、稠密向量与全文的多路检索能力集成至数据库内核，使用户通过单条 SQL 即可实现混合检索；另一方面尝试将向量Embedding 模型嵌入数据库，使用户仅需插入原始数据，无需关注向量处理过程，从而实现数据插入与查询的一体化易用性体验。

Milvus和OceanBase在向量数据库市场中呈现出明显的差异化定位，这种差异源于两者不同的技术路线选择和产品理念。

技术架构

从技术架构角度看，Milvus 采用 "存储-计算彻底分离" 架构，查询节点、索引节点、存储节点可独立扩缩容，灵活适配读多写少、写多读少等不同负载场景(70)。Milvus 的架构革新体现在其模块化、分布式的云原生设计上(62)。而 OceanBase 则基于一体化架构，内存 + 磁盘分布式处理，支持不同类型企业千万级、亿级、十亿 + 级不同规模向量处理

在功能特性方面，两者各有侧重。Milvus 作为专门的向量数据库，在向量检索性能和灵活性方面具有优势，支持 GPU 索引和混合搜索灵活性。其支持的向量维度最高可达32768维，虽然不直接支持SQL，但提供了丰富的 API 接口(135)。相比之下，OceanBase 的向量维度最高支持 16000 维，但它最大的优势在于原生支持 SQL，能够通过标准 SQL 语言创建向量表并写入向量数据，使用标准 SQL 语法导入向量数据并进行 DML 操作。

产品定位

产品定位的差异还体现在应用场景的适配性上。Milvus 更适合对向量检索性能要求极高的场景，如金融风控、生物医药分子库检索等对性能要求严苛的高并发应用场景，其支持稀疏向量检索功能，相比传统解决方案的处理速度提升可达16倍。Milvus特别适合互联网推荐（如电商、短视频）等需要 "高QPS+低延迟"的场景，支持动态更新。

OceanBase 则定位为一体化 AI 数据底座，其核心优势在于能够在同一数据库引擎中同时处理结构化数据（标量）和非结构化数据（向量）。这种一体化架构设计使得 OceanBase 特别适合那些既需要处理传统关系型数据，又需要向量检索能力的企业级应用场景。OceanBase 原生分布式架构更适合金融级高一致性场景，支持事务处理，能够保证数据的一致性，而 Milvus 和 Elasticsearch 不能保证数据一致性。

大家要特别注意，我们拿Milvus和OceanBase向量版做对比只是一个把两种技术路线的向量化存储做对比，不代表A就一定强于B。需要根据具体的业务场景选择合适的引擎，比如我们没有提到的ES，ES的核心优势是全文检索与向量检索的深度融合，更加适合需要同时匹配关键词与语义的场景。

我们今天的分享就到这里了。

---

最后，欢迎加入我们的知识星球小圈子：

• 我们用了2个月时间，整理了200+场次大厂面试专题！

• 300万字！全网最全大数据学习面试社区等你来

   如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！