V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
chen0520
V2EX  ›  Go 编程语言

有没有人在生产用过 sqlite+nas 分布式存储的?

  •  
  •   chen0520 · 2024-09-03 09:34:27 +08:00 · 3523 次点击
    这是一个创建于 367 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    第 1 条附言  ·  2024-09-03 11:06:30 +08:00
    只是用的话限制,没说一定要用数据库
    32 条回复    2024-09-04 09:42:34 +08:00
    BG7ZAG
        1
    BG7ZAG  
       2024-09-03 09:40:01 +08:00
    国产数据库不是一堆吗?都是基于 postgresql 的,腾讯的 TDSQL ,阿里 PolarDB ,华为的 openGauss...
    chen0520
        2
    chen0520  
    OP
       2024-09-03 09:42:18 +08:00
    @BG7ZAG 特定的,我问了下这些都不能用
    Jinnrry
        3
    Jinnrry  
       2024-09-03 09:44:39 +08:00 via iPhone
    啊? SQLite 不也是数据库吗?而且目测也不在你特定数据库里面
    pota
        4
    pota  
       2024-09-03 09:45:06 +08:00
    sqlite 本身问题不大,还是要看并发量
    qW7bo2FbzbC0
        5
    qW7bo2FbzbC0  
       2024-09-03 09:47:42 +08:00
    那些能用就用呗,实在不行用 redis 实现
    oswinw
        6
    oswinw  
       2024-09-03 10:09:20 +08:00
    并发不大就问题不大
    mightybruce
        7
    mightybruce  
       2024-09-03 10:24:15 +08:00   ❤️ 3
    甲方说什么就是什么, 都限定了信创数据库,那就用起来,其他数据库根本不会给你过审的。
    joyoyao
        8
    joyoyao  
       2024-09-03 10:25:11 +08:00
    访问量不大可以的,sqlite 小项目用的人还是很多的。nas 分布式存储是啥,nfs 吗?
    mightybruce
        9
    mightybruce  
       2024-09-03 10:28:51 +08:00
    sqlite 也是数据库,只不过是可以嵌入程序运行的数据库,像这样的嵌入式数据库有 SQLite, RocksDB, and DuckDB, 多尝试尝试
    ConfusedBiscuit
        10
    ConfusedBiscuit  
       2024-09-03 10:29:09 +08:00
    我猜 OP 的主要疑问是,如果放在 NAS 等共享存储里,多个 sqlite 实例同时访问同一个数据库文件,会不会有问题。说实话,我也没这么用过,但是听起来有点儿危险。不知道有没有 sqlite 大佬能解答。

    还有,我也同意楼上大家的看法,要求用什么数据库就用什么数据库,做好数据层抽象,未来想换什么数据库都不太麻烦。
    mightybruce
        11
    mightybruce  
       2024-09-03 10:32:40 +08:00   ❤️ 1
    题外话,sqlite 不适合独立出来做数据服务器,适合嵌入在程序中, 这种就算用 sqlite 需要魔改,当然市面上已经有了这种魔改 sqlite 作为数据库引擎的高性能分布式数据库 (bloomberg 出的 comdb2)
    https://github.com/bloomberg/comdb2
    wwd179
        12
    wwd179  
       2024-09-03 10:32:54 +08:00
    并发写 sqlite 文件的时候,有写锁吧。性能估计很差。
    chen0520
        13
    chen0520  
    OP
       2024-09-03 11:02:29 +08:00
    @ConfusedBiscuit 没有指定,可以不用,只是用实体数据库的话只能用这一种
    meeop
        14
    meeop  
       2024-09-03 11:06:50 +08:00
    性能没问题,只是你需要自己处理并发访问,数据备份等逻辑
    chen0520
        15
    chen0520  
    OP
       2024-09-03 11:09:41 +08:00
    @joyoyao 是的,基于 k8s pv 挂上去
    chen0520
        16
    chen0520  
    OP
       2024-09-03 11:10:18 +08:00
    @meeop 你的意思并发写的话要有实现分布式锁的逻辑?
    mightybruce
        17
    mightybruce  
       2024-09-03 11:36:06 +08:00
    建议别尝试了, 通过修改 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 的主从之类的方案
    onichandame
        18
    onichandame  
       2024-09-03 11:46:11 +08:00
    不让用数据库就 json 文件一把梭。sqlite 设计只应对单线程程序访问,放共享存储中也只能同时给一个进程使用
    chen0520
        19
    chen0520  
    OP
       2024-09-03 11:46:14 +08:00
    @mightybruce 好的,感谢大佬,码了这么多字
    body007
        20
    body007  
       2024-09-03 11:52:01 +08:00
    wxf666
        21
    wxf666  
       2024-09-03 12:04:09 +08:00
    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.


    @wwd179 #12

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

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

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

    - 200 模拟发帖回帖 + 全文索引 / 秒
    - 1100 获取整帖(包括回帖者信息) / 秒
    Mithril
        22
    Mithril  
       2024-09-03 12:11:01 +08:00
    SQLite 的锁是基于文件系统的,所以官方也不建议你把数据库文件扔 NFS 里,主要是有些 NFS 文件系统实现的时候锁的机制做的不好,多线程或多进程访问的时候有可能损坏你的数据库文件。

    但有些文件系统的实现是明确说过支持全部的锁机制,没记错的话 AWS 的 EBS 就可以。这种情况下你把 SQLite 文件放上去共享也没问题。
    xuanbg
        23
    xuanbg  
       2024-09-03 12:11:34 +08:00
    生产用 nas 做数据备份还是把服务部署在 nas 上?
    Mystery0
        24
    Mystery0  
       2024-09-03 12:16:25 +08:00 via Android
    sqlite 不太清楚,h2 这种数据库的 db 文件丢 nas 里面连不了,真实项目踩过坑的,不过我估计 sqlite 应该也差不多
    Rorysky
        25
    Rorysky  
       2024-09-03 12:21:36 +08:00
    @ConfusedBiscuit sqlite 只支持一写多读,写的时候直接锁表
    vx7298
        26
    vx7298  
       2024-09-03 12:22:13 +08:00
    国产的 go 要求不?😂
    glcolof
        27
    glcolof  
       2024-09-03 14:43:08 +08:00
    既然前提是“数据库访问量不大”,可以单独开发一个后端程序,由它来读写 SQLite ,其它程序必须通过这个后端程序的接口来存取数据,就像网站前后端开发一样。
    mayli
        28
    mayli  
       2024-09-03 14:47:36 +08:00
    sqlite + litefs 试试
    chen0520
        29
    chen0520  
    OP
       2024-09-03 14:52:14 +08:00
    @body007 这个包不知道能不能集成到实际项目中,而不是单独的实体,单独的实体都要审查的
    xsen
        30
    xsen  
       2024-09-03 17:03:14 +08:00
    实现个数据库服务做 sqlite 缓存,写排队,读则缓存——未击中再访问数据库
    表设计要合理,尽量不要跨表写
    cadmuxe
        31
    cadmuxe  
       2024-09-04 03:17:16 +08:00
    像上面说的 sqlite 的锁是文件系统实现的。nfs 不支持这个。
    我家里的 nas 和 container host 不是一个机器,nfs 挂的文件。Plex 因为这个不能正常工作。
    thinkingbullet
        32
    thinkingbullet  
       2024-09-04 09:42:34 +08:00
    https://github.com/rqlite/rqlite 基于 sqlite 的分布式关系数据库,支持 window,Linux,macOS
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5274 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 07:55 · PVG 15:55 · LAX 00:55 · JFK 03:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.