边缘设备的数据库选型一直是个头疼事。Redis太吃内存,InfluxDB依赖太重,SQLite又不是为时序数据设计的。最近看到一个叫NanoTDB的项目,专门给树莓派、IoT网关这类资源受限场景做的嵌入式时序数据库,有点意思。

它的设计很克制:纯Go实现,运行时零外部依赖,所有数据就是一个根目录下的普通文件。没有守护进程,没有网络端口,直接嵌入你的程序里用。

打开网易新闻 查看精彩图片

核心结构三层:引擎(Engine)管路由,数据库(Database)管存储,每个库底下再分WAL、目录和分区数据文件。写数据走Line Protocol格式,比如prod/room.temp 21.5 1715000000000000000,引擎按斜杠前的前缀路由到对应数据库,WAL先落盘保证崩溃安全,再攒进内存页,满了就压缩写到.dat文件,然后重置WAL。

打开网易新闻 查看精彩图片

有个硬性约束:单条时间线必须单调递增写,乱序数据直接拒掉。这个设计省掉了合并排序的复杂度,换取写入速度。查询时按UTC天分片扫文件,页头有时间范围元数据,不匹配的帧直接跳过不解压。

最省空间的是它的WAL编码。已知指标、同基线的情况下,一条记录只需要11字节:2字节指标ID、3字节时间差、1字节标志、4字节数值。新指标或新时间基线时才需要额外字段。作为对比,CSV里一个浮点数就得七八字节。

类型系统也简单:第一次写入决定指标类型,整数固定int32,浮点固定float32,混写报错。可以用i后缀强制整数,比如256i

打开网易新闻 查看精彩图片

项目还留了个internal库给自己用,存引擎自身的批量大小、内存占用这类指标,结构和用户库完全一致,只是不暴露出来。这个设计挺干净, dogfooding做得彻底。

目前看下来,NanoTDB的定位很明确:不是要跟InfluxDB或TimescaleDB竞争,而是填补"比文件写日志强一点,比上数据库又轻很多"的空白地带。适合那种一台树莓派挂几个传感器、本地存几周数据、偶尔批量上传云端的场景。代码量可控,读一遍实现就能自己改。