理解写入、读取和段发布的顺序有助于选择持久性配置和排查恢复问题。SonnetDB 的 measurement 存储采用 WAL、MemTable、不可变 Segment 与后台 Compaction 组成的 LSM 风格路径。本文讨论时序存储关系表、文档、对象和 MQ 保留各自合同不能把这条路径直接套到所有模型。SonnetDB 已正式发布 4.0.0。以下链接固定到已经公开的源码提交后续改动以实际版本为准性能数字和生产恢复保证需要对应版本的独立证据。写入先记录日志再进入内存measurement 写入由 SQL、Point/批量 API、ADO.NET 或 HTTP 入口进入。通过 schema 与类型检查后先追加 WAL再写入 MemTable后台或显式 Flush 将内存数据写为不可变 Segment。当前 MemTable 按SeriesId FieldName建桶桶中保存相应点与统计量并提供查询快照。它不是旧文所猜测的“通常为跳表或有序树”实际数据结构和并发合同可以直接从源码检查。写入 - schema/类型检查 - WAL - MemTable | Flush | immutable Segment“写入成功”的持久性分级TsdbOptions对 WAL 提供两个关键选项配置写入确认后的 WAL 所在位置关注点FlushWalToOsOnWritefalse且不启用每批同步可能仍在进程缓冲进程崩溃可能丢失最近的缓冲写入FlushWalToOsOnWritetrue默认不启用每批同步交给 OS page cache与介质持久化不同掉电风险仍须处理SyncWalOnEveryWritetrue按 group-commit 路径同步 WAL更强持久性写延迟和吞吐需在目标介质实测Flush、文件同步和目录发布共同参与恢复顺序。文件系统、操作系统和存储设备的行为也影响最终结果不能把进程 kill 测试外推成任意断电零丢失承诺。查询合并内存与持久段SQL 经过解析、名称绑定和计划后查询根据 measurement schema、series 与过滤条件选取候选数据读取 MemTable 快照和 Segment再应用 tombstone 与查询表达式。SegmentReader 可以利用 series/block 索引和时间范围跳过不相关数据。缓存与 reader 快照也有自己的更新和失效周期因此不能把查询概括成“每次顺序扫描全部文件”。结果顺序、聚合和分组以具体 SQL 形状为准需要稳定时间顺序时显式使用ORDER BY time。SELECTtime,usageFROMcpuWHEREhostserver-01ANDtime1713676800000ANDtime1713680400000ORDERBYtime;Compaction合并段与消化 tombstone当前默认策略为 Size-Tiered由文件大小和 tier 条件形成计划并不是旧稿所说的 Leveled 策略。Compaction 合并段、处理删除与保留策略随后发布替换结果。主线的段替换清单记录 pending/committed 状态以区分未提交的新段和已被替换的旧段。查询读取的 segment 快照与替换发布需要保持一致后台执行也会消耗 CPU、内存和 I/O不能预先声称对前台影响极小。架构之外的运维边界备份应使用受支持的目录备份与校验流程。数据库目录不是单个数据文件Server 的 SonnetMQ 物理日志位于实例级.system/mq单库备份不覆盖它。Graph 仍为 Beta容量和长期运行验证也不能由 WAL/Segment 路径的测试推导。参考架构文档、TsdbOptions、MemTable、CompactionPlanner和可靠性变更。
