LevelDB 多版本和压缩

原创 于 2025-08-11 11:28:37 发布 · 568 阅读 · 14 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#java #算法 #数据库

作为高性能键值存储库，LevelDB 的高效运行离不开多版本机制与压缩策略的支撑。多版本如何实现数据的并发读写与历史回溯？压缩机制怎样平衡存储效率与访问性能？当数据遭遇异常，恢复机制又如何保障可靠性？本文将围绕这三大核心维度，拆解 LevelDB 的底层设计智慧。

文件类型：

图片

多版本

版本管理中相关的类

  • Version标识了一个版本，主要信息是这个版本包含的SSTable信息；

  • VersionSet是一个版本集，里面保存了Version的一个双链表，其中有一个Version是当前版本，因为只有一个实例，还保存了其它的一些全局的元数据，Dummy Version是链表头；

  • VersionEdit保存了要对Version做的修改，在一个Version上应用一个VersionEdit，可以生成一个新的Version；

  • Builder是一个帮助类，帮助Version上应用VersionEdit，生成新版本

VersionSet 是一个双链表结构，每个 Version 代表了一个版本

图片

将当前的 版本 和 VersionEdit 合并之后，就得到了一个新的版本 VersionEdit就是一次 Minor Compaction、或者是 Major Compaction的结果

图片

版本管理的工作流程：

  • VersionSet里保存着当前版本，以及被引用的历史版本；

  • 当有Compaction发生时，会将更改的内容写入到一个VersionEdit中；

  • 利用Builder将VersionEdit应用到当前版本上面生成一个新的版本；

  • 将新版本链接到VersionSet的双链表上面；

  • 将新的版本设置为当前版本；

  • 将旧的当前版本Unref，就是引用计数减1。

图片

版本控制中的引用计数：

  • 每个Version包含了一个引用，当前版本的 ref 为 1

  • 当有迭代器需要遍历数据库时，这个版本的 ref ++ 等于 2

  • 其他线程不断写入，触发 compaction，生成新版本

  • 新版本 + 1，老版本 - 1

  • 因为 老版本为 1，所以不会被删除，直到迭代接受，ref = 0

  • 如果 Version 的ref 为0，则可以删除了

实际存储的时候，是存入dbname/MANIFEST-[0-9]+ 这样的文件
CURRENT 指向最新的 manifest 文件
Version 相当于 一个 manifest 文件，VersionSet 则管理多个 manifest 文件
VersionSet 头结点指向最新的 manifest 文件

FileMetaData
sstable的元信息

图片

Version
位置：db/version_set.h
读取数据库时，就需要 Version 里面的信息

图片

VersionEdit

图片

VersionEdit 中包含了两个函数

图片

这个就是一个 编码，一个解码
将 dst 中的信息，写入到所有变量中，以及从 变量中解码信息到 Slice 中

VersionSet

图片

VersionSet::Builder

辅助类
主要变量：

图片

LevelFileNumIterator
主要变量

图片

其中 new 出来的 两次迭代器，就使用到了 LevelFileNumIterator

图片

builder 版本变迁过程

图片

总结一下

  • 整体是 VersionSet 的双链表结构，一个版本由 Version 表示

  • VersionEdit 是一次变更，比如 sstable新增，删除(通过压缩产生)，通过 应用 VersionEdit 就可以得到一个新版本

  • builder 会加速变更，可以将多个 VersionEdit 一次性应用

  • 每个 Version 内部关联了一个 FileMetaData，表示一个 sstable的元数据，内部包含了 min、max key方便定位

  • MANIFEST 实际关联了一个 log 文件，还会将变更的内容当做 log 记录下来，等启动恢复的时候，就会读取这些log文件

压缩

压缩，包含两种

  • Minor Compaction，mem-table写满会后刷盘，写入到 level-0 中

  • Major Compaction，某个层的文件太多，需要将部分文件推入更高层

图片

Minor Compaction过程

图片

Minor Compaction 时序图

图片

