SQLite for client-server

时间:2009-08-24 10:05:47

标签: performance sqlite client-server

我在Stackoverflow上看到了几个SQLite性能问题,但重点是网站,我正在考虑在客户端 - 服务器场景中使用这个数据库:

  • 我现在预计一台服务器有1-10个客户端,未来可能会达到50个或更多。
  • 读取次数略多于写入次数
  • 数据库将位于服务器进程后面(即:不通过网络使用直接数据库访问)

与使用PostgreSQL相比,使用SQLite会降低应用程序的响应速度吗?我的直觉告诉我,对于这些负载应该没问题,但也许有人对这种情况有一些实际经验。

3 个答案:

答案 0 :(得分:13)

我确实使用SQLite作为与~10个并发用户一起使用的主要客户端/服务器产品,我对此决定深感遗憾。在我看来 - 由于其精细的锁定粒度,PostgreSQL比SQLite更适合客户端/服务器场景。

当有人需要写东西时,当整个数据库被锁定时,你根本无法走得太远......

我非常喜欢SQLite(我甚至编写了一个用于比较SQLite数据库的商业实用程序 - SQLite Compare但是我认为当你有客户端/服务器场景时它不符合要求。

即使是SQLite的作者says,它也应该被用来替代自定义文件格式而不是一个完整的数据库服务器。我希望我更认真地听取他的意见。

答案 1 :(得分:3)

您没有提到您正在使用的操作系统和Postgres版本。但是,在考虑更改数据库引擎之前,尝试使用典型用法对当前数据库进行一些日志记录和基准测试,然后优化“最重”的问题。也许你的后端处理负载会使DB问题时间无关紧要? 由于SQLite是基于文件的DBMS,当客户编号增长时,来自多个进程的并发访问会降低性能(在评论后编辑)

以下问题可能会有所帮助:How Scalable is SQLite?

答案 2 :(得分:1)

我会向S.Lott的回答确认。

我不知道SQLite与PostgreSQL相比如何表现,因为我不知道任何新的测量,但我在相当类似的环境中使用SQLite的经验相当不错。

在我看来,唯一可能导致麻烦的是你有很多写作。但这一切都取决于我所说的每秒总数。

在我看来,对于SQLite来说,拥有一个服务器进程的设置也是最佳的 - 所以你可以避免它在多任务处理方面的弱点。