JSON vs SQLite 数据存储的优缺点。

JSON（文件存储） vs SQLite

核心场景：大量零散小文件、数据持续累积增长，下面对比重点围绕这个痛点。

说明：这里 JSON 指「一个 / 多个独立 .json 文件存数据」；不是 JSON 字段存在数据库里。

一、核心优缺点对比

📄 JSON 文件（零散小文件方案）

✅ 优点

1. 简单，零依赖：不需要服务、不需要库，直接读写文件，随手用文本编辑器打开查看。
2. 单条数据隔离：一条记录一个 json 文件时，单个文件损坏不会影响其他文件。
3. 增量备份简单：只需要同步新增 / 修改的小文件。
4. 程序调试友好：出错直接打开 json 看内容。

❌ 缺点（就是你关心的：小文件越来越多之后的大坑）

1. 文件系统瓶颈（最致命） 操作系统的目录有 inode / 目录项上限。几十万个小文件放在同一个文件夹下，ls、遍历、查找都会巨慢。 哪怕文件很小，每个文件都要占用一个 inode，占用额外磁盘元数据空间。
2. 没有事务：写文件中途断电 / 程序崩溃，JSON 文件直接半截损坏，数据丢失。
3. 查询、过滤极慢：想查满足条件的数据，必须遍历打开全部 json 文件、解析，不能索引。
4. 更新开销大：修改一条记录，要完整重写整个 json 文件；不能局部修改。
5. 并发读写麻烦：多进程同时写同一个 json，极易文件覆盖，需要自己加锁。
6. 磁盘碎片：大量频繁改写的小文件，碎片会越来越多。

缓解办法：拆分目录（按日期 / ID 哈希分文件夹，比如 data/00/01.json），但只是延缓，不能根治。

---

🗄️ SQLite（单文件数据库）

✅ 优点（完美解决大量零散小文件痛点）

1. 全部数据打包在 1 个（或少量）db 文件，不会产生成千上万个小文件，inode 占用极低。文件系统压力几乎不受记录条数影响。
2. 支持索引：按字段查询、过滤、排序速度远高于遍历 json。
3. 事务 ACID：写操作要么完整成功，要么回滚，不会出现半截损坏的数据。
4. 支持局部更新：只修改需要的字段，不用重写全部数据。
5. 内置锁机制，原生支持多进程 / 多线程读写控制。
6. 支持 JSON 字段：SQLite 本身就可以存 JSON 文本，还能对 json 内部 key 建立索引。

❌ 缺点

1. 单文件损坏风险：磁盘 IO 崩溃、断电，极端情况下整个 db 文件损坏（但开启 WAL 模式能大幅降低风险）。
2. 不能直接用文本编辑器浏览，查看数据需要数据库工具。
3. 超大库（千万级记录以上）会有性能拐点；百万级以内通常非常稳。
4. 多机器同时写同一个 db 文件性能很差（SQLite 不适合网络多机并发写）。
5. 备份需要复制整个 db 文件（可以用 VACUUM、在线备份 API 优化）。

二、针对你的场景：数据不断新增，小文件持续变多

什么时候选 JSON 文件

• 总数据量不大，文件数控制在几万以内；
• 几乎不需要复杂查询，大多按 ID 直接读取单条；
• 简单脚本，不想引入数据库依赖；
• 数据很少修改，只读为主。

❌ 不推荐：长期运行，持续新增，文件数量会涨到几十万、上百万。目录遍历、文件元数据开销会成为性能天花板。

什么时候选 SQLite

• 长期持续写入，记录数量持续上涨，担心小文件爆炸；
• 需要按字段搜索、筛选数据；
• 需要保证写入可靠性，防止断电坏数据；
• 希望避免大量 inode 占用、目录卡顿。

✅ 推荐：绝大多数本地持久化业务，单设备读写，优先 SQLite，甚至你可以继续把 JSON 存在 SQLite 的 TEXT 字段里，保留 JSON 灵活性，同时享受数据库能力。

三、补充方案参考（可选）

1. SQLite + JSON 字段：推荐折中方案。记录主体放 JSON 字符串，查询简单字段建立索引，兼顾灵活和性能。
2. LevelDB / RocksDB：KV 嵌入式数据库，也是单文件组，适合高吞吐写入，查询能力弱于 SQLite。适合只做 key-value 存取，不需要复杂 SQL。

四、简单总结一句话

如果数据会长期累积，小文件数量持续增长，优先 SQLite，避免文件系统 inode 爆炸； JSON 零散小文件适合轻量、短期、文件总量可控的场景，文件一多性能和稳定性会明显变差。