内部使用网站:是否有令人信服的理由反对SQLite？

Question

许多web框架(如烧瓶或姜戈 )都使用SQLite作为它们的默认数据库。SQLite之所以引人注目，是因为它包含在python中，而且管理开销非常低。

然而，大多数高流量的公共生产站点最终使用的是一个较重的数据库: mySQL、Oracle或postgresql。

问题如下：

假设：

• 站点流量适中，将发生对数据库的并发读/写访问。
• 我们将SQLAlchemy和SQLite写锁一起使用(尽管这句话让我有点紧张)
• 数据库将包含大约60,000条记录。
• 数据结构不需要在较重的数据库中找到的高级功能。

对于作为中等流量内部企业工具的网站来说，是否有令人信服的理由反对SQLite并发？如果是的话，什么条件会导致SQLite出现并发问题？

我正在寻找已知的具体根源，而不是一般的恐惧/毫无根据的指责。

Answer 1

我建议您阅读您的问题的正式答案，SQLite的适当用途。具体来说，“另一个关系数据库管理系统可能工作得更好的情况”警告说，SQLite不支持并发写入：

SQLite支持无限数量的同时读取器，但它只允许一个作者在任何时候。在许多情况下，这不是一个问题。每个应用程序都能快速地运行数据库并继续工作，并且锁的持续时间不会超过几十毫秒。但是有些应用程序需要更多的并发性，而这些应用程序可能需要寻求不同的解决方案。

从适当的角度来看，我倾向于将SQLite视为一种支持SQL查询的非常复杂的文件格式。如果我想将我的数据库与我的web应用程序分开，我倾向于避免使用SQLite，因为它不是针对这种情况进行优化的。简而言之，在某些情况下，SQLite的可伸缩性不够强，所以那些运行网站的人，如果希望有一天变得流行起来，最好从可伸缩的东西开始，而不是使用SQLite，然后被迫进行切换。

尽管如此，对于大多数内部网站来说，SQLite可能是好的；通常，内部网站不需要相同级别的并发性和可伸缩性。

Answer 2

戴上我的IT总监帽子，我在这里看到了几个无名小卒：

• 数据损坏的风险。也许比真实更残忍，但最终这是一个非事务性文件类型DB，除了询问您是否有最近的备份之外，如果有任何错误的写操作，它也没有什么用处。说到这点。。。
• 我怎么才能支持这件事？在某种程度上，我知道我有一份很好的副本。最好不要让应用程序离线。
• 如何确保对数据库的访问？我的一般理解是，SQL在文件系统访问之外没有任何东西，这是一个不错的开始，但不是所有的，结束的。特别是对于web应用程序，您可能需要更多的分级权限，而不是DBA或任何东西。

从开发人员的角度来看，我认为重要的是要知道为什么SqlLite是默认的--这是因为它很简单，而且演示得很好。如果你是在向新开发人员“销售”一个平台，那么关键是你能够用最少的小题大做来启动一个可以工作的web应用程序。必须站起来正确地配置数据库服务器将是一个巨大的绊脚石，需要避免。