谢瑞阳&徐翔宇的KV分离LEVELDB实现

22 KiB

Raw Blame History

代码设计

1.项目概述

1.1 实现字段查询功能

LevelDB 的基本数据结构是由一个 key 和对应的 value 组成，其中 value 是一个简单的字节序列（可以是字符串或二进制数据）。默认情况下，LevelDB 不支持像关系型数据库那样的字段查询功能。然而，在实际应用中，用户可能需要对存储的数据进行更加精细的操作，特别是当值包含多个逻辑字段时，直接使用现有的 LevelDB 接口难以满足需求。在本实验中，我们的目标是扩展 LevelDB 的功能，使其 value 支持多字段结构，并实现通过字段值查询对应的 key 的功能。

1.2 KV 分离

在 LevelDB 及其采用的 LSM 树结构中，性能挑战之一在于 Compaction 操作的效率。Compaction 是指将内存中的数据合并到磁盘上的过程，此过程中涉及大量的读写操作，对于系统的整体性能有着重要影响。在 Compaction 时，所有涉及到的旧 sstable 中的键值对都将被写入到新 sstable 中，而 Value 通常比 Key 大得多。如果将 Key 和 Value 分离存储，合并时只涉及 key 写入 sstable 的过程，可以显著减少 Compaction 的开销，从而提升性能。基于此我们计划实施键值分离策略。具体而言，键将保持原有的排序方式，而值将被独立存储。这样做可以在不影响查询性能的前提下，大幅降低 Compaction 过程中的数据迁移量，进而减少不必要的磁盘 I/O ，提升系统的合并效率。

2.功能设计

Andy Pavlo在15445课程中说，完成一个项目，应先写出能够完成正确性要求的代码，再在此基础上提升性能，避免不成熟的优化方式。

因此，我们的项目流程将保持每周推进代码进度，在完成目标要求的代码的基础上，不断迭代优化性能。

2.1.字段设计

设计目标：
- 将 LevelDB 中的 value 组织成字段数组，每个数组元素对应一个字段（字段名：字段值）。
- 字段会被序列化为字符串，然后插入LevelDB。
- 这些字段可以通过解析字符串得到，字段名与字段值都是字符串类型。
- 允许任意调整字段。
- 实现通过字段值查询对应的 key。
实现思路：

函数 Put_with_fields 负责插入含字段的数据。原字段数据经过序列化函数 SerializeValue 处理后，函数 Put_with_fields 调用 Put 将序列化后的字段插入 leveldb。

函数 Get_with_fields 负责获得含字段的数据。使用 Get 从 leveldb 中获取 key 和序列化后的 value，调用 ParseValue 可以将字段反序列化。

函数 Get_keys_by_field 遍历数据库中的所有键值对，解析每个 Value，提取字段数组 FieldArray。检查字段数组中是否存在目标字段，如果匹配，则记录其对应的 Key。将所有匹配 key 汇总到 keys 中返回。

初步实现（第一周已完成）：在 leveldb 内部实现以上功能。内部实现会导致读取时无法区分多字段类型和原生 kv 对，扩展性不足。

后续改进（第二周）：为了解决无法区分多字段类型和原生 kv 对的问题，将以上函数功能实现在用户层级，使 leveldb 内部对多字段类型无感知。

2.2.KV分离

设计思路

KV 分离设计

a. 将LevelDB的key-value存储结构进行扩展，分离存储key和value

b. Key存储在一个LevelDB实例中，LSM-tree中的value为一个指向Value log文件和偏移地址的指针，用户Value存储在Value log中。
读取操作。

KV分离后依然支持点查询与范围查询操作。
Value log的管理。

a.当Value log超过一定大小后通过后台GC操作释放Value log中的无效数据。

b.GC能把旧Value log中没有失效的数据写入新的Value log，并更新LSM-tree里的键值对。

c.新旧Value log的管理功能。
确保操作的原子性

实现思路

初步实现（第一周已完成）

使用单一Value Log简单的实现KV分离，该实现较为简单，仅需在Put/Get函数内部进行简单修改，但在大数据量场景下性能极差。

