json 当数据库有什么问题吗

[shinonome]

正在写一个项目, 大概是存一个 tmdb bangumi 的一些数据和一些简单的数据

数据数量估计不会超过 1w(估计 2000 可能就撑死了), 是否有必要上 sqlite 呢, 我自已评估下来, 比较麻烦的是

1. 数据的关联 比较不清晰
2. 有数据保存不及时(可接受

sqlite 部份我也写好了, 请问大家会怎么取舍这两个呢

[lscho]

你都写好了还纠结啥，直接 sqlite 呗

[Quarter]

sqlite 本身就比较轻量级了，直接用就可以了

[shinonome]

@lscho 感觉放内存里会快很多

[ipwx]

sqlite

[xiaomushen]

既然 sqlite 写好了，那还纠结啥？

[shinonome]

@xiaomushen json 可以少依赖，也更快了

[deplives]

你一共就 1w 数据，放磁盘和放内存的差别大吗？

[chendy]

sqllite ，下限比手撸文件高到不知道哪里去了

[xiaomushen]

@shinonome 随便吧，反正就那点儿数据

[darkengine]

放内存里会快很多 -- 你的 json 数据不用持久化？

[Ketteiron]

json 你要考虑这几个问题：
1. 数据竟态，多个进程修改同一个文件互相覆盖，极端情况下文件可能会损坏
2. 序列化/IO 开销大，改动 1 个字符也要重新全部读取->序列化->修改->反序列化->全部写入
3. 如果选择常驻内存模式不会有上述问题，但是新增了磁盘保存问题，应用意外退出会丢失数据
当你解决完所有问题，恭喜你再次发明了 sqlite

[Vegetable]

你这 json 是数据库吗？只是一个持久化文件，本质是内存数据的快照而已。

这两个东西放一起比根本就不是 json 当数据库有什么问题，而是你究竟需不需要数据库。

[adgfr32]

写内存里，全量备份成文件问题都不大。

[Ipsum]

我想起了之前有个神人，用 es 当关系数据库用，里面用户表全是 json 。

[fkdtz]

1w 条数据还值得纠结一下吗？
除非你是打印到 A4 纸上再 OCR 识别，
否则哪个方案都不会有什么大区别

[julyclyde]

json 本身没有索引吧，完整加载到内存之后才有，会导致内存占用大
当然你如果数据量少那就无所谓了。我自己也是用 json 的


但是你已经 sqlite 了还犹豫啥，坚持 sqlite 吧！
json 谈不上减少依赖啊。json 和 sqlite 都是 python 自带的标准库里的东西

[sunny352787]

你做的啥东西啊？都到内存里了为啥还是 json ？没有自己的结构吗？你搞几个 map 存也行啊，游戏里很多都是这么干的

[OneLiteCore]

看你及时性要求的吧，如果需要实时反馈的比如订单之类的，那还是老老实实上数据库吧。

但如果是那种用户行为统计数据的话及时性要求就不高了，可以考虑把用户统计的数据直接保存为 JSON ，然后可以使用 DuckDB 直接对文件夹下的所有 JSON 进行 SQL 语法检索。唯一的要求就是最好存 SSD 里面，毕竟这种场景下的都是大量细碎的小文件。

[shinonome]

@Ketteiron #11 emmm,也是呀, 看来还是要考虑很多

[xdeng]

json 的解析基本就是字符串的解析 慢 大，sqlite 可是有格式的二进制 快 小。

[liKeYunKeji]

再少的数据我都是直接 mysql ，习惯了

[strobber16]

推一手 chaiSQL

[skallz]

json 问题不大，之前写 node 也用过轻量级数据库 lowdb ，它实际上也是用的 json 的

[WarlockMan]

持久化的可靠性，json 方案相当于内存数据库，没解决持久化可靠性问题。如果进程崩了，数据丢失了。
sqlite 把这部分常见的问题都托管了。

[Rickkkkkkk]

直接本地一个 map 就装好了。

[daxin945]

看看 duckdb 呢

[uds9u32br]

go 的话接受 kv 可以用 bolt

[lovelylain]

json 的优势是可以直接用文本编辑器修改，如果用不到这点，相比 sqlite 实在没理由选 json

[mogita]

多大 payload ？希望快就全搂到内存里呗，比任何 IO 都快。。

[godall]

好搞笑，1w 数据就是手搓一个数据库也绰绰有余，至于 JSON 什么的，你结构化数据出来组装成 JSON 也毫无问题，反而 json 检索太麻烦，〔全文检索除外〕，反正数据库低于 1000w 条记录随便什么数据库都没有问题，哪个方便用哪个就行

[Div1ne]

用 sqlite 。
如果你不想持久化，想追求极致的快，sqlite 也有 memory 模式，全程不用落盘。

sqlite 的好处是你的数据访问层可以用标准的 sql 来写，万一以后你的业务体量大了，方便切换到其他数据库。不要折腾 json 了。。。。

[roundgis]

一萬條記錄 放 slice 遍歷都用不了多久 不要糾結了

[bronyakaka]

几千 1w 的数据隔这纠结半天，我们一天 1 千万数据写 pg 里，感觉离崩溃不远了

[shinonome]

@bronyakaka #33 TVT 别骂了别骂了, 就是数据量太小了才纠结一下要不要数据库, 毕竟只是为了持久存

[kuanat]

既然是 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 数据库一般就没这顾虑。