第 1 章 · 简介与历史

第 1 章 · 简介与历史

1.1 LevelDB 是什么

LevelDB 是由 Google 开源的嵌入式键值存储引擎（Embedded Key-Value Store）。它不是一个独立运行的数据库服务，而是一个库——你可以将它链接到自己的应用程序中，直接在进程内完成数据的读写操作。

💡 提示：LevelDB 的设计灵感来自 Google 内部的 Bigtable 存储系统。如果你了解 Bigtable 的 SSTable 和 MemTable 概念，会发现 LevelDB 是这些思想的精简实现。

1.2 历史背景

诞生故事

2011 年，Google 的 Jeff Dean 和 Sanjay Ghemawat（MapReduce 论文的两位作者）将 LevelDB 开源。他们的目标是创建一个轻量级、高性能的嵌入式存储引擎，填补当时开源生态中 “进程内高性能 KV 存储” 的空白。

版本演进

分支与衍生项目

LevelDB 的成功催生了一系列衍生项目：

                    ┌──────────────┐
                    │   LevelDB    │ (Google, 2011)
                    └──────┬───────┘
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
    ┌──────────────┐ ┌──────────┐ ┌──────────────┐
    │   RocksDB    │ │ HyperDB  │ │ goleveldb    │
    │ (Facebook)   │ │ (学术)   │ │ (Go 实现)    │
    └──────────────┘ └──────────┘ └──────────────┘
            │
            ▼
    ┌──────────────┐
    │  PebblesDB   │
    │  (UT Austin) │
    └──────────────┘

1.3 LSM-Tree 核心思想

LevelDB 的底层数据结构是 LSM-Tree（Log-Structured Merge-Tree），由 Patrick O’Neil 等人在 1996 年的论文中提出。

传统 B-Tree 的瓶颈

传统数据库（如 MySQL InnoDB）使用 B-Tree 存储数据。B-Tree 的随机写（Random Write）在磁盘上会导致大量寻道开销：

B-Tree 随机写：
  写入 Key=42 → 寻道到 Page #387 → 修改 → 写回
  写入 Key=17 → 寻道到 Page #125 → 修改 → 写回
  写入 Key=99 → 寻道到 Page #512 → 修改 → 写回
  （每次写入可能触发随机 I/O）

LSM-Tree 的解法：顺序写

LSM-Tree 的核心思想是将随机写转换为顺序写：

1. 写入时：先写入内存中的 MemTable（类似跳表），同时追加 WAL（Write-Ahead Log）保证持久性
2. MemTable 满了：冻结为 Immutable MemTable，刷盘生成 SSTable 文件
3. 后台 Compaction：定期合并多个 SSTable，清理过期数据

LSM-Tree 写入流程：

  写请求 ──→ [MemTable (内存)] ──→ 满了 ──→ [SSTable L0 (磁盘)]
                │                                      │
                ▼                                      ▼
           [WAL 日志]                          [Compaction]
                                                    │
                                              ┌─────┴─────┐
                                              ▼           ▼
                                         SSTable L1   SSTable L1
                                              │
                                              ▼
                                         SSTable L2

读写性能对比

⚠️ 注意：LSM-Tree 的经典权衡是写放大（Write Amplification）和空间放大（Space Amplification）。Compaction 过程中，数据会被反复读写，这就是写放大的来源。

1.4 LevelDB 的特性概览

核心特性

不支持的特性

1.5 适用场景分析

✅ 推荐使用 LevelDB 的场景

场景一：区块链状态存储

以太坊（Go-Ethereum）和比特币都使用 LevelDB 存储区块链状态：

// 以太坊风格的区块头存储
db->Put(WriteOptions(), "block:1000:hash", block_hash);
db->Put(WriteOptions(), "block:1000:header", serialized_header);
db->Put(WriteOptions(), "state:account:0xABC...", account_state);

为什么适合：写多读少、数据有序、嵌入式无需额外服务。

场景二：时序数据缓存层

IoT 设备 → 采集数据 → LevelDB（本地缓存）→ 批量上传 → 云端时序数据库

为什么适合：高吞吐写入、本地持久化防丢失、顺序 Key 天然支持时间排序。

场景三：搜索引擎倒排索引

// Key: "term:leveldb" + doc_id → Value: tf-idf 分数
std::string key = "term:leveldb" + "\x00" + std::to_string(doc_id);
db->Put(WriteOptions(), key, SerializeScore(tf_idf));

为什么适合：有序遍历支持前缀查询，批量写入构建索引高效。

场景四：配置中心/服务发现

// 服务注册
db->Put(WriteOptions(), "service:auth:node1", "192.168.1.10:8080");
db->Put(WriteOptions(), "service:auth:node2", "192.168.1.11:8080");

// 查询所有 auth 服务节点
auto iter = db->NewIterator(ReadOptions());
for (iter->Seek("service:auth:");
     iter->Valid() && iter->key().starts_with("service:auth:");
     iter->Next()) {
    // 遍历所有 auth 节点
}

❌ 不推荐使用 LevelDB 的场景

1.6 谁在使用 LevelDB

1.7 与同类技术对比

1.8 本章小结

扩展阅读

1. LSM-Tree 原始论文：O’Neil, P., et al. “The Log-Structured Merge-Tree (LSM-Tree)” (1996)
2. Bigtable 论文：Chang, F., et al. “Bigtable: A Distributed Storage System for Structured Data” (2006)
3. LevelDB 作者演讲：Jeff Dean - “Achieving Rapid Response Times in Large Online Services”
4. RocksDB Wiki：Tuning Guide
5. Designing Data-Intensive Applications：Martin Kleppmann, Chapter 3 “Storage and Retrieval”

下一章：第 2 章 · 编译安装与语言绑定 →