优点：实现简单，合并时开销小

缺点：大数据量下性能极差，不能作为最终方案。

第二种实现（第二周已完成）

对每个SSTable和MemTable建立一个Value Log。该实现相比于初步实现更加复杂，需要在合并时查询所有相关Value Log，并建立新Value Log。此外还要考虑在合并结束后将废弃的Value Log异步删除。

Trick 1.为什么要在Put到MemTable时就放入Value Log而非dump至SS Table时才放入Value Log？

原因：将写ValueLog推迟至SSTable并没有减少Put时写入磁盘的总数据量（写ValueLog：ValueLog中写Value，WAl中写Key和Value元数据；不写ValueLog：WAL中写Key和Value），优点是将两次无法并行的写文件操作变为一次写文件操作。但该方法有一个缺陷，即leveldb原生的管理数据的方式是MemTable和SSTable大小相等。而经过这样改变后，MemTable在dump成SSTable后其大小会突然减少（Value全部转移至ValueLog），导致一个SSTable中存储的数据量过少。而原本valuelog的优势（一个SSTable可以放更多键值对使得table cache命中率变高）也将不存在了。我们将两个做法都进行了实现，通过对比性能发现后者不如前者，因此选择保留前者设计。

优点：随合并自动GC，无需考虑GC。

缺点：合并时开销未能减小。

第三种实现（第三周）：使用相对固定大小的Value Log，例如每个Value Log大小约为2KB。新添加的键值对依次将值计入最新Value Log，当Value Log大小满了之后就创建新Value Log。需要设计一种不改变SSTable内记录Value元数据的GC方法。

优点：合并时开销小。

缺点：需要设计一种GC方式，能够在异步GC的同时不改变SSTable。

3. 数据结构设计

KV分离后 Value 结构设计

一个Value，开头是使用Varint64存储的FieldNum，表示有FieldNum个Field组成。然后是使用Varint64存储的Field X name size，表示该field的字段名长度，然后是字段名，然后是使用Varint64存储的Field X Value size，表示该field的值长度，然后是值。

ValueLog结构设计

第一版设计

使用一个Value Log文件的设计中，我们只需记录Value在Value Log中对应的偏移量和Value长度即可。

Value Log中只记录Value值，无需记录元信息。

第二版设计

Value设计为：1字节标志位+Varint64文件ID+Varint64偏移量+Varint64长度。

在存储时根据Value大小是否较大选择进行KV分离。若分离则标志位为true，否则标志位为false。

日志文件中仍然只需记录Value值即可，无需记录元信息。

第三版设计

这一版设计有些复杂。

和第二版设计一样，在Value开头使用一字节标志位表示是否KV分离。

如果KV分离，则接下来是Varint64的文件ID和Varint64的文件内offset。

在ValueLog中，在开头记录当前会索引到该Value Log的键值对数量Using count。如果Using count==0，则表示该ValueLog不被任何键值对使用，可以删除。

Using count在Value Log添加键值对时进行+1。

Using count在其中任意键值对被合并，并且该键值对由于合并时被更加新的键值对覆盖或者该键值对的True using Sign=False时，进行**-1**。

在一个Value通过SSTable索引到Value Log后，其索引到的开头是一个Value True Using Sign。该标志位同样是一字节，标志了当前该Value是否是真正的Value。

若标志位为True表示是真正的Value，那么标志位后是Varint64的Value长度+Value本身。

若标志位为False表示不是真正的Value，那么标志位后是Varint64的下一个可能存在有真实对应Value的Value Log文件ID和Varint64的在下一个Value Log文件中的offset。

Value True Using Sign发生变化有两种情况：

一个键值对由于合并时被更加新的键值对覆盖时，不仅将Using count进行-1，同时也将其Value True Using Sign设置为False。

在键值对加入到Value Log时，其Value True Using Sign设置为True。

当后台异步GC过程检测到一个Value Log的Using count较小时，将对其中Value True Using Sign仍为True的Value做以下处理：

