使用 SQLite 作为生产数据库，这是个坏主意，但是答案

【问题标题】：Using SQLite as production database, bad idea but使用 SQLite 作为生产数据库，这是个坏主意，但是
【发布时间】：2011-08-31 03:25:27
【问题描述】：

我们目前正在使用 postgresql 作为我们在 rails 中的生产数据库，这是一个很棒的数据库，但我正在围绕 SQLite 构建我们应用程序的新版本。事实上，我们不使用 postgres 的高级功能，如全文搜索或 PL/SQL。考虑到 SQLite，我喜欢仅使用一个文件移动数据库的想法，它在服务器和 Rails 中的简单集成，性能似乎非常好 -> Benchmark

我们的应用程序的流量相对较高，每天大约有 120 万次观看。因此，我们从数据库中读取大量数据，但写入少量数据。

你怎么看？任何使用或尝试（如我们）将 SQLite 用作生产数据库的人的反馈？

【问题讨论】：

SQLite 支持全文搜索...
是的，但它不如 postgres'one 强大。无论如何，我们不使用全文。

标签： ruby-on-rails database sqlite production-environment

【解决方案1】：

如果您进行大量读取和少量写入，则将 SQLite 与某种内存缓存机制结合起来（memcache 或 redis 非常适合此）。这将有助于最大限度地减少对数据库的访问（读取）次数。这种方法有助于任何多读少写的环境，并且有助于避免 SQLite 的缺陷 - 在您的特定情况下。

【讨论】：

您已经将该架构投入生产了吗？如果是这样，那是什么样的体验？

【解决方案2】：

SQLite 专为嵌入式系统而设计。它适用于单个用户，但不能很好地处理并发请求。每天 120 万次观看可能意味着您将获得大量后者。

【讨论】：

SQLite 文档有一整页的文档讨论了这个问题以及他们如何尝试在版本 3 中修复它：sqlite.org/lockingv3.html
我同意，但这只是关于写而不是读。如果你使用异步写入或内存缓存机制之类的东西，你会失去数据完整性，但它会快得多。

【解决方案3】：

对于只进行读取，我认为理论上它可以比进程外数据库服务器更快，因为您不必将数据序列化到内存或网络流中，所有这些都是在进程内访问的。在实践中，RDBMS 可能会更快；例如，MySQL 具有非常好的查询缓存功能，并且对于某些可能会有所改进的查询，因为您的所有 Rails 进程都将使用相同的缓存。使用 sqllite 他们不会共享缓存。

【讨论】：