嵌入式Buildroot测量仪器数据采集：SQLite替代CSV选型及分库咨询

问题1：该场景下选择SQLite替代CSV是否为合理技术选型 #

结论是属于匹配度极高的合理选型，实际开发验证的依据如下：

• 先做严格的量级测算：运维参数按最高10秒采样间隔、单条10个字段估算，单条记录按200字节算，一整年的累计数据量也就约630MB；加上5分钟采样的低频次物理量，一年总数据量不到650MB。就算设备连续跑5年，总数据量也就3.2GB左右，完全落在SQLite的稳定性能支持范围内，不存在性能瓶颈。
• 对比原有CSV方案，SQLite的优势完全命中核心诉求：
  • 嵌入式设备硬复位、意外掉电的概率远高于桌面环境，CSV没有原子写入机制，一旦在写文件中途断电，很容易出现行错位、文件截断，修复成本极高；开启WAL模式的SQLite依靠原子提交机制，掉电后重启最多回滚最后一个未完成的事务，不会损坏整个库文件，能把设备崩溃导致的数据损坏风险降到最低。
  • 长期迭代灵活性更强：后续要给数据加字段、补元数据，只要执行一次ALTER TABLE语句加列即可，不需要像CSV那样要兼容不同时期的文件列顺序、分隔符差异；后续数据加工软件读数据时直接用标准SQL查询即可，不需要维护一整套CSV解析的兼容逻辑。
  • 部署成本极低：Buildroot本身已经集成了SQLite支持，Qt5.12自带SQLite驱动，整个适配过程只需要写少量数据库初始化、查询的代码，不需要引入额外的第三方依赖。
• 仅需注意一个嵌入式场景的适配细节：因为设备运行在闪存存储上，不要做单条数据单独提交事务，把10秒粒度的运维数据攒10条或者1秒的量一次性提交，减少闪存的擦写次数、降低存储磨损，最终性能表现不会比写CSV差。

问题2：按月分块拆分数据库的实现难度与自动化方式 #

结论是该操作实现难度极低，搭配cron实现自动化是工业界嵌入式采集设备的常规操作，没有技术门槛

• 最省事的实现思路（比定期拆分单库简单一个量级）：
  从设计初期就不要把所有年份的数据存在同一个SQLite文件里，直接按「年-月」粒度独立创建数据库文件，比如measure_2024_05.db、measure_2024_06.db。每次写入数据前先判断当前时间对应的目标库文件是否存在，不存在就执行固定的建表语句创建新文件，再把数据写入对应月份的库文件。
  这种方案天生就实现了按月分块、文件大小可控的目标，完全不需要做后续的数据拆分、导入导出操作，每个月的库文件可以直接备份、归档，没有任何锁冲突风险。
• 如果坚持先存单库再定期拆分，实现逻辑也不复杂：
  每月触发拆分时，先创建对应月份的归档库文件，通过ATTACH DATABASE语句关联主库和归档库，把上月时间范围的记录从主库迁入归档库，再删除主库中已经迁出的记录，最后运行VACUUM回收主库的磁盘空间。整个流程的SQL逻辑不到20行代码，只需要注意拆分时把事务粒度控制好，不要和正在运行的采集写入操作抢文件锁即可。
• 关于cron自动化的可行性：
  Buildroot自带的busybox cron完全可以胜任自动化任务，只需要写一个几十行的shell脚本，在每月1号0点触发：检查上月对应的库文件完整性、把归档文件移动到独立的备份目录、清理临时文件即可。因为每个月份的库文件是独立打开、写完就关连接的，根本不会出现长时间的文件锁占用，cron任务触发时完全不会干扰正常的采集流程。

内容的提问来源于stack exchange，提问作者dpeng