SQLite 作为低流量站点的生产数据库
我正在考虑使用 SQLite 作为一个网站的生产数据库，该网站可能会同时接收 20 个用户，但峰值的潜力可能是其数倍（因为该网站可以在开放的 Internet 上访问，并且总是有一个有人可能会在某个地方发布一个链接，从而吸引很多人同时访问该网站）。
SQLite 有可能吗？
我知道这不是一个理想的生产场景。 我只是想问这是否有可能实现。
I'm considering using SQLite as a production database for a site that would receive perhaps 20 simultaneous users, but with the potential for a peak that could be many multiples of that (since the site would be accessible on the open Internet and there's always a possibility that someone will post a link somewhere that could drive many people to the site all at once).
Is SQLite a possibility?
I know it's not an ideal production scenario. I'm only asking if this is within the realm of being a realistic possibility.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
为了补充一个已经很出色的答案：由于在这种情况下您正在使用无服务器解决方案，因此您可以告别复制或数据库的任何类型的水平扩展以及其他高级选项。
如果您有多个用户更新相同的信息块，那么它也不是最佳选择。 如果将来要对数据库进行分片，则必须迁移数据并转移到其他地方。
此外，如果您有一个负载均衡器并且涉及多个系统，那么使用 SQLite 就很难维护数据中心性。
这些只是不推荐的一些原因。 它非常适合小型项目，也非常适合开发。
To add to an already brilliant answer: Since you are working with a server-less solution in this case, you can say goodbye to replication, or any sort of horizontal scaling of your db, as well as other advanced options.
It also isn't the best choice if you have multiple users updating the same exact chunk of information. If you were to shard the database in the future, you would have to migrate the data and move to something else.
Also if you have a load balancer and multiple systems involved it would be difficult to maintain data centrality if using SQLite.
These are just some of the reasons why it isn't recommended. Its great for smaller projects, and great for development.
看起来，通过队列，您还可以避免 SQLite 的许多并发写入问题。 您不是直接写入 SQLite 数据库，而是写入队列，然后队列以先进先出模式依次写入 SQLite 数据库。
我不确定您的应用程序是否达到了您需要的位置，是否值得编写或只是转移到客户端/服务器数据库......但这是一个想法。
It seems like with queuing you could also get away with avoiding a lot of the concurrency write problems with SQLite. Instead of writing directly to the SQLite database, you would write to a queue that then in turn sequentially writes to the SQLite database in a first in first out mode.
I am not sure if your application reaches to where you would need this if it would be worth writing or just moving on to client/server database...but it is a thought.
无论如何，继续针对 SQLite 进行开发，并且您最初可能可以很好地使用它。 如果您发现您的应用程序有更多用户，您将需要转换到 PostgreSQL 或 MySQL。
SQLite 的作者在网站上解决了这个问题：
所以我认为总而言之，就去做吧，如果它对你来说效果不佳，那么过渡到企业级数据库无论如何都是相当微不足道的。 但是，请务必注意您的架构，并在设计数据库时考虑到增长和效率。
这是一个线程，其中包含一些关于将 SQLite 用于生产 Web 应用程序的更独立的评论。 听起来它的使用效果好坏参半。
自从这个答案发布以来，SQLite 现在具有 多线程模式 和 预写日志模式 这可能会影响您对其是否适合中低流量网站的评估。
Charles Leifer 撰写了一篇博文，内容涉及SQLite 的 WAL（预写日志记录）功能以及一些关于适当用例的深思熟虑的意见。
By all means, continue to develop against SQLite, and you're probably fine to use it initially. If you find your application has more users down the track, you're going to want to transition to PostgreSQL or MySQL however.
The author of SQLite addresses this on the website:
So I think the long and short of it is, go for it, and if it's not working well for you, making the transition to an enterprise-class database is fairly trivial anyway. Do take care of your schema, however, and design your database with growth and efficiency in mind.
Here's a thread with some more independent comments around using SQLite for a production web application. It sounds like it has been used with some mixed results.
Since this answer was posted, SQLite now features a multi-threaded mode and write ahead logging mode which may influence your evaluation of its suitability for low-medium traffic sites.
Charles Leifer has written a blog post about SQLite's WAL (write ahead logging) feature and some well-considered opinions on appropriate use cases.
SQLite 网站 的小摘录说明了一切。
SQLite“正常工作”（当然，直到它不起作用）。
The small excerpt from the SQLite website says it all.
SQLite "just works" (until it doesn't of course).
我们经常使用 SQLite 作为内部数据库：员工目录、事件日历和其他 Intranet 服务都在轻量级数据库上运行。 以我们在“真实”数据库（如MySQL<）上运行的规模运行这些应用程序将是一个重大的矫枉过正。 /a>. 当您考虑到它们在一台中型计算机上与其他四个虚拟机一起运行时尤其如此。
曾经，我们有一个面向外部的站点，它在 SQLite 数据库上运行了数月，只需要重新启动一次。 显然，它的流量非常低，但它的表现却很好。
We often use SQLite for internal databases: The employee directory, our calendar of events, and other intranet services all run on lightweight databases. It would be major overkill to be running these applications at the scale we do on a "real" database like MySQL. This is especially true when you factor in that they're running alongside four other virtual machines on a single mid-range computer.
At one point we had an outward facing site that ran on an SQLite database for months with only a single reboot required. Obviously, it was very low traffic, but it put along nicely for what it did.
我们在绝对没有写入的环境中遇到了类似的选项，并且我们选择使用 SQLite。
请参阅我关于该主题的博客文章：
We have encountered a similar option on an environment with absolutely no writes, and we selected using SQLite.
See my blog post on the subject:
我认为这主要取决于您的读/写比率。 如果主要是从数据库中读取，那么可能没问题。 由于 SQLite 锁定数据库的方式，多用户写入可能会成为一个问题。
I think it would depend mostly on what your read/write ratio will be. If it's mostly reading from the database, you may be okay. Multi-user writing in SQLite can be a problem because of how it locks the database.
人们谈论并发问题，但 SQLite 有一种方法可以缓存传入的请求并让它们等待一段时间。 它不会立即超时。
我读过有关默认超时设置从零开始的内容，这意味着它会立即超时，这是无稽之谈。 也许人们没有调整这个设置？
People speak about concurrency problems, but SQLite has a way to cache incoming requests and have them wait for some time. It doesn't time out immediately.
I've read things about the default timeout setting beginning at zero, meaning it times out immediately and that's nonsense. Maybe people didn't adjust this setting?
我在一个流量非常低的网络服务器（它是一个基因组数据库）中使用它，并且没有任何问题。 但只有 SELECT 语句，不涉及写入数据库。
I am using it in a very low traffic web server (it is a genomic database) and I don't have any problems. But there are only SELECT statements, no writing to the DB involved.
这取决于网站的使用情况。 如果大多数时候您只是读取数据，那么您几乎可以使用任何数据库并将数据缓存在应用程序中以获得良好的性能。
It depends on the usage of the site. If most of the time you're just reading data, you can pretty much use anything for a DB and cache the data in the application to achieve good performance.