正在写一个项目, 大概是存一个 tmdb bangumi 的一些数据和一些简单的数据
数据数量估计不会超过 1w(估计 2000 可能就撑死了), 是否有必要上 sqlite 呢, 我自已评估下来, 比较麻烦的是
- 数据的关联 比较不清晰
- 有数据保存不及时(可接受
sqlite 部份我也写好了, 请问大家会怎么取舍这两个呢
This topic created in 389 days ago, the information mentioned may be changed or developed.
 |
lschoOct 13, 2025
1
你都写好了还纠结啥，直接 sqlite 呗
|
 |
QuarterOct 13, 2025 via Android
2
sqlite 本身就比较轻量级了，直接用就可以了
|
 |
ipwxOct 13, 2025
4
sqlite
|
 |
xiaomushenOct 13, 2025
5
既然 sqlite 写好了，那还纠结啥？
|
 |
6
@xiaomushen json 可以少依赖，也更快了
|
 |
deplivesOct 13, 2025
7
你一共就 1w 数据，放磁盘和放内存的差别大吗？
|
 |
chendyOct 13, 2025
8
sqllite ，下限比手撸文件高到不知道哪里去了
|
|
9
@shinonome 随便吧，反正就那点儿数据
|
1 |
darkengineOct 13, 2025
10
放内存里会快很多 -- 你的 json 数据不用持久化？
|
 |
11
json 你要考虑这几个问题：
1. 数据竟态，多个进程修改同一个文件互相覆盖，极端情况下文件可能会损坏 2. 序列化/IO 开销大，改动 1 个字符也要重新全部读取->序列化->修改->反序列化->全部写入 3. 如果选择常驻内存模式不会有上述问题，但是新增了磁盘保存问题，应用意外退出会丢失数据 当你解决完所有问题，恭喜你再次发明了 sqlite |
 |
12
你这 json 是数据库吗？只是一个持久化文件，本质是内存数据的快照而已。
这两个东西放一起比根本就不是 json 当数据库有什么问题，而是你究竟需不需要数据库。 |
 |
zh3256Oct 13, 2025 via Android
13
写内存里，全量备份成文件问题都不大。
|
 |
IpsumOct 13, 2025 via Android
14
我想起了之前有个神人，用 es 当关系数据库用，里面用户表全是 json 。
|
 |
fkdtzOct 13, 2025
15
1w 条数据还值得纠结一下吗？
除非你是打印到 A4 纸上再 OCR 识别， 否则哪个方案都不会有什么大区别  |
 |
julyclydeOct 13, 2025
16
json 本身没有索引吧，完整加载到内存之后才有，会导致内存占用大
当然你如果数据量少那就无所谓了。我自己也是用 json 的 但是你已经 sqlite 了还犹豫啥，坚持 sqlite 吧！ json 谈不上减少依赖啊。json 和 sqlite 都是 python 自带的标准库里的东西 |
 |
sunny352787Oct 13, 2025
17
你做的啥东西啊？都到内存里了为啥还是 json ？没有自己的结构吗？你搞几个 map 存也行啊，游戏里很多都是这么干的
|
 |
18
看你及时性要求的吧，如果需要实时反馈的比如订单之类的，那还是老老实实上数据库吧。
但如果是那种用户行为统计数据的话及时性要求就不高了，可以考虑把用户统计的数据直接保存为 JSON ，然后可以使用 DuckDB 直接对文件夹下的所有 JSON 进行 SQL 语法检索。唯一的要求就是最好存 SSD 里面，毕竟这种场景下的都是大量细碎的小文件。 |
 |
46foOct 13, 2025
20
json 的解析基本就是字符串的解析 慢 大，sqlite 可是有格式的二进制 快 小。
|
 |
liKeYunKejiOct 13, 2025
21
再少的数据我都是直接 mysql ，习惯了
|
 |
strobber16Oct 13, 2025
22
推一手 chaiSQL
|
 |
skallzOct 13, 2025
23
json 问题不大，之前写 node 也用过轻量级数据库 lowdb ，它实际上也是用的 json 的
|
 |
WarlockManOct 13, 2025
24
持久化的可靠性，json 方案相当于内存数据库，没解决持久化可靠性问题。如果进程崩了，数据丢失了。
sqlite 把这部分常见的问题都托管了。 |
 |
RickkkkkkkOct 13, 2025
25
直接本地一个 map 就装好了。
|
 |
haoyunyinglaiOct 13, 2025
26
看看 duckdb 呢
|
 |
uds9u32brOct 13, 2025
27
go 的话接受 kv 可以用 bolt
|
 |
lovelylainOct 13, 2025
28
json 的优势是可以直接用文本编辑器修改，如果用不到这点，相比 sqlite 实在没理由选 json
|
 |
mogitaOct 13, 2025
29
多大 payload ？希望快就全搂到内存里呗，比任何 IO 都快。。
|
 |
godallOct 13, 2025 via Android
30
好搞笑，1w 数据就是手搓一个数据库也绰绰有余，至于 JSON 什么的，你结构化数据出来组装成 JSON 也毫无问题，反而 json 检索太麻烦，〔全文检索除外〕，反正数据库低于 1000w 条记录随便什么数据库都没有问题，哪个方便用哪个就行
|
 |
Div1neOct 13, 2025
31
用 sqlite 。
如果你不想持久化，想追求极致的快，sqlite 也有 memory 模式，全程不用落盘。 sqlite 的好处是你的数据访问层可以用标准的 sql 来写，万一以后你的业务体量大了，方便切换到其他数据库。不要折腾 json 了。。。。 |
 |
roundgisOct 13, 2025 via Android
32
一萬條記錄 放 slice 遍歷都用不了多久 不要糾結了
|
 |
bronyakakaOct 13, 2025
33
几千 1w 的数据隔这纠结半天，我们一天 1 千万数据写 pg 里，感觉离崩溃不远了
|
|
34
@bronyakaka #33 TVT 别骂了别骂了, 就是数据量太小了才纠结一下要不要数据库, 毕竟只是为了持久存
|
 |
kuanatOct 14, 2025
35
既然是 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 数据库一般就没这顾虑。 |
 |
hello158Oct 14, 2025
37
我其实更喜欢 Json ，对象直接 Json 存储。
不用考虑什么一对多多对一 关联查询。 用 SqlLite 也行啊，只是你的数据表只有 2 个字段，ID + DATA ，把 json 存入 DATA 字段即可。 |
 |
Geon97Oct 15, 2025
38
duckdb 吧，放到内存里
|
 |
BuffDogOct 15, 2025
39
没问题啊，有什么问题？
你用龟甲来做数据库也没问题的 |
 |
c4pt0rOct 15, 2025
41
先问是 OLTP 场景还是 OLAP 场景再决定吧。。。
|
Select Language