有没有人有在LAN(Windows或Linux)上的SMB共享上运行Sqlite数据库的实际经验?
从文档中可以清楚地看出,这并不是共享Sqlite数据库的最快方式.
显而易见的警告是它可能很慢,并且Sqlite一次只支持一个写入DB的线程.因此,您的并发性会降低很多,因为您的数据库更新现在会阻止数据库更长时间(数据在网络上传输时数据库将被锁定).
对于我的应用程序,我想要共享的数据量相当小,并且写入不太频繁(最多每隔几秒写一次).
我应该注意什么?这可以吗?
我知道这不是Sqlite的设计目标,我对基于Postgres/MySql/Sql Server的解决方案不太感兴趣,因为我试图尽可能保持我的应用程序尽可能少的依赖.
相关链接:
从sqlite邮件列表中,我想一个很大的问题是SMB(windows或linux)上的filelock apis有多不可靠
小智 31
我对基于文件的数据库(即那些没有数据库服务器进程的数据库)的经验,可以追溯到二十多年,如果你试图分享它们,它们将不可避免地最终被破坏.我强烈建议你再看看MySQL.
请注意,我不是在选择SQLite - 我自己使用它,而不是作为共享数据库.
你要求真实世界的经验。这里有一些:
SQLite 锁定是健壮的,假设底层(网络)文件系统也是健壮的。从历史上看,这是一个糟糕的假设。最近的操作系统让它变得更好。
如果您按规则行事,那么您最大的问题将是数据库在一段时间内保持“锁定”状态的情况。例如,如果网络丢弃来自阅读器的“解锁”请求,您可能无法在锁定到期之前写入。如果作家的“解锁”丢失,您将无法阅读。(公平地说,您可能会遇到与普通文档相同的问题。)
在为数据库禁用“机会锁定”(客户端级文件缓存)的良好可靠网络上,您会遇到更少的问题。
好吧,我不是伟大的sqlite专家,但我相信锁定记录/表可能无法正常工作,可能会使数据库损坏.因为没有单个服务器维护中央锁定,所以在网络上共享同一文件的不同机器上的两个sqlite dll实例可能根本无法正常工作.如果在同一台机器上打开数据库,sqlite可能会使用操作系统提供的文件级别锁定来保持完整性,但我怀疑它是否能够在网络共享上正常工作.
"如果你有许多客户端程序通过网络访问公共数据库,你应该考虑使用客户端/服务器数据库引擎而不是SQLite.SQLite将在网络文件系统上工作,但由于与大多数网络文件系统相关的延迟,性能将此外,许多网络文件系统实现的文件锁定逻辑包含错误(在Unix和Windows上).如果文件锁定不能正常工作,则两个或更多客户端程序可能修改相同的部分同一个数据库同时导致数据库损坏.由于这个问题是由底层文件系统实现中的错误引起的,因此SQLite无法阻止它."
来自https://www.sqlite.org/whentouse.html
这也适用于任何类型的基于文件的数据库 Microsoft Access
| 归档时间: |
|
| 查看次数: |
29967 次 |
| 最近记录: |