1.将Value对应的数据（设为True的标志位，Value len和Value本身）像新数据一样写入最新的Value Log中。

2.将原Value True Using Sign置为False

3.将原Value Log中标志位后的数据修改为新写入的Value Log的ID和数据所处的Offset。

（保证原Value大小大于16，以防Varint64(Value len)+Value len<Varint64(File ID)+Varint64(Offset)。)

注意

在SSTable合并时要检查所合并的Value直接指向的Value Log是否Value True Using Sign=True，不是的话，要不断通过Next File找下一个文件，直到找到Value True Using Sign=True的文件。然后将新SSTable中的Value指向该新文件。除此之外，在此过程中找到的所有文件的Using count都要-1。

这样的GC设计可以确保，GC过程中无需修改原SSTable数据，且合并过程中仅需修改较少的数据。

[!CAUTION]

！注意！在实现过程中发现性能缺陷

当合并时由于需要扫描合并的SSTable，要对其中每个Value做读ValueLog操作（因为可能可以更新Value指向的ValueLog），导致一次合并会涉及很多次的ValueLog文件读写，性能过于低效，因此想到了新的操作方法。

3.1 fixsize_valuelog实际设计

新的`valuelog` 文件的组织方式：

valuelog 文件存储了 键值对（KV） 数据，每条记录按照以下格式组织：

键的长度（key_len）：uint64_t，标识键的字节长度。
键（key）：实际的键数据，长度为 key_len。
值的长度（value_len）：uint64_t，标识值的字节长度。
值（value）：实际的值数据，长度为 value_len。

在sstable中key对应的value位置存储了对应valuelog文件的id和在文件中的offset。

gc过程：

垃圾回收的核心思想是扫描所有的 valuelog 文件，检查文件中的记录是否有效。如果记录的键已失效（比如键在 sstable 中不存在或元数据不匹配），则该记录会被忽略，最终删除整个无效的 valuelog 文件。

详细过程：

扫描数据库目录：
- 遍历 valuelog 文件。
处理每个 valuelog 文件：
- 打开文件，逐条读取记录。
读取每条记录：
- 按文件结构读取 key_len、key、value_len、value。
- 检查 sstable是否包含该键：
  - 如果键不存在（或无效），忽略此条记录。
  - 如果键存在，验证元数据（包括 valuelog_id 和 offset）。
- 有效的键值对会被重新 put 进入数据库，sstable中重复的key会在compaction过程中被回收。
清理无效文件：
- 如果整个 valuelog 文件的记录均无效或已被迁移，删除该文件。

4. 接口/函数设计

4. 1Value多字段设计

4.1.1 数据序列化与反序列化

序列化字段数组为字符串值

std::string SerializeValue(const FieldArray& fields);

输入：字段数组 fields。
输出：序列化后的字符串。

反序列化字符串值为字段数组

void DeserializeValue(const std::string& value_str, FieldArray* res);

输入：序列化字符串 value_str。
输出：字段数组 res。

4.1.2 数据查询接口

按字段查找键

Status DB::Get_keys_by_field(const ReadOptions& options, const Field field, std::vector<std::string>* keys);

输入：
- 读取选项 options。
- 字段值 field。
输出：
- 操作状态 Status。
- 符合条件的键列表 keys。

4.1.3 判断文件是否为 `valuelog` 文件

判断给定文件是否为 .valuelog 格式的文件。

