Zilliz | 语义+R-Tree空间索引:Milvus如何帮外卖APP做3公里内美食推荐| Milvus Week

Milvus融合地理与向量检索

本文来源公众号“Zilliz”,仅用于学术分享,侵权删,干货满满。

原文链接:https://mp.weixin.qq.com/s/neCqyfed0GzV4SeCTQpMdg

本文为Milvus Week系列第三篇,该系列旨在分享Milvus的创新与实践成果,以下是DAY3内容划重点:

Milvus2.6中,Zilliz借助Geolocation Index for Milvus,首次将地理空间数据与向量检索融合,使 AI 可以在理解语义的同时,理解空间。

在当今的智能时代,地理位置(Geolocation)信息,已经结合 AI 推荐、智能调度、自动驾驶等场景,成为理解世界、做出决策的关键数据。

比如,当我们在 Doordash 或 美团 上点餐时,除了会关注用户与餐厅之间的距离,还会综合考虑餐厅评分、骑手位置、交通状况、以及用户个人偏好向量等综合数据。

再比如, 当自动驾驶车辆在城市道路上行驶时,结合地理位置信息,它需要在毫秒级时间内完成路径规划、障碍物检测和场景语义理解。

而实现这一切,都离不开对地理空间数据的高效索引与检索。

过去,地理数据与向量数据往往存在于两套系统中:

  • 一套用于存储坐标与空间关系(如经纬度、多边形区域等);

  • 另一套用于 AI 模型生成的语义嵌入与相似性检索。

这种割裂导致了系统复杂、数据同步困难、查询效率低下的问题。

为了解决以上问题,在最新的Milvus2.6中,Zilliz借助Geolocation Index for Milvus,首次将地理空间数据(Geometry)与向量检索(Vector Search)有机融合,使 AI 可以在理解语义的同时,理解空间。

通过引入基于 R-Tree 的空间索引机制,Milvus 不仅支持高维向量相似搜索,还能执行高效的地理空间查询(如 st_contains、st_within、st_distance 等),让空间感知的智能检索成为现实。

这意味着,无论是本地生活平台想要为用户找到“此刻最近、最合适的美食”,还是自动驾驶系统需要判断“车辆是否即将进入禁行区域”,Milvus 都能以统一的数据存储与查询方式完成。

01 本地生活服务:让智能推荐更懂附近有什么你爱吃的

以 Doordash 和 美团 为例,这类平台每天要在上亿次请求中完成复杂的地理计算。消费者打开 App 的那一刻,系统就要基于位置、时间、口味偏好、配送时长、实时交通等维度,计算出此刻、此地最合适的餐厅或骑手。

传统方案通常需要分别查询地理数据库与推荐系统,然后再进行多轮过滤与排序。Milvus 的 Geolocation Index 让这一流程显著简化:

  • 统一存储:地理坐标与用户画像、商户向量嵌入存储在同一系统中。

  • 联合检索:既能基于“距离我 3 公里以内的商户”筛选,又能基于相似口味或评分进行向量搜索。

  • 动态决策:结合实时骑手分布和交通状况,快速匹配最近可用骑手。

最终,平台可以在一次检索中完成空间 + 语义的双维度决策。例如,当用户搜索“咖喱饭”,系统不仅返回文本匹配度高的商户,还能在用户当前位置附近优先推荐配送速度更快、口味相似度更高的选项。

02 自动驾驶:让车辆决策更智能

在自动驾驶场景中,地理空间索引是感知、定位、决策的基础数据结构之一。车辆需要在毫秒级时间内完成地图匹配、障碍物检测和路径规划。

Milvus 的 Geometry 类型结合 R-Tree 索引,可以存储和检索各种几何形状数据,例如:

  • 道路边界(LineString)

  • 交通标识区域(Polygon)

  • 障碍物(Point)

这些数据可以被高效地索引和查询,做到让地理数据真正参与到 AI 决策闭环中。例如,自动驾驶系统可通过 R-Tree 快速判断当前车辆坐标是否位于某个道路区域内,或相交于前方障碍物区域。

同时,结合向量嵌入(如感知模块生成的场景向量),系统还可实现更智能的语义检索,如:在 50 米范围内寻找与当前交通模式最相似的历史片段,帮助模型快速理解场景并优化决策。

03 Milvus 的升级:Geometry+ R-Tree +语义

(1)Geometry:最常用的原生地理空间数据类型

Zilliz 在 Milvus 2.6 中引入了一个关键能力:原生地理空间数据类型 Geometry。这使得向量数据库首次具备了理解地理的能力。

Milvus 的 Geometry 类型不仅支持点(Point),还支持线(LineString)、多边形(Polygon)等复杂空间结构。

