放弃pgvector，Milvus 才是海量非结构化数据自动分片最优解

前言

选型一时爽，扩容火葬场。

“因为所有的关系型数据都已经存在了PostgreSQL ，所以在语义检索业务中，也就顺手选了 pgvector 。结果等到产品落地、数据量飞涨的时候，哪怕只是把一亿条数据做个分片这么简单的任务，也能消耗整个团队几天的时间，时延达到秒级不说，上线依然一夜报错8个bug。”

这是不是你用 pgvector管理非结构化数据时经常遇到的困扰？

作为 PostgreSQL 的插件，相较一众向量数据库产品，pgvector的上手成本，以及与现在数据库系统的对接、整体生态集成，无疑都是表现最为优秀的那一个。 比较适合一些学生党，或者尝鲜党作为了解向量数据库的入门产品。

但是，对商业级用户来说，如果你的产品未来的用户规模会像微信、抖音一样，用户数量超过十亿，你还这么觉得吗？

当然，这个问题不止出现在pgvector。

无论你使用的是 pgvector、Qdrant、Weaviate，还是其他依赖手动分片的向量数据库，困难都大抵类似：一开始看似低门槛的解决方案，发展到后期，随着数据量的增长，全都会变成惰性带来的技术负债：一个短择的技术决策，可能导致长期的遗患无穷。

更何况，相比过去的线性增长时代，在AI时代，一夜爆火、业务爆发式指数增长已经成为常态。

相应的，高可扩展性的重要等级，已经从选型的可选项升级为的必选项。

01

PG很好，但不是超大数据集的最优解

首先，我们必须承认一个现实：PG很好，但更适合中小规模数据的场景中去使用，在超大数据量场景中，通常会面临较大性能瓶颈。

当然，可扩展性不是一个新鲜问题，在技术上，我们也可以通过多种方式解决。

最直接的方法是垂直扩展，通过增加更多 CPU、内存或存储来增强单个机器的资源，以容纳不断增长的数据量。这个方法简单且暴力，但这种方法有明显的局限性。在 Kubernetes 环境中，大型 pod 效率低下，依赖单个节点会增加故障风险，可能导致停机时间大大增加。

因此，相比垂直扩展，多数企业会更倾向于水平扩展做分片，将数据分布在多个服务器上，从而减轻单个服务器的压力，以更低成本，提高整体系统的性能和扩展性，并保证，在单一节点出现故障时，其他节点可以继续处理请求。

乍一看，分片似乎是个很简单的事情——只要将数据库分成更小、独立的表，增加容量并允许多个可写主节点就能搞定。

但是概念虽简单，但在实践中，分片的难度不低。

因为大多数应用程序最初是设计为与单个、统一的数据库一起工作的。一旦向量数据库被分成多个分片，每个与数据交互的应用程序接口都必须进行修改或完全重写，开发成本骤增。

02

手动分片是可扩展性的自最优解吗？

Pgvector、Qdrant、Weaviate大多会采用手动来处理分片问题。但手动分片通常会导致：

• 数据分布不平衡（热点）：在多租户使用场景中，每个租户的数据量可以从数百万到数十亿个向量不等。这种不平衡会形成热点，某些分片过载，而其他分片则闲置。

• 增加重新分片的成本：在一开始，应该把所有数据分成多少片，几乎没人说得清。但是在后期，我们又会发现，分片太少就会导致频繁且成本高昂的重新分片，分片太多则会增加不必要的元数据开销。

• 架构变更的复杂性：许多向量数据库通过管理多个底层数据库来实现分片。这就导致在分片之间同步schema变更变得繁琐且易出错，减慢了开发周期。

• 资源浪费：在存储计算耦合的数据库中，开发者必须仔细规划每个节点可以分配的资源，同时考虑未来的增长。因此，当资源利用率在 60-70% 时，就需要开始计划重新分片。

因此，在调研中，我们发现，一些企业使用了pgvector 后，原本预计一次手动分片需要两名工程师大约六个月的时间，但实际工程量大超预期：

每次架构变更、数据再平衡操作或规模扩展都需要把类似的操作再次重复，如此循环往复，以至于不得不针对pgvector建立一个永久的分片维护团队。

但这些原本是在早期选型过程中，就可以规避的技术债。

03

Milvus如何实现无感扩容自动分片

当手动管理分片开始被逐渐淘汰，自动扩展分片的向量数据库，开始逐渐被越来越多的人所使用。其典型代表是Milvus，可以帮助用户实现了从数百万到数十亿向量的无感扩容。

具体来说，Milvus 利用 Kubernetes 和存算分离架构来支持无缝扩展与动态资源分配，可以实现以下功能：

• 根据需求变化快速扩展

• 在所有可用节点上自动负载均衡

• 独立的资源分配，用户可以自由调整计算、内存和存储

• 即使在快速增长期间也能保持一致的高性能

在这背后，是Milvus 的两项关键创新。

• 其一，基于Segment的架构：在核心上，Milvus 将数据组织成“Segment”——数据管理的最小单位：

  • Growing Segment位于StreamNodes上，优化实时查询的数据新鲜度

  • Sealed Segment 由QueryNodes管理，利用强大的索引加速搜索

  • 这些Segment在节点之间均匀分布，以优化并行处理

• 其二，双层路由：与传统数据库中每个分片位于单个机器上不同，Milvus 将一个Shard中的数据动态分布在多个节点上：

  • 每个Shard可以存储超过 10 亿个数据点

  • 每个Shard中的Segment可以跨机器自动平衡

  • 扩展集合就像扩展Shard数量一样简单

  • 即将推出的 Milvus 3.0 将引入动态Shard拆分，甚至将这一最小的手动步骤也取消

而应对 大规模查询时， Milvus 整体遵循以下的过程：

• Proxy识别请求collection的相关Shard

• Proxy从StreamNodes和QueryNodes收集数据

• StreamNodes 处理实时数据，而QueryNodes 同时处理历史数据。

• 结果被聚合并返回给用户

尾声

实际上，PG与Milvus的选择背后，不只是向量数据库如何选型这么简单，而是代表了一个技术团队的长期技术哲学思考：究竟是先快速上线搞定需求，还是将眼光放得更长远，考虑半年、一年甚至三年五年的长期需求。

类似的抉择，还出现在究竟是选择手动运维还是自动化运维，选择自研还是采购SaaS之类的场景之中。

长期来看，一个优秀的团队，一定是始终将精力集中在最重要的创新的团队。

自动分片终将取代手动分片，这不仅会带来效率的提升，更能让工程师的工作从无意义的重复手动分片回到产品功能的设计，带来效率与体验的双重提升。

如果正在阅读文章的您也面临类似的工程负担、大规模性能瓶颈，或者数据库迁移问题，欢迎在 zilliz.com/cloud 上体验全托管的 Milvus，体验无感扩容。