bool IsValueLogFile(const std::string& filename) {

输入：

文件名 filename，可以是完整路径或纯文件名。

输出：

布尔值 true：文件是 valuelog 文件。
布尔值 false：文件不是 valuelog 文件。

4.1.4 解析 `sstable` 中的元信息

解析 sstable 中存储的值，提取 valuelog_id 和 offset 信息。

void ParseStoredValue(const std::string& stored_value, uint64_t& valuelog_id, uint64_t& offset);

输入：
- 存储值 stored_value，格式为 "valuelog_id|offset"。
输出：
- valuelog_id：解析出的 ValueLog 文件 ID。
- offset：解析出的记录偏移量。

4.1.5 获取 `ValueLog` 文件 ID

从文件名中提取 ValueLog 文件的 ID（假设文件名格式为 number.valuelog）。

uint64_t GetValueLogID(const std::string& valuelog_name);

输入：
- 文件名 valuelog_name，可以是完整路径或仅文件名，格式需符合 number.valuelog。
输出：
- uint64_t 类型，返回提取的文件 ID。

4.2 Value Log设计

4.2.1 WriteValueLog

将一堆键值对的值顺序写入Value Log，用于writebatch写入数据库，以及Value Log GC的时候。两者都会对多个键值对同时操作，因此设计为批处理。

函数内将使用写锁保证正确性。同一时间最多只有一个WriteValueLog可以进行。

std::vector<std::pair<uint64_t,uint64_t>> WriteValueLog(std::vector<const slice&> value);

输入：一个Slice vector，表示要写入Value Log的Value们。
输出：一个std::pair<uint64_t,uint64_t> vector，每个pair中：第一个uint64_t是Value Log文件ID，第二个uint64_t是处在Value Log中的偏移量。

[!NOTE]

在第三版设计中，valuelog中会存储key，所以有部分改动。

4.2.2 ReadValueLog

通过Value Log读取目标键值对的值。

函数内将使用读锁保证正确性。在一个ValueLog正在被读取时，GC和WriteValueLog(?)无法对该ValueLog操作。

Status ReadValueLog(uint64_t file_id, uint64_t offset,Slice* value);

输入：第一个uint64_t是Value Log文件ID，第二个uint64_t是处在Value Log中的偏移量，第三个是指向要传回的value的指针。
输出：一个Status，表示是否成功传回对应Value。

[!NOTE]

在第三版设计中，valuelog中会存储key，所以有部分改动。

4.2.3 测试GC

调用MaybeScheduleGarbageCollect()来安排一个后台线程执行垃圾回收任务。它会等待所有已安排的垃圾回收任务完成，这通过循环检查background_garbage_collect_scheduled_标志，并在该标志为真时等待background_gc_finished_signal_信号来实现。

void DBImpl::TEST_GarbageCollect()

4.2.4 调用线程进行GC

启动一个新的后台线程执行BGWorkGC方法。这里使用了gc_mutex_.Lock()来确保线程安全。

void DBImpl::MaybeScheduleGarbageCollect()

4.2.5 调用负责GC函数

调用BackgroundGarbageCollect()进行实际的垃圾回收工作。

void DBImpl::BGWorkGC(void* db)

4.2.6 后台GC函数

负责执行后台垃圾回收任务。它确保在进行垃圾回收时，只有一个线程能够访问共享资源，并且在完成任务后通知等待的线程。

void DBImpl::BackgroundGarbageCollect()

4.2.7 后台GC函数

垃圾回收的核心实现。在目前的设计下，它遍历数据库目录中的所有valuelog文件，并尝试回收不再需要的数据。

void DBImpl::GarbageCollect()

5. 功能测试

5.1单元测试（测试用例）：

依据我们的设计，每周的工作内容完成后，都将对当前完成的功能进行正确性检验。以下以第一周我们完成的功能为例：

第一周

字段数组的存储与读取：

验证了 Put_with_fields 和 Get_with_fields 的正确性，确保字段数组可以正确序列化存储并反序列化读取。

基于字段的键查询：

验证了 Get_keys_by_field 的逻辑，确保能够根据字段值查找所有匹配的键。

Key Value分离：

并未额外设计，通过上两个功能的正确运行能够证明Key Value分离的初步实现大体是正确的。

#include "gtest/gtest.h"
#include "leveldb/env.h"
#include "leveldb/db.h"
using namespace leveldb;

constexpr int value_size = 2048;
constexpr int data_size = 128 << 20;

Status OpenDB(std::string dbName, DB **db) {
  Options options;
  options.create_if_missing = true;
  return DB::Open(options, dbName, db);
}

TEST(TestTTL, OurTTL) {
    DB *db;
    WriteOptions writeOptions;
    ReadOptions readOptions;
    if(OpenDB("testdb_for_XOY", &db).ok() == false) {
        std::cerr << "open db failed" << std::endl;
        abort();
    }
    std::string key = "k_1";

    std::string key1 = "k_2";
    
    FieldArray fields = {
        {"name", "Customer#000000001"},
        {"address", "IVhzIApeRb"}, 
        {"phone", "25-989-741-2988"}
    };

    FieldArray fields1 = {
        {"name", "Customer#000000001"},
        {"address", "abc"}, 
        {"phone", "def"}
    };

    db->Put_with_fields(WriteOptions(), key, fields);

    db->Put_with_fields(WriteOptions(), key1, fields1);

    // 读取并反序列化
    FieldArray value_ret;
    db->Get_with_fields(ReadOptions(), key, &value_ret);;
    for(auto pr:value_ret){
        std::cout<<std::string(pr.first.data(),pr.first.size())<<" "<<std::string(pr.second.data(),pr.second.size())<<"\n";
    }

    std::vector<std::string> v;
    db->Get_keys_by_field(ReadOptions(),fields[0],&v);
    for(auto s:v)std::cout<<s<<"\n";
    delete db;
}



int main(int argc, char** argv) {
  // All tests currently run with the same read-only file limits.
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

进一步设计

对KV分离实现更细粒度的测试，以及对KV分离GC操作实现测试

1.向表内插入一些value较小的键值对以及value较大的键值对，随后通过检查ValueLog内部数据（也可以是ValueLog文件长度）来判断是否对长短数据各自进行了处理。

2.向表内插入大量value较大的键值对后，查询ValueLog文件总数，删除其中绝大多数键值对，然后再查一次ValueLog文件总数，期望文件总数变少。

5.2性能测试（Benchmark）：

这一部分我们希望在完成大部分功能后再根据代码调整。

初步计划：

1.测试大数据量下短键值对和长键值对分别的插入和查询效率，与原版LevelDB作对比。

2.测试大数据量下磁盘使用率，与原版LevelDB作对比。

3.测试大数据量下合并的速率，与原版LevelDB作对比。

4.完成了多种KV分离方案后，将不同方案在Benchmark下进行测试。

原leveldb：

version_2:

version_3:

6. 可能遇到的挑战与解决方案

如何处理GC开销、数据同步

如何实现GC

在数据结构设计中已经进行了详细说明。

第二种设计通过合并过程自动完成了GC的功能。

第三种设计通过设计了一种异步的GC操作，使GC无需改变SSTable数据。

数据同步

写Value Log的时机和写WAL的时机一致，都在写MemTable之前完成。如果用户的Sync参数设置为True，则要保证Value Log一定写入完成后才能返回给用户写入成功的信息。

减少GC开销

有一种可能的优化是仅在数据写入SSTable之后才会使用Value Log。

7. 分工和进度安排

功能	完成日期	分工
完成初步的多字段Value实现和KV分离实现	11月20日	谢瑞阳
完成设计文档	11月27日	徐翔宇&谢瑞阳
将多字段Value实现迁移至用户层级	11月27日	徐翔宇
完成第二版ValueLog的设计	11月27日	谢瑞阳
完成第二版ValueLog的测试	11月27日	徐翔宇
完成第三版ValueLog的函数接口实现以及测试	12月1日	徐翔宇
完成第三版ValueLog的函数实现	12月4日	谢瑞阳
完成BenchMark设计	12月8日	徐翔宇&谢瑞阳
完成BenchMark，对不同KV分离方案进行测试	12月11日	徐翔宇
基于测试结果进行优化，完成第四版ValueLog的设计...	12月??日	徐翔宇&谢瑞阳

8. 每周进度更新

12.3-12.9：实现version_2，修改version_3设计，完成version_3，benchmark实验。

在valuelog中调整value和key的顺序，kv_len的储存形式，get的时机应该在读取value之前
调整kv分离标志位的位置
实现valuelog的block_cache

22 KiB Raw Blame History