这样一来,Milvus 可以直接存储:商户位置(Point)、配送区域(Polygon)、无人车行驶轨迹(LineString),从单纯的向量数据库,升级为同时支持 空间数据 + 语义向量 的多模态数据库。

Geometry 类型的数据使用 WKT(Well-Known Text),  例如:

data = [    {         "id": 1,        "geo": "POINT(116.4074 39.9042)",        "vector": vector,    }]

(2)R-Tree:为Geometry 打造的空间索引

有了 Geometry 类型,还需要高效的空间检索筛选能力。

Milvus 通过两阶段筛选(粗筛+精筛)对地理数据进行精确过滤。

  • 粗筛:通过 R-Tree 等空间索引进行快速剪枝

  • 精筛:对查询区域的边角区域进行精确过滤

在这个过程中, Milvus 引入了经典的空间索引结构 —— R-Tree (Rectangle Tree)

R-Tree 是专为多维空间数据(尤其是 Geometry 几何类型,如点、线、面、多边形等)设计的平衡树索引结构,其核心逻辑是通过最小边界矩形(MBR, Minimum Bounding Rectangle)把空间对象分组,形成类似 B-Tree 的层级结构,通过空间近似与分层索引解决几何对象的高效检索问题。

  • 每个节点都保存一个包围盒(bounding box)

  • 查询时可以快速“剪枝”,仅访问可能相交的区域

  • 平均查询复杂度为 O(log N)

  • Milvus 使用 boost 库的 R-Tree 索引。利用其高性能、并发安全特点。

为了 R-Tree 索引提高效率,Milvus 是通过查询区域的 bounding box 与 R-Tree 索引快速筛选。对于用户传入的查询区域不规则时,R-Tree 索引会筛选出一些不符合条件的数据。这时候就需要计算查询区域与这些数据的关系从而来达到精确筛选的目的。

Milvus 内部使用 GEOS 库进行空间关系判断(如 st_within、st_intersects、st_distance等)

目前,Milvus 支持的空间过滤算子有如下几个:

  • st_intersects(A, B):计算几何空间 A 是否与几何空间 B 相交。

  • st_contains(A, B):计算几何空间 A 是否完全包含几何空间 B(不含边界)。

  • st_within(A, B):计算几何空间 A 是否完全被 B 包含 (st_contains 的反操作)。

  • st_covers(A, B):计算几何空间 A 是否完全覆盖几何空间 B (含边界)。

  • st_touches(A, B):计算几何空间 A 是否与几何空间 B 仅在边界接触。

  • st_equals(A, B):计算几何空间 A 是否与几何空间 B 完全相同。

  • st_overlaps(A, B):计算几何空间 A 是否与几何空间 B 有部分重叠。

  • st_dwithin(A, B, d):计算几何空间 A 与几何空间 B 的距离是否小于 d。

(3)向量语义 + Geo:双索引融合的架构

基于Geometry+ R-Tree 能力,Zilliz 在打造Milvus的过程中,会将 向量索引 与 地理索引 结合使用:

执行流程如下:

  1. 通过 R-Tree 过滤符合地理范围的数据(如 within 2km);

  2. 再向量索引筛选出 Top-N 相似。

04 尾声:向量 + Geo,让 AI 拥有位置感知

地理位置不仅仅是坐标,它是现实世界的语义锚点

在 Zilliz 的新一代数据库中,向量与地理信息正逐渐融合为一种统一的数据结构:

  • 支持 向量 + Geo + 时间 的联合检索;

  • 支持 空间感知推荐系统

  • 支持 多模态 LBS(Location Based Search)

未来,AI 不只是理解内容,它还将理解——内容在哪里、在何时最有意义

THE END !

文章结束,感谢阅读。您的点赞,收藏,评论是我继续更新的动力。大家有推荐的公众号可以评论区留言,共同学习,一起进步。

