我正在考虑使用 SQLite 作为一个站点的生产数据库,该站点可能会同时接收 20 个用户,但峰值可能是该站点的许多倍(因为该站点可以在开放的互联网上访问,并且总是有可能有人会在某个地方发布一个链接,该链接可能会同时将许多人吸引到该站点)。
SQLite 有可能吗?
我知道这不是一个理想的生产场景。我只是在问这是否在现实可能性的范围内。
我正在考虑使用 SQLite 作为一个站点的生产数据库,该站点可能会同时接收 20 个用户,但峰值可能是该站点的许多倍(因为该站点可以在开放的互联网上访问,并且总是有可能有人会在某个地方发布一个链接,该链接可能会同时将许多人吸引到该站点)。
SQLite 有可能吗?
我知道这不是一个理想的生产场景。我只是在问这是否在现实可能性的范围内。
SQLite 不支持任何类型的并发,因此在生产网站上运行它可能会遇到问题。如果您正在寻找一个“更轻”的数据库,也许可以考虑尝试像 CouchDB 这样的现代对象文档存储。
无论如何,继续针对 SQLite 进行开发,最初使用它可能没问题。如果您发现您的应用程序有更多的用户,那么您将希望过渡到 Postgres 或 MySQL。
SQLite 的作者在网站上解决了这个问题:
SQLite 作为大多数中低流量网站(也就是说,大多数网站)的数据库引擎效果很好。SQLite 可以处理的网络流量取决于网站使用其数据库的程度。一般来说,任何每天点击量少于 100K 的网站都可以使用 SQLite。10 万次点击/天的数字是保守估计,而不是硬性上限。SQLite 已被证明可以处理 10 倍的流量。
SQLite 网站(https://www.sqlite.org/)当然使用 SQLite 本身,在撰写本文时(2015 年),它每天处理大约 400K 到 500K 的 HTTP 请求,其中大约 15-20% 是接触数据库的动态页面。动态内容每个网页使用大约 200 个 SQL 语句。此设置在与其他 23 个共享物理服务器的单个 VM 上运行,但在大多数情况下仍将平均负载保持在 0.1 以下。
所以我认为它的长短是,去吧,如果它不适合你,那么过渡到企业级数据库无论如何都是相当微不足道的。但是,请注意您的架构,并在设计数据库时考虑到增长和效率。
这是一个线程,其中包含一些关于将 SQLite 用于生产 Web 应用程序的更多独立评论。听起来它已经被使用了一些混合的结果。
编辑(2014):
自发布此答案以来,SQLite 现在具有多线程模式和预写日志模式,这可能会影响您对其对中低流量站点的适用性的评估。
Charles Leifer 写了一篇关于 SQLite 的 WAL(预写日志)功能的博客文章,以及一些关于适当用例的深思熟虑的意见。
SQLite网站的一小段摘录说明了一切。
数据是否通过网络与应用程序分开?→ 选择 客户端/服务器
许多并发作家?→ 选择客户端/服务器
大数据?→ 选择客户端/服务器
否则→选择SQLite!
SQLite“正常工作”(直到它当然不工作)
我们经常将 SQLite 用于内部数据库;员工目录、我们的事件日历和其他 Intranet 服务都运行在轻量级数据库上。以我们在诸如 mySQL 之类的“真实”数据库上运行的规模运行这些应用程序将是非常过大的。当您考虑到它们在一台中端计算机上与其他 4 个虚拟机一起运行时,尤其如此。
有一次,我们有一个面向外的站点,它在一个 sqlite 数据库上运行了几个月,只需要一次重启。显然,它的流量非常低,但它很好地完成了它的工作。
我们在绝对没有写入的环境中遇到了类似的选项,我们选择使用 SQLite。
请参阅我关于该主题的博客文章:
好吧,使这个解决方案在理论上可行的主要假设是我们的 SQLite 数据库是完全只读的。我们的服务器代码永远不应该改变它。这将解决任何锁定问题,因为没有读锁。我们在互联网上找不到任何人说在没有写入的情况下 SQLite 的高吞吐量读取存在问题 - 有可能!
我认为这主要取决于您的读/写比率。如果它主要是从数据库中读取,你可能没问题。SQLite 中的多用户写入可能是一个问题,因为它如何锁定数据库。
人们谈论并发问题,但 sqlite 有一种方法可以缓存传入的请求并让它们等待一段时间。它不会立即超时。
我已经阅读了有关默认超时设置从零开始的内容,这意味着它会立即超时,这是无稽之谈。也许人们没有调整这个设置?
取决于网站的使用情况。如果大多数时候您只是在读取数据,那么您几乎可以将任何东西用于数据库并将数据缓存在应用程序中以获得良好的性能。
我在一个非常低流量的网络服务器(它是一个基因组数据库)中使用它,我没有任何问题。但是只有 SELECT 语句,没有写入所涉及的数据库。
补充一个已经很出色的答案:由于在这种情况下您使用的是无服务器解决方案,因此您可以告别复制,或任何类型的数据库水平扩展,以及其他高级选项。如果您有多个用户更新相同的确切信息块,这也不是最佳选择。如果将来要对数据库进行分片,则必须迁移数据并转移到其他地方。此外,如果您有一个负载均衡器并涉及多个系统,则使用 sqlite 将难以保持数据中心性。这些只是不推荐它的一些原因。它非常适合小型项目,也非常适合开发。
似乎通过排队,您也可以避免 SQLite 的许多并发写入问题。不是直接写入 sqlite db,而是写入队列,然后依次以先进先出模式顺序写入 sqlite db。不确定您的应用程序是否可以到达您需要它的地方,如果它值得编写或者只是转移到客户端/服务器数据库......但是一个想法。