Sonnerie时序数据库文件格式深度解析

项目概述

Sonnerie是一个高效的时序数据库系统，其核心在于精心设计的文件存储格式。本文将深入剖析Sonnerie的文件格式设计，帮助开发者理解其底层数据组织方式和高效查询原理。

文件结构基础

Sonnerie采用分段(Segment)存储结构，每个段包含索引数据和压缩后的实际值(称为Payload)。这种设计在保证查询效率的同时，实现了良好的存储压缩率。

关键特性

• 所有数字采用大端序(Big-Endian)存储
• 变长整数使用unsigned-varint编码
• 所有键(Key)必须是有效的UTF-8编码字符串

段头结构详解

每个数据段以特定标识符开头，后跟版本信息和关键元数据：

1. 起始标识：@TSDB_SEGMENT_
2. 版本号：2字节，当前版本为0x0100
3. 五个变长整数：
   • 本段第一个键的长度(字节)
   • 本段最后一个键的长度(字节)
   • Payload的存储长度
   • 前一个段的压缩长度(含所有头信息)
   • 包含first_key数据的所有前序段的总字节数(若无则为0)
4. 键信息：
   • 第一个键(长度由第一个变长整数指定)
   • 最后一个键(长度由第二个变长整数指定)
5. 压缩数据：LZ4压缩的Payload数据

特殊处理：如果压缩数据中出现@TSDB_SEGMENT_标识，会被替换为@TSDB_SEGMENT_\xff\xff以避免解析冲突。

Payload数据结构

Payload是存储实际时序数据的核心部分，其结构设计考虑了高效存储和快速访问：

1. 头部信息（4个32位数字）：
   • 键长度
   • 格式字符串长度
   • 该键对应实际数据的字节长度
2. 键内容：UTF-8字符串
3. 格式字符串：定义数据列的类型和结构
4. 实际数据：按时间戳组织的值序列

对于变长数据(如字符串)，每条记录前会存储一个varint表示记录长度(不含时间戳)，然后是8字节的时间戳和各列的值。

删除标记机制

Sonnerie采用特殊的删除标记来处理数据删除操作：

• 格式字符为\x7f时表示删除事务
• 删除事务必须只包含一个段，且该段只包含一条记录
• 删除范围由以下要素定义：
  • 起始键和结束键
  • 起始时间戳和结束时间戳(各8字节)
  • 键通配符(用于模式匹配删除)

删除操作是逻辑删除，实际数据在后续的压缩(compaction)过程中才会被物理移除。

文件组织与查询

段文件结构

一个段文件包含多个有序排列的段，每个段都有完整的头信息。文件中的段按键的字典序排列，且后一个段的第一个键必须大于等于前一个段的最后一个键。

高效查询原理

Sonnerie采用二分查找算法在段文件中定位键：

1. 基于文件大小进行二分查找
2. 通过扫描找到@TSDB_SEGMENT_标识定位段边界
3. 利用段头中的"payload压缩长度"信息可以快速回退到前一个段
4. 找到包含目标键的段后，解压LZ4数据获取实际值

这种设计充分利用了操作系统的磁盘缓存机制，使得频繁查询的键的定位过程几乎不需要磁盘I/O。

数据库整体架构

Sonnerie数据库是一个目录结构，包含：

• 一个"main"主文件
• 多个以"tx."开头(不以".tmp"结尾)的事务文件

查询时需要对所有文件进行排序合并操作，其中文件名字典序最后的文件中的数据具有更高优先级，这种设计实现了高效的更新机制。

压缩(Compacting)机制

压缩过程实质上是多文件的排序合并：

1. 对一组文件执行排序合并
2. 创建新的合并后文件
3. 安全删除原文件组

虽然新旧文件短暂共存不会影响逻辑正确性，但为了最佳性能，应尽量减少这种重叠时间。

格式字符串设计

格式字符串定义了各列的数据类型，支持以下类型标识符：

• 'f'/'F'：32/64位浮点数
• 'u'/'U'：32/64位无符号整数
• 'i'/'I'：32/64位有符号整数
• 's'：变长字符串(存储时包含长度信息)
• \x7f：特殊删除标记(如前所述)

这种紧凑的类型表示方式既节省了存储空间，又便于快速解析。

设计哲学与优势

Sonnerie文件格式的设计体现了几个关键思想：

1. 局部性原理：通过段结构和二分查找优化磁盘访问模式
2. 写时优化：压缩过程实现存储空间的持续优化
3. 分层优先级：通过文件名排序实现高效的更新机制
4. 空间效率：结合LZ4压缩和紧凑的二进制格式减少存储开销

理解这些设计原理不仅有助于更好地使用Sonnerie，也能为开发类似系统提供有价值的参考。