WriteLevel0Table过程

  • 得到一个新的 FileMetaData 编号，就是 VersionSet->next_file_number_++

  • 调用 BuildTable，其生成的 TableFileName 是根据 FileMetaData的编号得到的

  • 获取 min、max key，然后确定将 ss-table 推入哪个层级，调用 PickLevelForMemTableOutput

  • 将 压缩状态存入 CompactionStats[level] 中，这里的 level 固定为 PickLevelForMemTableOutput 返回的层级

BuildTable 过程：

  • 从 skip-list 的第一个元素开始遍历，一直到结束，将这些 key-value 加入到 TableBuilder

  • 同时记录 FileMetaData 的最大、最小、key数量、文件size

  • 将数据写入到磁盘

PickLevelForMemTableOutput

  • 如果跟 0层的有重叠，则推入 0层

  • 检查方式是，对于 level0，需要遍历所有文件，检查每个文件跟min、max key 是否有重叠

  • 非 level 0的，则使用 二分查找 当前层的所有文件

  • 还会检查 level 0、level 1 在其祖父层级(对应的就是 level 2、level 3中，是否重叠太多

  • 默认的最大单个文件大小为 2M，如果一次重叠的数量 > 20M，PickLevelForMemTableOutput 会继续往更深层级查找

  • 不过限制了最大查找层级为 2，这也是做了一个权衡

Major Compaction 的过程

图片

Compaction类

图片

ManualCompaction 类

图片

Compaction 的触发方式

  • Manual Compaction

  • Size Compaction

  • Seek Compaction

手动压缩的触发函数：

图片

Size compation

  • 实现函数为： void VersionSet::Finalize(Version* v)

  • 对于 leve 0，如果 > 4 就会触发

  • 超过 0 的，如果超过了 10^n MB 就会触发

  • 由于 ss-table 的不变性，只有版本变更的时候才会变化

  • 在每次版本变更之后，调用 Finalize，计算出比例最大的 level，下次就从这里开始

  • 由于一次压缩要很久，这里会记录一个 level 的key，std::string compact_pointer_[config::kNumLevels];

  • 下次再压缩这一层的时候，就从这个 key 开始继续压缩

Seek Compaction

  • 为读做的优化，DB::GET、DBIter 时候，如果读取了超过一个 ss-table 则需要优化

  • 对于读取 超过一个 的ss-table，对于第一个 ss-table做一个 减操作，如果等于 0了，就需要做压缩

  • 所以 seek 是精确到某个 ss-table 的

  • 迭代的时候，是每读取 2M数据，就模拟一个key，做对应的 ss-table–

  • 初始值，static_cast((f->file_size / 16384U))

  • 一次Seek花费10ms；

  • 读写1MB的花费10ms （100MB/s）；

  • 而Compaction 1MB的数据花费25MB左右的IO

执行过程

  • 执行优先级是 Manual、Size、Seek

  • 前两者是根据 start、end key 选择某一个level的多个文件

  • 后者只有确定的一个文件

  • 根据 level 层的文件，再确定 level + 1层的文件，之后再反向 level 层扩大 level 的输入范围

  • 最后调用多路合并，进行压缩

图片

扩大输入文件集合

  • 确定起始key、结束key

  • 在level i层中，查找与起始输入文件有key重叠的文件，如图中红线所标注，最终构成level i层的输入文件；

  • 利用level i层的输入文件，在level i+1层找寻有key重叠的文件，结果为绿线标注的文件，构成level i，i+1层的输入文件；

  • 最后利用两层的输入文件，在不扩大level i+1输入文件的前提下，查找level i层的有key重叠的文件，结果为蓝线标准的文件，构成最终的输入文件；

图片

归并的过程：

  • 迭代按照Internal Key的顺序进行，多个key则按seq number 降序排列

  • 相同的 key只有第一个有效，因为它的 seq 是最大的

  • 碰到一个删除时，并且它的 seq_number <= 最新快照，会判断更高层是否有这个key

  • 如果有则无法丢弃这个删除操作，因为一旦丢弃，更高层又可见了，不存在可则可以删除

  • 如果ss-table达到 2M，或者和上层文件重叠超过 10个，这两个条件任意一个触发就会 生成一个 ss-table写磁盘

图片

数据删除的处理

  • 如果是覆盖写入，则当做一个删除处理，即按照降序排序，前面的覆盖后面的，后面重复的key可以忽略

  • 如果是删除标记，并且level + 1层没有这个key，则可以删除

  • 如果这个key 的seq_number <= 最老快照的序列号，则可以删除，否则不能删除(因为可能被使用中)

level 0 的压缩过程

  • 选择 key 800 - 2500

  • 因为 level 0有重叠，遍历所有文件，找到 key 重叠的文件，确定 start、end key

  • 选择 level 1 层，根据 start key、end key确定 level 1 层的文件

  • 将 level 0 和 level 1的文件做多路归并

图片

level > 0 的压缩过程

  • 选择 key 800 - 2500

  • 因为是完全有序的，可以根据二分搜索到确定的范围，确定出 level 层的文件

  • 再确定出 level + 1 层的文件

图片

MVCC 数据清理

  • 遍历所有文件

  • 小于 VersionSet 的 log_number_ 的文件

  • 或者不在 遍历列表中的文件，则可以删除

恢复

LevelDB打开需要做以下事情：

  • 如果数据库目录不存在，创建目录

  • 加文件锁，锁住整个数据库；

  • 读取MANIFEST文件，恢复系统关闭时的元数据，也就是版本信息，或者新建MAINFEST文件；

  • 如果上一次关闭时，MemTable里有数据，或者Immutable MemTable写入到SSTable未完成，那么需要做数据恢复，从WAL恢复数据；

  • 创建数据库相关的内存数据结构，如Version、VersionSet等

图片

DBImpl::Recover做了以下事情

  • 创建数据库目录；

  • 对这个数据库里面的LOCK文件加文件锁，单进程的

  • 如果数据库不存在，那么调用DBImpl::NewDB创建新的数据库；

  • 调用VersionSet::Recover来读取MANIFEST，恢复版本信息；

  • 根据版本信息，搜索数据库目录，找到关闭时没有写入到SSTable的日志，按日志写入顺序逐个恢复日志数据

  • DBImpl::RecoverLogFile会创建一个MemTable，开始读取日志信息，将日志的数据插入到MemTable

  • 并根据需要调用DBImpl::WriteLevel0Table将MemTable写入到SSTable中

异常恢复

  • 如果元数据丢了，但是数据还在，也可以恢复的

  • 把所有sstable 当做 level 0 层，然后不断做压缩

  • 由于sstable 数量会远大于0，这样会大致大量的compaction

  • 经过很多次compation最后会稳定下来，形成新的 元数据

  • 旧的文件则会删除

参考

  • 论文《Less hashing, same performance:Building a better Bloom filter》

  • github index

  • Bloom Filters by Example

  • 漫谈 LevelDB 数据结构（一）：跳表（Skip List）

  • 漫谈 LevelDB 数据结构（二）：布隆过滤器（Bloom Filter）

  • 漫谈 LevelDB 数据结构（三）：LRU 缓存（ LRUCache）

  • LevelDB源码剖析

  • SF-Zhou’s Blog

  • leveldb-handbook

  • 庖丁解LevelDB

  • rust使用

  • LevelDB使用介绍

  • LeveLDB维基百科

  • dbdb.io的LevelDB介绍

  • MariaDB的插件

  • 书籍：精通LevelDB

  • leveldb 实现解析

  • POSIX™ 1003.1 Frequently Asked Questions (FAQ Version 1.18)

  • Spurious wakeup

  • Memory barrier

  • Memory Barriers: a Hardware View for Software Hackers

  • Bean Li的LevelDB文章汇总

  • LevelDB设计与实现 - Compaction

  • LevelDB设计与实现 - MVCC等

  • leveldb源码剖析 系列

  • HBase file format with inline blocks (version 2)

相关文章

  • LevelDB 辅助工具类

  • LevelDB SSTable模块

  • LevelDB MemTable模块

  • LevelDB Log模块

  • LevelDB 公开的接口

数新智能
关注
博客
告别“数据沼泽”，拥抱“活水湖”：数新智能基于CyberEngine与Apache Paimon的新一代数据湖仓架构
04-24 266
数据不再只是静态存储，它正在变成流动的“水”。今天，我们正式向大家介绍基于CyberEngine大数据平台的新一代数据湖解决方案，它为企业构建灵活、实时、统一的“活水湖”数据底座。本期聚焦基于 CyberEngine 与 Apache Paimon 的新一代数据湖仓架构，解析其如何告别数据沼泽、实现实时入湖与跨存储自由，为企业构建“活水湖”提供实践参考。在CyberEngine的加持下，基于Paimon构建的数据湖成为了一汪真正的“活水湖”，既拥有数据湖的灵活性，又具备数据仓库的高性能与事务能力。
博客
DataX 深度解析：异构数据同步的核心设计与实现原理
03-30 403
本期我们将深度解构数新智能「开源技术」系列之——开源离线数据同步工具 DataX，其他相关文章可移步专栏合集查看。作为大数据体系建设的基础工具，DataX 以 Framework+Plugin 核心设计破解异构数据源同步的 N*N 链路难题，是企业数据治理的重要抓手。本文将从架构设计、执行流程、插件开发等维度拆解其技术内核，提炼实操要点，为技术从业者提供可落地的参考思路。
博客
赋能某跨境智慧物流：基于 AWS Graviton 的全栈数据平台实现 25% 成本节省
02-13 545
数新智能通过将 自研的云原生数据底座CyberEngine 与 业界领先的 AWS Graviton 自研芯片 进行全栈深度集成，不仅解决了客户在成本与性能上的燃眉之急，更为其构建了面向未来的数据核心竞争力。这为整个平台奠定了高性价比的基石。我们深信，真正的技术价值，在于将底层硬件的强大潜力，通过领先的软件平台转化为切实的业务成果。数新智能的解决方案核心，是将 AWS Graviton 处理器的原生优势 与 CyberEngine 数据底座的云原生能力进行深度耦合，实现从硬件到软件的全栈协同优化。
博客
数新智能 CyberData 现已全面支持 AWS Graviton 处理器
02-13 156
重要提示： 无论客户使用的是传统 x86 架构实例还是新一代 ARM 架构的 Graviton 实例，CyberData 都能提供完全相同的功能特性和用户体验，确保服务的一致性和可靠性。通过此次架构升级，我们能够利用 Graviton 处理器带来的卓越性价比和能效，这不仅提升了服务的整体性能，也使我们能够更可持续地运营，并长期致力于为客户提供更优质的服务。发布同步性： 所有新版本、新功能及漏洞修复均同步发布至 x86 和 ARM 架构，不存在任何发布时间差异。起始支持版本：CyberData 5.4.1。
博客
CyberData 数据平台版本升级：信创深化、安全升级与全链路智能管控革新
02-13 421
为响应国家信创战略部署，满足企业数字化转型中的数据安全与高效管理需求，数新智能 CyberData 数据平台完成核心能力迭代升级。本次升级聚焦国产化适配深化、数据安全防护强化、建模能力拓展、标准管控智能化及资产体系重构五大核心方向，同步优化多维度操作体验，为企业提供更安全、高效、灵活的数据全生命周期管理解决方案。01 强化国产化适配，拓宽生态支持边界CyberData 持续深化与国产数据库的融合适配，完成平台信创化升级，进一步拓宽生态支持范围：· 核心数据库信创化落地：将业务底层数据库全面替换为国产主流数据
博客
CyberEngine 在云上大数据计算降本方面的实践和能力
02-13 585
随着云计算与大数据技术的深度融合，越来越多企业选择将大数据计算负载迁移至云端，以享受弹性扩展、按需使用的核心优势。但随之而来的，是云上资源配置不当、闲置浪费导致的成本高企问题，成为制约企业数字化转型效益的关键瓶颈。作为深耕大数据与云计算领域的技术服务商，数新智能依托自研 CyberEngine 产品，构建了一套通过资源优化实现云上大数据计算降本增效的标准化能力，无需定制开发即可适配各类企业场景，本文将深度拆解其核心产品化策略与实践逻辑。
博客
数新智能 CyberEngine 大数据引擎管理平台焕新升级
02-13 673
在平台易用性上，对平台的日志管理、资源管理等模块进行了“重组”，更加贴合运维人员使用习惯，提供便捷清爽的使用体验，另外，CyberEngine平台从诞生之日起就为国内的信创用户提供了良好的支持能力，除了支持国产的ARM架构CPU机型外，对国产的操作系统和中间件也都进行了充分的适配，此次的发布信创能力又进一步得到了提升；基于AWS平台的弹性伸缩能力：支持绑定和管理EKS集群，对EKS集群的弹性伸缩能力支持，根据业务的资源使用需求快速的完成Node的弹性扩缩容，极大的优化企业用户对于资源的利用效率。
博客
倒计时3天，四大行业嘉宾携出海解决方案重磅来袭
01-21 884
背景亮点：曾就职于新加坡科技，康柏电脑，通用汽车，爱立信，诺基亚，Linaro 非营利组织 (Linux for ARM)，Ubuntu，Vantiq 等企业。：曾就职于新加坡科技，康柏电脑，通用汽车，爱立信，诺基亚，Linaro 非营利组织 (Linux for ARM)，Ubuntu，Vantiq 等企业。1 月 24 日，由数新智能、CCF、华为云联合主办「智联生态 智启全球 —— 数据为帆，AI 为舵，共创出海新路径」Data+AI 技术出海主题论坛，热度再升级！：高金 数新智能解决方案总监。
博客
倒计时 5 天！Data+AI 技术赋能零售出海主题峰会嘉宾重磅官宣
01-19 371
本次演讲将聚焦 OceanBase 如何助力中国企业应对全球化挑战，实现高效、安全的跨境数据管理，实现降本增效、提升运维效率、保障业务连续性，同时更好的满足 AI 智能业务需求，为企业在国际市场的开拓筑牢数据根基。1 月 24 日，由数新智能、CCF、华为云联合主办「智联生态 智启全球 —— 数据为帆，AI 为舵，共创出海新路径」Data+AI 技术出海主题峰会，将落地杭州东新瑞莱克斯酒店！陈燕，亿企赢海外税产品总监，从事海外税十余年，曾实施过多家上市公司海外税，范围覆盖亚洲、美洲、澳洲等。
博客
CyberScheduler —— 打破数据调度边界的核心引擎
12-29 760
作为数新智能 CyberData 产品的调度引擎， CyberScheduler 以“全场景适配、全链路可控、全架构兼容”为设计理念，从触发机制、依赖管理、统一编排、部署能力到高可用架构，构建了一套覆盖企业数据调度全生命周期的解决方案。当前，企业采用多云（阿里云、华为云、谷歌云、AWS云、私有云等）和多计算引擎（Spark、Flink、Doris、ClickHouse、MaxCompute等）架构已成常态，但不同云厂商、不同引擎的调度工具碎片化，导致数据管理效率低下、运维成本高企。
博客
Compaction in Apache Iceberg
12-09 805
iceberg的有一个好处是，通过快照可以做 time-travel，verion rolback， 快照中的 manifest files不会被删除。job、task执行失败，可能会导致写入了部分数据，这些数据没有任何关联任何快照，因此也不能用正常的方式删除他们，因为没有任何关联关系。但流写入时，会出现很多新的小文件，删除过期文件可以将这些文件数据删除，但是处理不了 manifest 文件。除了压缩小文件，还做了排序，这意味着最小/最大过滤的好处将会更大(扫描的文件越少，速度越快)
博客
CyberAI多模态数据平台焕新升级！七大核心功能解锁高效管理新体验
12-01 825
数新智能一站式多云AI原生数智平台升级，新增多模态数据管理功能。
博客
The Life of a Read/Write Query for Apache Iceberg Tables
11-10 1195
本文以读写查询生命周期为核心，解析 Iceberg 表的处理逻辑。当前快照中已经存在的 manifest file，跟新的一起，写入到 manifest list中，以及manifest file 的路径和统计信息。在这个 manifest list中，包含了所有 manifest file 的路径，以及每个文件的信息，如每个分区的 lower和upper等。merge-on-read，生成新的更新/删除/插入 数据文件，读取时会忽略旧的文件，只有更新的数据在内存中，占用内存会减少。
博客
Data engineering at Meta
11-07 877
揭秘 Meta 如何通过 UPM 流水线管理、分析库集成及自动化监控，构建支撑千亿级日活的高效数据链路，展现湖仓架构、流批融合及云原生设计的工程化落地经验，为企业数据智能建设提供可复用的技术蓝图。facebook 每天会产生 几百P 的数据，用户行为，代码变更，这个框架就用来实时分析这种变化，并提供开发人员展示。每个表都按照 ds 分区，也就是 YYYY-MM-DD 分区的，一般是数据产生的时间，也有其他方式分区的。内部维护了一个分支，做了一些定制化修改，也会定期合并开源分支，同时也会提交修改到开源。
博客
Data Ingestion: Architectural Patterns
10-26 1134
在数据驱动的时代，数据摄取是构建高效数据生态系统的基石。Data Integration Challenges，因为是一个数据库来管理 OLAP、OLTP，如果数据源种类很多，就不好处理，需要跨数据源查询，带来复杂度。Handling Push Failures，pull失败了只要重试即可，但是push失败了 分析平面感知不到，需要设计高可用，高并发的 push流系统。本质上来说，data ingestion 就是把运营平面的数据，同步到 分析平面中，这样就可以解锁 分析平面的所有能力了。
博客
“数”风流人物｜从手搓Hadoop到智能数据平台构建，数新智能CTO原攀峰的“自我突破”
10-20 136
本文是数新智能 CTO 原攀峰接受 IT168 专访的完整内容，字里行间藏着我们对 “智能数据平台” 的核心思考与落地答案。无论你是正在搭建数据平台的技术管理者，还是想探索 AI 时代数据价值的从业者，这篇深度访谈都值得一读。
博客
BTrace
09-23 468
从动态追踪工具如 Btrace、Arthas 的 retransform 能力，到 JDB 调试，再到 JDK 内置的 VisualVM、JFR，以及 JProfiler、MAT 等性能分析工具，还有分布式监控工具、火焰图等，它们共同助力开发者高效定位问题、优化系统性能。· arthas 使用了：Instrumentation.retransformClasses()，会替换整个类，风险高。· btrace 使用了：java.lang.instrument，只是在关键函数中注入了额外信息，风险低。
博客
云环境中的日志收集和处理方案
09-15 762
在云环境中，高效的日志收集与处理是系统监控和运维的关键。本文围绕《云环境中的日志收集和处理方案》展开，先介绍日志收集的两种方式，再聚焦处理环节，探讨写入 kafka、共享存储、S3 等路径，分析使用 raft 组日志集群及 NewSQL 的方案，最后结合 Spark 端调度进行总结，为云日志管理提供多维度技术参考。SPARK_EXECUTOR_ID ，driver端需要手动设置，executor 是自动设置上的。根据当前的节点 hash，定位到环的一个为止，然后顺时针处理，这样每段由不同节点处理。
博客
PyTorch
09-09 899
在深度学习领域，PyTorch 以动态图机制和简洁易用的特性，成为科研与工程落地的热门框架。本文围绕《PyTorch》展开，从基础操作切入，通过 numpy 与 tensor 实例演示数据处理核心逻辑，深入解析 Torchvision 数据加载、图像处理及常用功能。结合卷积原理、损失函数设计、梯度计算等关键模块，详解网络构建与优化方法，搭配可视化工具与分布式训练技巧，为读者呈现从基础语法到高阶应用的完整知识图谱，助力快速掌握 PyTorch 核心技术栈。
博客
OpenLDAP研究
09-04 578
在企业目录服务领域，OpenLDAP凭借开源、灵活的特性备受青睐。本文围绕《OpenLDAP研究》，从剖析其底层架构入手，详解实用命令与核心配置信息，展示web控制台便捷管理方式，还会梳理相关文档资源，助你全面掌握OpenLDAP的运行逻辑与使用技巧。这里存储的 kerberos 的 keytab 实际是。经过了 ASN.1 加密，包含了一些其他信息。树状的层级结构，比如组织的划分。按照 DNS 来划分层次。OpenLDAP系列文档。再做了 base64。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值