北京
边缘设备的数据库选型一直是个头疼事。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竞争，而是填补"比文件写日志强一点，比上数据库又轻很多"的空白地带。适合那种一台树莓派挂几个传感器、本地存几周数据、偶尔批量上传云端的场景。代码量可控，读一遍实现就能自己改。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
