空间检索(下)

简介: 本文探讨“查找最近的加油站”与“查找附近的人”的本质区别,前者需动态调整查询范围以获取最近K个结果。通过GeoHash编码实现高效空间检索,提出逐步扩大查询范围的策略,并利用其一维排序特性,采用统一索引结构支持多级范围查询,在减少查询次数的同时降低存储开销,提升检索效率。

空间检索(下):「查找最近的加油站」和「查找附近的人」有何不同?
上一讲我们讲了,对于查询范围固定的应用需求,比如「查找附近的人」,我们可以根据规划好的查询区域大小,均匀划分所有的空间,然后用 GeoHash 将坐标转换为区域编码,以该区域编码作为 Key 开始检索。这样,我们就可以查到并取出该区域中的目标数据,对这些数据进行精准计算然后排序输出了。

但是,并不是所有应用的查询范围都是不变的。在一些基于地理位置的服务中,我们并不关心检索结果是否就在我们「附近」,而是必须要找到「最近」的一批满足我们要求的结果。这怎么理解呢?

我来举个例子,我们在长途自驾游的时候,突然发现车快没油了。这个时候,我们要在一个导航地图中查找最近的 k 个加油站给车加油,这些加油站可能并不在我们附近,但地图又必须要返回最近的 k 个结果。类似的情况还有很多,比如说,我们要查询最近的医院有哪些,查询最近的超市有哪些。那对于这一类的查询,如果当前范围内查不到,系统就需要自动调整查询范围,直到能返回 k 个结果为止。

对于这种需要动态调整范围的查询场景,我们有什么高效的检索方案呢?今天,我们就来探讨一下这个问题。

直接进行多次查询会有什么问题?

我们就以查找最近的加油站为例,一个直观的想法是,我们可以先获得当前位置的 GeoHash 编码,然后根据需求不停扩大查询范围进行多次查询,最后合并查询结果。这么说比较抽象,我们来分析一个具体的位置编码。

假设我们当前地址的 GeoHash 编码为 wx4g6yc8,那我们可以先用 wx4g6yc8 去查找当前区域的加油站。如果查询的结果为空,我们就扩大范围。扩大查询范围的思路有两种。

第一种思路是,一圈一圈扩大范围。具体来说就是,我们第一次查询周边 8 个邻接区域,如果查询结果依然为空,就再扩大一圈,查询再外圈的 16 个区域。如果还是不够,下一次我们就查询再外圈的 24 个区域,依此类推。你会发现,这种方案的查询次数会成倍地增加,它的效率并不高。

查询周边区域查询周边区域

逐步扩大查询周边区域

另一种思路是,我们每次都将查询单位大幅提高。比如说,直接将 GeoHash 编码去掉最后一位,用 wx4g6yc 再次去查询。如果有结果返回,但是不满足要返回 Top K 个的要求,那我们就继续扩大范围,再去掉一个编码,用 wx4g6y 去查询。就这样不停扩大单位的进行反复查询,直到结果大于 k 个为止。
扩大查询单位扩大查询单位

逐步扩大查询单位

和第一种查询思路相比,在第二种思路中,我们每次查询的区域单位都得到了大范围的提升,因此,查询次数不会太多。比如说,对于一个长度为 8 的 GeoHash 编码,我们最多只需要查询 8 次(如果要求精准检索,那每次查询就扩展到周围 8 个同样大小的邻接区域即可,后面我就不再解释了)。

这个检索方案虽然用很少的次数就能「查询最近的 k 个结果」,但我们还需要保证,每次的查询请求都能快速返回结果。这就要求我们采用合适的索引技术,来处理 GeoHash 的每个层级。

比如说,如果使用基于哈希表的倒排检索来实现,我们就需要在 GeoHash 每个粒度层级上都分别建立一个单独的倒排表。这就意味着,每个层级的倒排表中都会出现全部的加油站,数据会被复制多次,这会带来非常大的存储开销。那我们是否有优化存储的方案呢?

