Golang Go语言中是否有人在生产环境中使用过 sqlite+nas 分布式存储?

发布于 1周前 作者 itying888 来自 Go语言

数据库访问量不算大,甲方要求如果用数据库只能用特定的国产数据库,我网上搜了一下几乎没啥介绍,所以就想能不能直接不通过实体的数据库,目前我能想到的方案就这个,我主要担心瞬时的的简单并发会不会有问题,有人有相关经验吗


Golang Go语言中是否有人在生产环境中使用过 sqlite+nas 分布式存储?
33 回复

国产数据库不是一堆吗?都是基于 postgresql 的,腾讯的 TDSQL ,阿里 PolarDB ,华为的 openGauss…

更多关于Golang Go语言中是否有人在生产环境中使用过 sqlite+nas 分布式存储?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


特定的,我问了下这些都不能用

啊? SQLite 不也是数据库吗?而且目测也不在你特定数据库里面

sqlite 本身问题不大,还是要看并发量

那些能用就用呗,实在不行用 redis 实现

并发不大就问题不大

甲方说什么就是什么, 都限定了信创数据库,那就用起来,其他数据库根本不会给你过审的。

访问量不大可以的,sqlite 小项目用的人还是很多的。nas 分布式存储是啥,nfs 吗?

sqlite 也是数据库,只不过是可以嵌入程序运行的数据库,像这样的嵌入式数据库有 SQLite, RocksDB, and DuckDB, 多尝试尝试

我猜 OP 的主要疑问是,如果放在 NAS 等共享存储里,多个 sqlite 实例同时访问同一个数据库文件,会不会有问题。说实话,我也没这么用过,但是听起来有点儿危险。不知道有没有 sqlite 大佬能解答。

还有,我也同意楼上大家的看法,要求用什么数据库就用什么数据库,做好数据层抽象,未来想换什么数据库都不太麻烦。

题外话,sqlite 不适合独立出来做数据服务器,适合嵌入在程序中, 这种就算用 sqlite 需要魔改,当然市面上已经有了这种魔改 sqlite 作为数据库引擎的高性能分布式数据库 (bloomberg 出的 comdb2)
https://github.com/bloomberg/comdb2

并发写 sqlite 文件的时候,有写锁吧。性能估计很差。

没有指定,可以不用,只是用实体数据库的话只能用这一种

性能没问题,只是你需要自己处理并发访问,数据备份等逻辑

是的,基于 k8s pv 挂上去

你的意思并发写的话要有实现分布式锁的逻辑?

建议别尝试了, 通过修改 sqlite 数据库文件同步到共享存储的方式的方式是错误的,不要研究了,
另外出了问题你也搞不定,sqlite 是不存在跨机操作数据文件的方式的,sqlite 对数据文件的保护的确是操作系统的文件锁,
另外 nas 这种共享存储 不适合关键的数据库主备。

我也只见过 mysql, oracle 数据库搞这种共享存储的数据库集群的成熟方案,sqlite 别搞。

1.基于共享存储的方案 SAN
方案介绍:SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享,共享存储能够为数据库服务器和存储解耦。使用共享存储时,服务器能够正常挂载文件系统并操作,如果服务器挂了,备用服务器可以挂载相同的文件系统,执行需要的恢复操作,然后启动 MySQL 。

2.基于磁盘复制的方案 DRBD
方案介绍:DRBD(Distributed Replicated Block Device)是一种磁盘复制技术,可以获得和 SAN 类似的效果。DBRD 是一个以 linux 内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上,并在主设备提交块之前记录下来。DRBD 与 SAN 类似,也是有一个热备机器,开始提供服务时会使用和故障机器相同的数据,只不过 DRBD 的数据是复制存储,不是共享存储。

其他方式是通过网络 IO 的主从之类的方案

不让用数据库就 json 文件一把梭。sqlite 设计只应对单线程程序访问,放共享存储中也只能同时给一个进程使用

好的,感谢大佬,码了这么多字

SQLite 不适合分布式写入。

要有高的写并发,就得利用 WAL ,尽可能缓冲多点事务,再落盘写入。

而官方说,WAL 模式要求所有进程在同一主机上,不能在网络文件系统上工作:

> All processes using a database must be on the same host computer; WAL does not work over a network filesystem. This is because WAL requires all processes to share a small amount of memory and processes on separate host machines obviously cannot share memory with each other.


#12

单机上使用的话,利用好 WAL ,加上外部互斥锁(或者一个进程专门处理写请求),可以实现很高的并发。

这两天我测试过,在电视盒子上(单核 Nginx 默认页压测 1W QPS ,性能不及 6 年前骁龙 636 千元机一半),

Python 的 FastAPI + SQLite + 去年本站被爬的千万数据:

- 200 模拟发帖回帖 + 全文索引 / 秒
- 1100 获取整帖(包括回帖者信息) / 秒

SQLite 的锁是基于文件系统的,所以官方也不建议你把数据库文件扔 NFS 里,主要是有些 NFS 文件系统实现的时候锁的机制做的不好,多线程或多进程访问的时候有可能损坏你的数据库文件。

但有些文件系统的实现是明确说过支持全部的锁机制,没记错的话 AWS 的 EBS 就可以。这种情况下你把 SQLite 文件放上去共享也没问题。

生产用 nas 做数据备份还是把服务部署在 nas 上?

sqlite 不太清楚,h2 这种数据库的 db 文件丢 nas 里面连不了,真实项目踩过坑的,不过我估计 sqlite 应该也差不多

sqlite 只支持一写多读,写的时候直接锁表

国产的 go 要求不?😂

既然前提是“数据库访问量不大”,可以单独开发一个后端程序,由它来读写 SQLite ,其它程序必须通过这个后端程序的接口来存取数据,就像网站前后端开发一样。

sqlite + litefs 试试

这个包不知道能不能集成到实际项目中,而不是单独的实体,单独的实体都要审查的

实现个数据库服务做 sqlite 缓存,写排队,读则缓存——未击中再访问数据库
表设计要合理,尽量不要跨表写

像上面说的 sqlite 的锁是文件系统实现的。nfs 不支持这个。
我家里的 nas 和 container host 不是一个机器,nfs 挂的文件。Plex 因为这个不能正常工作。

https://github.com/rqlite/rqlite 基于 sqlite 的分布式关系数据库,支持 window,Linux,macOS

作为IT领域Go语言方面的专家,对于Golang在生产环境中的使用有一定的了解。关于“sqlite+nas 分布式存储”这一组合,以下是我的专业分析:

Golang中sqlite+nas分布式存储的使用情况

在Golang中,sqlite通常作为一个轻量级的数据库管理系统,在资源受限或需要快速部署的场景中广泛应用。而NAS(网络附加存储)则是一种通过网络进行数据访问和存储的设备。

尽管sqlite在处理中小型数据集时表现出色,但考虑到分布式存储的需求,sqlite的单点存储特性可能会成为瓶颈。NAS虽然提供了网络访问的便捷性,但通常不直接参与数据库的分片或分布式处理。

在分布式存储场景中,通常会选择更适合分布式架构的数据库系统,如MongoDB、Cassandra等,它们提供了内置的分片、复制和故障转移机制。

因此,虽然sqlite和NAS在各自的应用场景中都有其优势,但将它们组合用于分布式存储可能不是最佳选择。在生产环境中,建议根据具体需求选择更适合的分布式存储解决方案。

回到顶部