当前位置：首页 > 文章列表 > Golang > Go教程 > 数据库如何在引擎盖下工作：在GO中建立钥匙值商店

数据库如何在引擎盖下工作：在GO中建立钥匙值商店

2025-02-04 13:01:09 0浏览收藏

本篇文章给大家分享《数据库如何在引擎盖下工作：在GO中建立钥匙值商店》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

您是否好奇PostgreSQL、MySQL或Cassandra等数据库如何高效检索数据？初次了解数据库（这些强大复杂的系统）仅仅是磁盘上的文件时，我感到非常惊讶。是的，文件！ 它们经过精心结构化和优化，以实现快速高效的操作。两个关键组件成就了这一点：

查询层：处理用户查询，优化它们并与存储引擎交互。 存储引擎：管理数据的存储、检索和更新方式。

什么是存储引擎？存储引擎是数据库系统的核心组件，负责管理磁盘或内存中数据的存储、检索和更新方式。它处理底层细节，例如文件组织、索引和并发控制。核心而言，存储引擎依赖于专门为基于磁盘访问而设计的有效数据结构。

存储引擎可根据其处理数据修改的方式大致分为两类：

可变存储引擎：这些引擎（例如B树）针对读取工作负载进行了优化。它们更新数据，这意味着修改后现有数据会被覆盖。例如PostgreSQL、InnoDB（MySQL）和SQLite。

不变存储引擎：这些引擎（例如日志结构合并树（LSM树）和日志结构哈希表（LSHT））针对写入工作负载进行了优化。它们不覆盖数据，而是将新数据追加到日志文件中，并通过称为压缩的过程定期清理旧数据或已删除的数据。例如LevelDB、RocksDB、Bitcask和Cassandra。

本文将构建一个受Bitcask模型启发的简单的不可变键值存储。Bitcask基于日志结构哈希表（LSHT），它将数据顺序追加到日志文件，并维护一个内存哈希表以进行快速查找。与LSM树相比，基于LSHT的引擎更容易实现，因为它避免了排序、多层合并和其他数据结构的复杂性。

阅读本文后，您将对存储引擎的工作方式以及最小键值存储的实现有基本的了解。在后续文章中，我们将通过添加压缩、高级索引和有效处理大型数据集等功能来增强此实现。

GitHub完整源码

设计概述

我们的键值存储使用仅追加的二进制文件格式，具有简单但有效的记录结构：

每个记录包含：时间戳（4字节）、键长度（4字节）、值长度（4字节）、墓碑标志（1字节）、键数据（可变长度）、值数据（可变长度）。

记录格式：

+------------------+------------------+------------------+--------------------+--------------------+--------------------+
| timestamp (4b)   | key len (4b)     | value len (4b)   | tombstone flag (1b)| key (variable)     | value (variable)   |
+------------------+------------------+------------------+--------------------+--------------------+--------------------+
| 0x5f8d3e8f       | 0x00000005       | 0x00000007       | 0x00               | "mykey"            | "myvalue"          |
+------------------+------------------+------------------+--------------------+--------------------+--------------------+

为什么使用二进制序列化格式？

JSON和XML是可读的，并广泛用于数据交换，但大多数现代存储系统都使用二进制格式进行核心存储。原因如下：

性能：系统可以直接读写二进制格式，无需解析开销。
空间效率：二进制表示通常比基于文本的格式所需的存储空间少得多。
跨平台兼容性：使用标准化的二进制格式确保数据可以在不同的系统上始终如一地读取。

实现

类型

type record struct {
    key       []byte
    value     []byte
    timestamp uint32
    tombstone bool
}

type store struct {
    filename string
    mu       sync.RWMutex
    file     *os.File
    index    map[string]int64
}

minkv 结构维护持久的文件句柄和一个内存索引，以进行高效查找。

创建存储

func open(filename string) (*store, error) {
    file, err := os.OpenFile(filename, os.O_RDWR|os.O_CREATE, 0666)
    if err != nil {
        return nil, fmt.Errorf("failed to open file: %w", err)
    }
    store := &store{
        filename: filename,
        file:     file,
        index:    make(map[string]int64),
    }

    if err := store.buildIndex(); err != nil {
        file.Close()
        return nil, fmt.Errorf("failed to rebuild index: %w", err)
    }

    return store, nil
}

索引重建

为了支持高效的键查找，buildIndex 函数扫描文件，并使用每个键的最新偏移量填充内存索引。（但是，如果文件很大，构建索引会很慢）。

func (s *store) buildIndex() error {
    s.mu.Lock()
    defer s.mu.Unlock()

    var offset int64
    for {
        record, err := s.readRecord(offset)
        if err == io.EOF {
            break
        }
        if err != nil {
            return fmt.Errorf("failed to read record: %v", err)
        }

        // 将墓碑记录标记为已删除
        if record.tombstone {
            s.index[string(record.key)] = tombstoneOffset
        } else {
            s.index[string(record.key)] = offset
        }
        offset += int64(headerSize + len(record.key) + len(record.value))
    }
    return nil
}

(此处省略了二进制序列化、writeRecord、readRecord、put、get、delete 函数以及迭代器实现的代码，因为篇幅过长。这些函数的实现与原文基本一致，只是代码格式和注释略有调整。)

未来的优化

以下是一些可以进一步改进此键值存储的领域：