LSM 树是如何检索的?

简介: LSM树检索先查内存中的C0树,命中则直接返回;未命中再查磁盘C1树。为避免返回过期数据,删除操作会在C0树中标记key为“已删除”,查询时遇此标记即返回失败,并在滚动归并时批量清理C1树中对应数据,实现高效、延迟删除。

现在你已经知道 LSM 树的组织过程了,我们可以来看,LSM 树是如何完成检索的。

因为同时存在 C0 和 C1 树,所以要查询一个 key 时,我们会先到 C0 树中查询。如果查询到了则直接返回,不用再去查询 C1 树了。

而且,C0 树会存储最新的一批数据,所以 C0 树中的数据一定会比 C1 树中的新。因此,如果一个系统的检索主要是针对近期数据的,那么大部分数据我们都能在内存中查到,检索效率就会非常高。

那如果我们在 C0 树中没有查询到 key 呢?这个时候,系统就会去磁盘中的 C1 树查询。在 C1 树中查到了,我们能直接返回吗?如果没有特殊处理的话,其实并不能。你可以先想想,这是为什么。

我们先来考虑一种情况:一个数据已经被写入系统了,并且我们也把它写入 C1 树了。但是,在最新的操作中,这个数据被删除了,那我们自然不会在 C0 树中查询到这个数据。可是它依然存在于 C1 树之中。

这种情况下,我们在 C1 树中检索到的就是过期的数据。既然是过期的数据,那为了不影响检索结果,我们能否从 C1 树中将这个数据删除呢?删除的思路没有错,但是不要忘了,我们不希望对 C1 树进行随机访问。这个时候,我们又该怎么处理呢?

我们依然可以采取延迟写入和批量操作的思路。对于被删除的数据,我们会将这些数据的 key 插入到 C0 树中,并且存入删除标志。如果 C0 树中已经存有这些数据,我们就将 C0 树中这些数据对应的 key 都加上删除标志。

这样一来,当我们在 C0 树中查询时,如果查到了一个带着删除标志的 key,就直接返回查询失败,我们也就不用去查询 C1 树了。在滚动归并的时候,我们会查看数据在 C0 树中是否带有删除标志。如果有,滚动归并时就将它放弃。这样 C1 树就能批量完成「数据删除」的动作。

相关文章
|
11月前
|
编解码 算法 前端开发
java后端开发学习路线+避坑指南
java后端开发学习路线+避坑指南
|
11月前
|
存储 索引
如何使用「全量索引结合增量索引」方案?
采用“全量索引+增量索引”方案可高效处理大规模数据更新。系统周期生成不可变的全量索引,提升检索性能;实时新增数据则构建内存中的增量索引,支持快速写入。查询时合并两者结果,并通过删除列表标记已删数据,避免脏数据返回。结合Double Buffer机制,还可实现无锁访问,显著提升系统并发能力与检索效率。(238字)
|
11月前
什么是局部敏感哈希?
局部敏感哈希(LSH)是一种将高维数据映射为低维编码的技术,使相似数据更可能生成相近或相同的哈希值。不同于传统哈希对微小变化敏感,LSH通过随机超平面划分空间,使邻近点在多个划分中大概率落入同侧,从而获得相似哈希码。常用海明距离衡量哈希值相似性,适用于近似最近邻搜索与大规模文本去重等场景。
|
11月前
|
机器学习/深度学习 搜索推荐 算法
推荐引擎:没有搜索词,「头条」怎么找到你感兴趣的文章?
资讯类App通过“下拉刷新”精准推荐内容,背后依赖推荐引擎的检索技术。它基于用户行为数据构建用户画像与文章画像,结合协同过滤、内容召回等算法,实现个性化推荐,并通过多路召回与分层排序提升效率与准确性。
|
11月前
|
负载均衡 算法 网络协议
负载均衡:节点负载差距这么大,为什么收到的流量还一样?
本文讲解RPC框架中的负载均衡机制,对比传统Web负载均衡,阐述其由调用端自主选择节点的优势。针对业务提出“智能调控流量”需求,提出自适应负载均衡方案:通过收集服务节点的CPU、内存、响应耗时等指标进行打分,动态调整节点权重,结合随机权重算法实现流量合理分配,提升系统稳定性和可用性。
|
11月前
|
Docker 容器
Dockerfile
Dockerfile是构建Docker镜像的脚本文件,包含一系列指令,每条指令创建一个镜像层。编写时需用大写指令、按序执行,#为注释。通过docker build构建镜像,再用docker run运行容器。构建时,Docker引擎逐条执行指令,提交每一层变更,最终生成新镜像。
|
11月前
|
存储 负载均衡 索引
简单的分布式结构是什么样的?
简单分布式结构通过分发服务器将请求分配给多台具备完整索引的索引服务器,实现负载均衡与高吞吐。虽不减少单次查询时间,但可通过拆分索引、分散内存加载来降低检索规模,提升单次效率,是分布式检索优化的关键思路。(238字)
|
11月前
|
存储 缓存 自然语言处理
如何使用磁盘上的倒排文件进行检索?
利用倒排文件检索时,优先将词典加载至内存以提升效率。通过哈希表或B+树定位关键词,再读取对应文档列表(posting list)。若其过长,则采用分层索引(如跳表、B+树)按需加载;结合LRU缓存常用数据,减少磁盘IO,提高检索性能。
|
11月前
|
存储 索引
直接进行多次查询会有什么问题?
直接多次查询会增加次数与开销。以GeoHash查找最近加油站为例,逐步扩大范围虽可行,但“逐圈扩展”效率低,查询次数多;“缩短编码”虽快,却需重复二分查找,浪费资源。优化需平衡查询次数与存储成本。
|
11月前
|
存储
如何利用批量写入代替多次随机写入?
LSM树通过延迟写入优化磁盘I/O:数据先写入内存中的C0树,达到阈值后批量以块为单位写入磁盘的C1树。C1树采用B+树结构且叶子节点全满,无需预留空间,提升写入效率,适用于高并发写场景。(239字符)