FlashDB 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用

看下了以前的讨论，当记录数较多时使用kv方式特别慢，这样的话如果使用ts方式是否能快速的增删查找，业务所限，每天要求存4w多条记录。

Jul 13 '22 02:07 Quiet-Dev

4w多条记录强烈建议换方案吧，换日志型数据库

Jul 18 '22 08:07 junzimengyou

4w多条记录强烈建议换方案吧，换日志型数据库

请问有哪个可以推荐下吗，不能用只读的

Jul 19 '22 03:07 Quiet-Dev

您是什么硬件方案？

落花繁华 @.***

------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:09 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165)

4w多条记录强烈建议换方案吧，换日志型数据库

请问有哪个可以推荐下吗，不能用只读的

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Jul 19 '22 03:07 junzimengyou

您是什么硬件方案？落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:09 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 4w多条记录强烈建议换方案吧，换日志型数据库请问有哪个可以推荐下吗，不能用只读的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

N32G455的MCU, 512K ROM , 144K RAM, 用的旺宏的8MB spi nor flash

Jul 19 '22 03:07 Quiet-Dev

LittleFS https://github.com/littlefs-project/littlefs

落花繁华 @.***

------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:29 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165)

您是什么硬件方案？落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:09 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 4w多条记录强烈建议换方案吧，换日志型数据库请问有哪个可以推荐下吗，不能用只读的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

N32G455的MCU, 512K ROM , 144K RAM, 用的旺宏的8MB spi nor flash

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Jul 19 '22 04:07 junzimengyou

LittleFS https://github.com/littlefs-project/littlefs 落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:29 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 您是什么硬件方案？落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:09 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 4w多条记录强烈建议换方案吧，换日志型数据库请问有哪个可以推荐下吗，不能用只读的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.> N32G455的MCU, 512K ROM , 144K RAM, 用的旺宏的8MB spi nor flash — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>

lfs也进行了尝试，但是在文件数量较多时，发现删除的速度比较慢，我尝试一次性删除一个具备100字节数据的60个文件（目录层级较多），发现需要5s左右才能结束，这影响了运行效率，而实际上删除在特定的情况下每小时要删除一千多记录。听说使用少量大文件的方式可以增加效率，但是这并不符合预期。

Jul 19 '22 06:07 Quiet-Dev

分多个分区多个数据库再试试

Jul 19 '22 07:07 armink

spi flash可能不适合这种运用场景，建议使用emmc或者tf卡，自带磨损均衡，但是fatfs文件系统不支持掉电保护，如果频繁擦写的话，我以前用的文件系统ext4来搞的，spi flash还是不适合大数据量频繁擦写的。

落花繁华 @.***

------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 下午3:00 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165)

LittleFS https://github.com/littlefs-project/littlefs 落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:29 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 您是什么硬件方案？落花繁华 @.*** … ------------------ 原始邮件 ------------------ 发件人: "armink/FlashDB" @.>; 发送时间: 2022年7月19日(星期二) 中午11:09 @.>; @.@.>; 主题: Re: [armink/FlashDB] 请教下在每分钟都需要存三十几条记录的场景下推荐怎么使用 (Issue #165) 4w多条记录强烈建议换方案吧，换日志型数据库请问有哪个可以推荐下吗，不能用只读的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.> N32G455的MCU, 512K ROM , 144K RAM, 用的旺宏的8MB spi nor flash — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>

lfs也进行了尝试，但是在文件数量较多时，发现删除的速度比较慢，我尝试一次性删除一个具备100字节数据的60个文件（目录层级较多），发现需要5s左右才能结束，这影响了运行效率，而实际上删除在特定的情况下每小时要删除一千多记录。听说使用少量大文件的方式可以增加效率，但是这并不符合预期。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Jul 19 '22 07:07 junzimengyou

lfs对小文件和大文件的处理方式是不一样的，所以你如果没其他办法，可以试试合并小文件为大文件，然后不使用文件删除，而是用标记无效的方式处理,再使用其他低优先级进程慢慢进行无效数据的整理的删除动作。对你这个应用，好好规划文件存储的形式，可能更为重要，而不是将功能压力放到文件系统上，毕竟嵌入式文件系统的设计都相对薄弱。

Feb 03 '23 08:02 ZanoZ