<think>我们正在处理用户关于docker-compose的问题。用户在执行命令时遇到两个错误: 1. WARN[0000] ... `version` is obsolete 2. no such service: milvus-standalone 首先,我们需要理解这两个错误的原因。 第一个警告:`version is obsolete` 是因为在docker-compose.yml文件中使用了旧版本的Compose文件格式。Docker Compose的版本演进中,新版本的Docker Compose已经弃用了旧版本的语法。通常,我们会在文件顶部看到类似于`version: &#39;2.x&#39;`或`version: &#39;3.x&#39;`的声明。但是,最新的Docker Compose(特别是v2及以后)推荐使用没有`version`字段的Compose文件,或者使用兼容的版本。这个警告一般不会导致服务运行失败,但需要关注。 第二个错误:`no such service: milvus-standalone` 表明Docker Compose无法找到名为`milvus-standalone`的服务。这可能有以下几个原因: - docker-compose.yml文件中没有定义名为`milvus-standalone`的服务。 - 服务名称拼写错误(大小写敏感?)。 - 用户可能没有在正确的目录下执行命令(即docker-compose.yml文件不在当前目录)。 - 用户可能使用了错误的项目名称(即通过`-p`指定了项目名,导致服务名发生了变化)? 既然用户提到的是Milvus的docker-compose文件,我们可以假设用户是从Milvus官方获取的docker-compose.yml文件。Milvus官方提供的standalone模式的文件中,服务名称可能是`standalone`而不是`milvus-standalone`?我们需要用户确认。 然而,用户之前执行的命令是`sudo docker-compose logs milvus-standalone`,所以我们需要检查服务名称。 解决步骤: 1. 确认当前目录下是否存在docker-compose.yml文件,并且该文件是否包含所需的服务定义。 - 用户可以使用`ls`命令查看当前目录下的文件。 - 使用`cat docker-compose.yml`来查看文件内容,特别是服务名称。 2. 调整docker-compose.yml文件的版本问题(以消除警告): - 如果使用的是较老的版本声明(如`version: &#39;2.x&#39;`或`version: &#39;3.x&#39;`),可以尝试去掉`version`行,或者更新为最新的版本格式(如`version: &#39;3.8&#39;`,但要注意最新版本支持的最高版本号)。 - 注意:新版本的Docker Compose(v1.27.0+)支持Compose文件格式版本为2.x和3.x,但会警告它们已被弃用。而Docker Compose v2(作为Docker Desktop的一部分)使用Compose Specification,它不再需要`version`字段,而是通过`services`等顶级关键字来定义。 3. 关于服务名称错误: - 在docker-compose.yml文件中,服务的名称是由`services`下面的键名决定的。例如: services: standalone: ... 那么服务名称就是`standalone`,而不是`milvus-standalone`。 - 因此,用户应该执行:`sudo docker-compose logs standalone` - 或者,如果用户使用的是Milvus官方提供的standalone docker-compose文件,通常服务名称为`standalone`。 4. 如果用户确实想使用`milvus-standalone`作为服务名,那么需要修改docker-compose.yml文件,将服务名称改为`milvus-standalone`。 5. 另一种可能是用户在启动容器时指定了项目名称(通过`-p`参数),那么服务名称会被加上项目前缀。但默认情况下,项目名称是当前目录名。用户可以使用`docker-compose ps`来查看当前项目下的服务名称。 综合以上,我们可以建议用户进行如下操作: 步骤1:确认当前目录下docker-compose.yml文件的内容,特别是服务名称。 命令:`sudo cat docker-compose.yml | grep -A 5 services` 步骤2:切换到包含docker-compose.yml文件的目录执行命令。 步骤3:如果服务名称确实是`standalone`,则使用: `sudo docker-compose logs standalone` 步骤4:更新docker-compose.yml文件以消除版本警告(可选,但推荐): - 删除`version`行(如果文件中只有`version`和`services`等简单结构,并且你的Docker Compose版本支持无版本格式)。 - 或者将版本号更新为较新的版本(如`version: &#39;3.8&#39;`),但需要确认该版本仍然被支持。 注意:如果用户使用的是Docker Compose v2,那么命令可能是`docker compose`(没有横杠),但是用户之前使用的是`docker-compose`(带横杠),说明可能是v1,但两种命令都可能存在。v1和v2在语法上大部分兼容。 另外,关于`no such service`错误,还有一种可能是服务从未被创建(即从未运行过`docker-compose up -d`)。因此,用户需要先确保服务已经创建(可以通过`docker-compose ps`查看)。 总结建议: 1. 检查服务名称:通过查看docker-compose.yml文件确认服务名称。 2. 确保服务已经创建:运行`sudo docker-compose ps`查看服务列表。 3. 使用正确的服务名称执行logs命令。 如果用户确认服务名称为`standalone`,那么命令应为: `sudo docker-compose logs standalone` 如果用户仍然想使用`milvus-standalone`作为服务名称,则可以修改docker-compose.yml文件,将原来的服务名称(如`standalone`)改为`milvus-standalone`,然后重新启动服务(`sudo docker-compose up -d`),然后再执行日志命令。 最后,关于版本警告,我们可以建议用户更新docker-compose.yml文件,删除或更新`version`字段。例如,Milvus最新的standalone的docker-compose文件已经不再使用`version`字段(参考Milvus官方文档)。 参考Milvus官方提供的docker-compose.yml(以standalone模式为例): https://github.com/milvus-io/milvus/blob/master/deployments/docker/standalone/docker-compose.yml 在该官方文件中,我们看到它没有使用`version`字段,并且服务名称为`standalone`。 因此,用户可能使用的是旧版本的Milvus docker-compose文件,或者自己修改过。我们建议用户下载最新版本的文件替换。 所以,如果用户的问题仍未解决,可以尝试重新下载官方docker-compose文件。 但是,我们首先需要用户确认当前docker-compose.yml文件的内容。 由于用户无法直接交互,我们给出通用的解决方案: 解决方案总结: 1. 查看当前目录下的docker-compose.yml文件,确认服务名称: ```bash sudo cat docker-compose.yml ``` 2. 如果服务名称为`standalone`,则使用以下命令查看日志: ```bash sudo docker-compose logs standalone ``` 3. 如果服务名称不是`standalone`,则使用实际的服务名称。 4. 如果服务名称确实是`milvus-standalone`,但是错误仍然存在,请检查是否在正确的目录下运行命令(即docker-compose.yml所在的目录)。 5. 如果以上步骤都无法解决,尝试更新docker-compose.yml文件,去掉`version`行(或者将其注释掉),并将文件内容更新为类似Milvus官方的最新内容。 6. 重新启动服务(在修改了docker-compose.yml文件后): ```bash sudo docker-compose down sudo docker-compose up -d ``` 然后再尝试查看日志。 7. 如果用户从未启动过服务,需要先启动服务: ```bash sudo docker-compose up -d ``` 8. 如果用户使用的是Docker Compose v2,可以尝试使用`docker compose`命令(不带横杠)来代替`docker-compose`,但注意命令的兼容性。 注意:以上命令均需要sudo,如果用户有权限问题,可能需要以root用户运行或配置docker组。 最后,由于用户使用的是Milvus,建议参考Milvus官方文档中关于standalone部署的部分。 </think>### 解决 Docker Compose 执行 `logs milvus-standalone` 时报错的方案 #### 错误原因分析 1. **`version is obsolete` 警告** Docker Compose V2 已弃用旧版 Compose 文件格式(如 `version: &#39;2.x&#39;`),需更新语法[^1]。 2. **`no such service: milvus-standalone` 错误** 表明 Docker Compose 未找到名为 `milvus-standalone` 的服务,可能原因包括: - 服务名称拼写错误 - 未在 `docker-compose.yml` 所在目录执行命令 - 服务未正确启动 - YAML 文件格式错误 #### 解决步骤 ##### 第一步:验证服务状态 ```bash # 查看所有运行中的服务 sudo docker-compose ps # 检查所有定义的服务(包括未运行的) sudo docker-compose config --services ``` 若输出中无 `milvus-standalone`,说明服务名称错误或未定义。 --- ##### 第二步:修正服务名称 1. 打开 `docker-compose.yml` 文件: ```bash sudo nano /home/smt/milvus/docker-compose.yml ``` 2. 在 `services:` 部分确认实际服务名称(如 Milvus 官方模板通常命名为 `standalone`): ```yaml services: standalone: # ← 这才是实际服务名 image: milvusdb/milvus-standalone ... ``` 3. 使用正确的服务名查看日志: ```bash sudo docker-compose logs standalone # 替换为实际服务名 ``` --- ##### 第三步:更新 Compose 文件格式 1. 删除或更新 `version` 字段(推荐完全移除): ```yaml # 原始文件可能包含 version: &#39;3.8&#39; # ← 删除此行 services: standalone: ... ``` 2. **重要**:检查缩进格式 删除 `version` 后需确保 `services` 顶格: ```yaml services: # 无缩进 standalone: # 缩进2空格 image: ... ``` --- ##### 第四步:重启服务 ```bash # 停止服务(在 YAML 文件目录执行) sudo docker-compose down # 重新启动 sudo docker-compose up -d # 查看日志确认 sudo docker-compose logs standalone # 使用正确的服务名 ``` --- ##### 第五步:特殊情况处理 若问题仍存在: 1. **检查文件路径** 确保命令在 `/home/smt/milvus/` 目录执行: ```bash cd /home/smt/milvus && sudo docker-compose logs standalone ``` 2. **验证 YAML 语法** ```bash sudo docker-compose config # 验证文件是否有语法错误 ``` 3. **下载最新官方模板**(适用于 Milvus): ```bash wget https://raw.githubusercontent.com/milvus-io/milvus/master/deployments/docker/standalone/docker-compose.yml ``` #### 预期结果 - 移除 `version` 字段后,`obsolete` 警告消失 - 使用正确服务名后,日志正常输出 > **注意**:Docker Compose V2 兼容无版本的 Compose 文件,但仍支持旧版语法(会有警告)[^2]。推荐遵循官方最新规范。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值