对不起这个问题，我不知道我是否理解这个概念，但是SQLite是无服务器的，这意味着数据库在本地机器中，并且它存储在一个文件中，这个文件只能在一种模式下访问：如果一个客户端读取它，它仅用于其他客户端的读取模式，并且如果客户端写入，则所有客户端都具有写入模式，因此一次只能在一种模式下！ 所以想象一下，我做了一个django应用程序，例如博客;那怎么用sqlite做的呢？因为如果客户进入博客，他会在阅读模式下查看页面和博客条目，如果注册客户端尝试添加评论，那么该文件将被设置为写入模式，那么sqlite如何处理这个？ 那么，SQLite是否就像BaseHTTPServer（django附带的服务器）一样，用于测试和学习目的？
答案 0 :(得分：35)
不同的数据库以不同的方式管理并发，但在sqlite中，使用的方法是全局数据库级锁。只有一个线程或进程可以一次更改sqlite数据库;所有其他并发进程将被迫等待当前正在运行的进程完成。
随着您的用户数量的增长; sqlite的简单锁定策略将导致越来越大的锁争用，并且您需要将数据迁移到另一个数据库，例如MySQL（可以进行行级锁定，至少使用InnoDB引擎）或PostgreSQL（使用多版本并发控制） 。如果您预计将获得大量用户（在某一天的大部分时间内，每秒超过1个请求），您应该从sqlite迁移;越早你这样做就越容易。
答案 1 :(得分：7)
数据库理论中的这个问题称为并发，SQLite在Windows版本中支持它＆gt;根据常见问题解答Win98和其他地方：
http://www.sqlite.org/faq.html#q5
我们知道没有其他支持as的嵌入式SQL数据库引擎 和SQLite一样多并发。 SQLite允许多个进程拥有 数据库文件立即打开，并为多个进程读取 数据库一下子。当任何进程想要写入时，它必须锁定 整个数据库文件的更新期间。但通常情况下 只需几毫秒。其他进程只是等待作者 完成然后继续他们的业务。其他嵌入式SQL 数据库引擎通常只允许单个进程连接 数据库一下子。
基本上，不要担心并发性，任何值得盐的数据库都可以正常使用。有关SQLite3如何管理此问题的更多信息，请参见here。作为开发人员，您不是数据库设计师，除非您对内部工作感兴趣，否则无需关心它。
答案 2 :(得分：7)
SQLite 不像BaseHTTPServer或类似的任何基本内容。它是一个功能齐全的嵌入式数据库。非常快。它的SQL语言可能没有最多的花里胡哨，但它足够灵活。我还没遇到过我需要为我参与的项目做不了的事情（这不是你典型的网络应用程序，事实上要讲真相）。
任何声称SQLite在不讨论实际设计的情况下生产好坏的人并没有告诉你多少。 SQLite非常快。在某些情况下，字面数量级比Postgres更快，后者在Djangonauts中成为替代品。正如有人指出的那样，它也支持大量的并发性。这是一个问题，你的应用程序是否属于某些情况＆＃39;或不。
现在，有一个重要因素需要考虑。 SQLite是一个进程内数据库。这非常重要。如果您使用gevent之类的东西，则可能会遇到应用程序中断的边缘情况。例如，尝试进行一个事务，在其中间有一个上下文切换可能会以可怕的方式破坏事务。换句话说，＆＃39;并发＆＃39;这取决于您的应用，因为SQLite是您应用的部分。
你可以用SQLite做什么，但就扩展而言，你可以像使用其他一些数据库引擎一样制作SQLite服务器集群，因为它可以进程。你的应用程序在缩放方面可能需要或可能不需要这么长，但我的猜测是绝大多数的应用程序都没有（无论如何）。（猜测）。
另一方面，正在进行中意味着添加自定义函数和聚合对它来说非常简单。我不确定Django的ORM是否会让它变得更难，但是你可以利用这些功能提出相当不错的设计。
答案 3 :(得分：1)
该晚了，但到2018年年中，这个问题仍然不明确。
博客站点的“客户端”是与“数据库客户端”不同的术语。 SQLite文档将客户端称为打开数据库文件的过程。 django应用程序这样的过程可以同时处理许多Web应用程序客户端（“用户”），并且从SQLiite的角度来看，它仍将仅仅是一个客户端。
在适当的RDBMS上选择SQLite的重要考虑因素是您的体系结构是否包含多个连接到数据库的软件组件。在这种情况下，由于每个应用程序都可能需要通过网络访问同一数据库文件，因此使用SQLite可能是主要的性能瓶颈。
如果不是多个应用程序（数据库客户端），则在99％的情况下，SQLite都是不错的生产选择。剩下的1％是使用特定数据库功能的应用程序，承受巨大负载的应用程序等。
了解您的架构。
答案 4 :(得分：1)
在生产环境中使用带有Sqlite的Django作为数据库并不是不可能的，主要取决于您的网站/ webapp流量以及您对数据库的打击程度（以及对数据库执行的哪种操作，即读/写/等）。实际上，到2019年底，我已经在一些每日交互少于5k的小批量应用中使用了它们（这些交互比您想象的要普遍得多）。
简单地说明当前的技术状态，目前Sqlite-3支持无限的并发读取（或就您的机器/工人可以处理的范围而言），但在任何时间点，只有一个单个 进程可以对其进行写入。请记住，精心设计的查询/数据库操作仅会持续数毫秒！
基于使用sqlite作为简单非常规数据库的唯一数据库（非常规，我的意思是典型用户全年不会每天使用此应用）来进行海外工作匹配的经验可以应付约5000名注册学生（统计数据显示，每天持续少于2k的请求涉及在高峰季节访问数据库-40％的写入60％的读取），对于超时/性能问题，我没有任何问题。
这实际上归结为对开发和URS（客户规范）务实。如果它成为下一个独角兽，则可以随时将SQLITE迁移到另一个RDBMS。例如，请参见Quick easy way to migrate SQLite3 to MySQL?
中的David d C e Freitas对迁移的看法。另外，SQLITE网站在其后端使用sqlite db ..参见下文...
SQLite网站（https://www.sqlite.org/）使用SQLite本身，当然，在撰写本文时（2015年），它每天处理约40万至500K HTTP请求，其中约15-20％是动态页面数据库。每个网页的动态内容使用大约200条SQL语句。此设置在单个VM上运行，该VM与23个虚拟机共享一台物理服务器，但大多数情况下仍将平均负载保持在0.1以下。
请记住，以上引用当然主要是指读操作，因此这些值可能不适用于写繁重的站点。
我在上面使用sqlite作为db构建的求职应用程序中给出的示例写得很繁琐，如果您注意到这些数字……平均而言，40％是短暂的写操作（即表单提交等） ），但请记住，在高峰季节，我达到数据库的音量每天只有2k。
然后再次，如果您意识到sqlite.db导致大量超时和糟糕的用户体验（在表单提交时出现408 !!!），尤其是在Django抛出 OperationalError：数据库锁定错误时（然后他们必须再次输入整个内容）...在准备迁移数据库时，始终可以按照django docs的方法在settings.py中增加超时，这是一个临时解决方案。
'OPTIONS': {
# ...
'timeout': 20,
# ...
}
同样，这全都归结为务实的发展和面对现实，即该站点可能没有吸引到太多的活动，并且一开始就容易过度设计。
很多时候，寻求一个简单的解决方案可以更快地将产品推向市场，从而快速地测试水域，当然，要做好食人鱼的准备，然后有时间升级到另一个RDBMS。
使用Django的ORM，在大多数情况下，在迁移到其他受支持的sql db期间，您无需触摸models.py。 保持 非常 mindfull ，尽管Sqlite不支持某些更高级的功能，甚至不支持其更大的表亲MYSQL和POSTGRES支持的字段。
答案 5 :(得分：0)
SQLite并不适合生产。即使在Windows上也可以很容易地启动和运行MySQL或PostgreSQL，并拥有真正的数据库。
真正的问题是SQLite3没有在Django中进行线程化，所以在您的服务器上一次只能发生一个PAGE视图，请参阅此错误https://code.djangoproject.com/ticket/12118
即使在开发过程中我也不使用SQLite3。