SQLite作为低流量站点的生产数据库？

Question

我正在考虑将SQLite用作一个可能会同时接收20个用户的网站的生产数据库,但是有可能达到峰值的可能是其倍数(因为该网站可以在开放的互联网上访问,并且总是有某人可能会在某个地方发布链接的可能性,这可能会导致很多人一次性访问该网站).

SQLite有可能吗？

我知道这不是一个理想的制作场景.我只是问这是否属于现实可能性范围.

Answer 1

SQLite不支持任何类型的并发,因此您可能在生产网站上运行它时遇到问题.如果您正在寻找一个"更轻"的数据库,也许可以考虑尝试像CouchDB这样的现代对象文档存储.

一定要继续针对SQLlite开发,你最初可能会好好使用它.如果您发现您的应用程序有更多的用户,那么您将要转换到postgres或mysql.

SQLlite的作者在网站上解决了这个问题:

SQLite通常可以作为中低流量网站的数据库引擎(也就是所有网站的99.9%).当然,SQLite可以处理的Web流量大小取决于网站使用其数据库的程度.一般来说,每天点击次数少于100K的网站应该可以正常使用SQLite.100K点击/天的数字是一个保守估计,而不是一个硬上限.SQLite已被证明可以使用10倍的流量.

SQLite通常可以正常工作作为网站的数据库后端.但是,如果您的网站太忙而无法将数据库组件拆分到单独的计算机上,那么您绝对应该考虑使用企业级客户端/服务器数据库引擎而不是SQLite.

所以我认为它的长短不一,为它而努力,如果它不适合你,那么转换到企业级数据库无论如何都是相当微不足道的.但请注意您的架构,并在设计数据库时考虑增长和效率.

这是一个关于将SQLite用于生产Web应用程序的更多独立注释的线程.听起来它已被用于一些混合的结果.

编辑(2014):

自从这个答案发布以来,SQLite现在具有多线程模式和预写日志记录模式,这可能会影响您评估它对中低流量站点的适用性.

Charles Leifer撰写了一篇关于SQLite的WAL(提前写入日志记录)功能的博客文章以及一些关于适当用例的深思熟虑的观点.

Answer 2

来自SQLite 网站的小摘录说明了这一切.

• 数据是否通过网络与应用程序分离？→选择 客户端/服务器

• 许多并发作家？→选择客户端/服务器

• 大数据？→选择客户端/服务器

• 否则→选择SQLite!

SQLite"正常工作"(当然不是)

Answer 3

我们经常将SQLite用于内部数据库; 员工目录,我们的事件日历和其他Intranet服务都在轻量级数据库上运行.以我们在像mySQL这样的"真实"数据库上执行的规模运行这些应用程序将是一件非常大的事.当您考虑到它们与单个中档计算机上的其他4个虚拟机一起运行时尤其如此.

有一次,我们有一个面向外部的站点,它在sqlite数据库上运行了几个月,只需要一次重启.显然,这是非常低的流量,但它很好地推动它做了什么.

Answer 4

我们在绝对没有写入的环境中遇到了类似的选项，我们选择使用 SQLite。

请参阅我关于该主题的博客文章：

好吧，使该解决方案在理论上成为可能的主要假设是我们的 SQLite 数据库是完全只读的。我们的服务器代码永远不应该改变它。这将解决任何锁定问题，因为没有读锁。我们在互联网上找不到任何人说在没有写入的情况下 SQLite 的高吞吐量读取存在问题 - 这可能是可能的！