我们可以利用 GeoHash 编码一维可排序的特点,使用数组或二叉检索树来存储和检索。由于数组和二叉检索树都可以支持范围查询,因此我们只需要建立一份粒度最细的索引就可以了。这样,当我们要检索更大范围的区域时,可以直接将原来的查询改写为范围查询。具体怎么做呢?

我来举个例子。在检索完 wx4g6yc8 这个区域编码以后,如果结果数量不够,还要检索 wx4g6yc 这个更大范围的区域编码,我们只要将查询改写为「查找区域编码在 wx4g6yc0 至 wx4g6ycz 之间的元素」,就可以利用同一个索引,来完成更高一个层级的区域查询了。同理,如果结果数量依然不够,那下一步我们就查询「区域编码在 wx4g6y00 至 wx4g6yzz 之间的元素」,依此类推。

相关文章
|
1天前
|
存储 Serverless
哈希冲突
哈希冲突可通过优化哈希函数或采用冲突解决策略应对。开放寻址法通过线性、二次探查或双散列寻找空位,但易导致聚集,影响效率;链表法则在冲突位置构建链表,避免抢占,更适应动态数据,是常用方案之一。
|
1天前
|
NoSQL 索引
SSTable 的分层管理设计
SSTable分层管理通过将文件按层级组织,逐层合并,控制每层容量上限,减少多路归并规模,避免全量重叠,提升查询效率与系统性能,是LevelDB高效读写的核心设计。
|
1天前
|
存储 自然语言处理 分布式计算
索引构建
搜索引擎如何为万亿网页构建索引?通过分治与多路归并,将文档拆分为小集合,在内存中生成倒排索引后写入磁盘,再合并多个有序临时文件,最终生成全局倒排文件。词典可加载至内存或用B+树管理,实现高效检索。该过程类似MapReduce,支持分布式扩展。
|
1天前
|
存储 负载均衡 搜索推荐
大规模检索系统
本讲介绍大规模检索系统如何通过分布式技术加速检索。通过索引拆分,将倒排索引分散到多台服务器内存中,减少单机数据规模和磁盘访问,从而提升单次查询效率。结合分发服务器与负载均衡,实现高吞吐、低延迟的分布式检索架构。
|
1天前
|
存储 搜索推荐 索引
跳表法加速倒排索引
跳表、哈希表与位图法可加速倒排索引。跳表通过多层链表实现快速跳转,将归并查找时间降至O(log n);哈希表适用于小集合查大集合,查询可达O(1);位图则利用位运算高效求交集,适合短posting list场景,显著提升检索效率。
|
1天前
|
存储 算法 搜索推荐
数组的检索效率
二分查找通过将有序数组不断折半,每次比较中间值与目标值,缩小搜索范围至一半,实现O(log n)高效检索,显著优于遍历的O(n),适用于大规模有序数据查询。
|
1天前
|
存储 API 索引
数据结构的存储方式
数据结构底层存储只有数组和链表两种,其他如栈、队列、树、图等均为其衍生。数组支持随机访问但扩容困难,链表灵活增删但无法随机访问。所有数据结构的操作本质为“增删查改”,遍历方式分为线性迭代与非线性递归。理解二者差异,是掌握各类高级数据结构的基础。(238字)
|
1天前
|
存储 Java API
数组(顺序存储)基本原理
本章讲解数组的底层原理,区分静态与动态数组。通过静态数组实现动态数组的增删查改,揭示随机访问O(1)的成因与连续内存的利弊,助你理解数据结构本质。
|
1天前
|
存储 缓存 NoSQL
查找对应的 SSTable 文件
通过分层结构与二分查找快速定位SSTable,结合BloomFilter过滤和索引区加速查询。利用table cache与block cache缓存机制,减少磁盘IO,提升检索效率。整个过程高效有序,适用于大规模数据检索场景。(238字)
|
1天前
|
自然语言处理 搜索推荐 UED
最近邻检索(上
在搜索引擎与推荐系统中,相似文章去重至关重要。本文介绍基于向量空间模型的近邻检索方法,将文档表示为TF-IDF加权的高维向量,通过计算向量间相似度识别重复内容。为提升检索效率,引入局部敏感哈希(LSH)技术,快速筛选潜在相似文章,有效优化用户体验。