未登录用户
首 页
书 架
登录系统
注册账号
联系我们
duidaima.com
版权声明
闽ICP备2020021581号
闽公网安备 35020302035485号
搜索
我要提问
随便写写
我要写书
这种情况用Json当数据库有什么问题吗?
发布于 3小时前
20 热度
12 评论
独走人海
0 粉丝 33 篇博客
关注
打赏
正在写一个项目, 大概是存一个 tmdb bangumi 的一些数据和一些简单的数据。数据数量估计不会超过 1w(估计 2000 可能就撑死了), 是否有必要上 sqlite 呢, 我自已评估下来, 比较麻烦的是
1.数据的关联 比较不清晰
2.有数据保存不及时(可接受
sqlite 部份我也写好了, 请问大家会怎么取舍这两个呢?
用户评论
弄潮儿
既然是 go 板块,大概率是想避开 sqlite CGO 依赖吧。目前无需 CGO 的实现就两个思路,要么 modernc.org/sqlite 这种自动化 c 代码转 go 代码的方案,要么就是 modernc.org/sqlite 这种外挂一个中间层通过 ipc 或者什么方式来使用。因为这俩方案在我看来都不理想,所以要么不用,用就老老实实 CGO ,无非就是写个多平台的构建脚本。
一般来说我不推荐用任何文件作为 naive 数据库,因为你需要实现最起码的并发控制(线程安全)、原子写入与(内存和持久化副本)一致性。当然这个东西没那么难,vibe 一下 100 行可能就够用了。不推荐的原因主要还是维护起来麻烦,因为用着用着就发现,这种方案不是很方便存储结构体,需要注意序列化反序列化的问题,然后增删改查也要重新造轮子。日后换方案也是麻烦事。
我比较常用的方案是 etcd-io/bbolt 这个 kv 数据库,该有的功能都有,有个自带的命令行程序,管理导出都方便,不用担心换技术栈。如果不是很依赖 sql 范式对数据做校验,推荐直接把逻辑交给应用代码,数据库就单纯做存储了。这样还有个好处,就是也用不到 orm ,大多数情况下 orm 的表达能力比代码差远了。用 orm 就很容易对调整数据库 schema 的事情产生抵触,毕竟改一次几乎所有语句都会要跟着改,用 kv 数据库一般就没这顾虑。
2025/10/14 11:37:00
[
0
]
[
0
]
回复
原木风
用 sqlite 。如果你不想持久化,想追求极致的快,sqlite 也有 memory 模式,全程不用落盘。sqlite 的好处是你的数据访问层可以用标准的 sql 来写,万一以后你的业务体量大了,方便切换到其他数据库。不要折腾 json 了。。。。
2025/10/14 11:34:00
[
0
]
[
0
]
回复
张蜚
好搞笑,1w 数据就是手搓一个数据库也绰绰有余,至于 JSON 什么的,你结构化数据出来组装成 JSON 也毫无问题,反而 json 检索太麻烦,〔全文检索除外〕,反正数据库低于 1000w 条记录随便什么数据库都没有问题,哪个方便用哪个就行
2025/10/14 11:11:00
[
0
]
[
0
]
回复
凉城以北
持久化的可靠性,json 方案相当于内存数据库,没解决持久化可靠性问题。如果进程崩了,数据丢失了。
sqlite 把这部分常见的问题都托管了。
2025/10/14 9:24:00
[
0
]
[
0
]
回复
时光浅巷
看你及时性要求的吧,如果需要实时反馈的比如订单之类的,那还是老老实实上数据库吧。但如果是那种用户行为统计数据的话及时性要求就不高了,可以考虑把用户统计的数据直接保存为 JSON ,然后可以使用 DuckDB 直接对文件夹下的所有 JSON 进行 SQL 语法检索。唯一的要求就是最好存 SSD 里面,毕竟这种场景下的都是大量细碎的小文件。
2025/10/14 9:19:00
[
0
]
[
0
]
回复
念之森蓝
json 本身没有索引吧,完整加载到内存之后才有,会导致内存占用大,当然你如果数据量少那就无所谓了。我自己也是用 json 的,但是你已经 sqlite 了还犹豫啥,坚持 sqlite 吧!json 谈不上减少依赖啊。json 和 sqlite 都是 python 自带的标准库里的东西!
2025/10/14 9:15:00
[
0
]
[
0
]
回复
煮酒慰风尘
1w 条数据还值得纠结一下吗?除非你是打印到 A4 纸上再 OCR 识别,否则哪个方案都不会有什么大区别!
2025/10/14 9:11:00
[
0
]
[
0
]
回复
星河几许
我想起了之前有个神人,用 es 当关系数据库用,里面用户表全是 json 。
2025/10/14 9:07:00
[
0
]
[
0
]
回复
山色风月倦
你这 json 是数据库吗?只是一个持久化文件,本质是内存数据的快照而已。这两个东西放一起比根本就不是 json 当数据库有什么问题,而是你究竟需不需要数据库。
2025/10/14 8:59:00
[
0
]
[
0
]
回复
彼岸星光
json 你要考虑这几个问题:
1. 数据竟态,多个进程修改同一个文件互相覆盖,极端情况下文件可能会损坏
2. 序列化/IO 开销大,改动 1 个字符也要重新全部读取->序列化->修改->反序列化->全部写入
3. 如果选择常驻内存模式不会有上述问题,但是新增了磁盘保存问题,应用意外退出会丢失数据
当你解决完所有问题,恭喜你再次发明了 sqlite
2025/10/14 8:54:00
[
0
]
[
0
]
回复
冷流大哥
sqllite ,下限比手撸文件高到不知道哪里去了
2025/10/14 8:43:00
[
0
]
[
0
]
回复
寒春玉柳
你都写好了还纠结啥,直接 sqlite 呗。sqlite 本身就比较轻量级了,直接用就可以了!
2025/10/14 8:38:00
[
0
]
[
0
]
回复
点击加载更多评论
吐槽.灌水
443 成员 |
1635 话题
+我要提问
+随便写写
可能感兴趣的话题
有几千万的数据量的层级权限下的列表展示页查询应该怎么设计?
大家做小程序开发用的都是什么技术栈?
iOS26真的很耗电量,你们有同感吗?
影视飓风成功最大的功臣是竟是Tim的父亲?
一般来说我不推荐用任何文件作为 naive 数据库,因为你需要实现最起码的并发控制(线程安全)、原子写入与(内存和持久化副本)一致性。当然这个东西没那么难,vibe 一下 100 行可能就够用了。不推荐的原因主要还是维护起来麻烦,因为用着用着就发现,这种方案不是很方便存储结构体,需要注意序列化反序列化的问题,然后增删改查也要重新造轮子。日后换方案也是麻烦事。
我比较常用的方案是 etcd-io/bbolt 这个 kv 数据库,该有的功能都有,有个自带的命令行程序,管理导出都方便,不用担心换技术栈。如果不是很依赖 sql 范式对数据做校验,推荐直接把逻辑交给应用代码,数据库就单纯做存储了。这样还有个好处,就是也用不到 orm ,大多数情况下 orm 的表达能力比代码差远了。用 orm 就很容易对调整数据库 schema 的事情产生抵触,毕竟改一次几乎所有语句都会要跟着改,用 kv 数据库一般就没这顾虑。
sqlite 把这部分常见的问题都托管了。
1. 数据竟态,多个进程修改同一个文件互相覆盖,极端情况下文件可能会损坏
2. 序列化/IO 开销大,改动 1 个字符也要重新全部读取->序列化->修改->反序列化->全部写入
3. 如果选择常驻内存模式不会有上述问题,但是新增了磁盘保存问题,应用意外退出会丢失数据
当你解决完所有问题,恭喜你再次发明了 sqlite