SQLite 的可伸缩性如何？

小开

Sqlite 是一个桌面或 正在处理中数据库。

对于需要支持对数据存储进行并发写访问的任何应用程序来说，桌面数据库本质上不是一个好的选择。这在某种程度上包括了大多数已经创建的网站。如果您甚至需要为任何事情登录，那么您可能需要对数据库的写访问权限。

小开

就单用户而言，Sqlite 是可伸缩的，我有一个性能非常好的多 GB 的数据库，我在这方面没有遇到太多问题。

但它是是单用户的，所以它取决于您所说的扩展类型。

回应评论。请注意，在多用户环境中使用 Sqlite 数据库没有任何阻碍，但是每个事务(实际上是每个修改数据库的 SQL 语句)都对文件采用锁定，这将阻止其他用户访问数据库 完全没有。

因此，如果对数据库进行了大量修改，就会很快遇到伸缩问题。另一方面，如果与写访问相比，您具有大量的读访问，那么情况可能没有那么糟糕。

但是 Sqlite 当然会在多用户环境中使用功能，但是它不会很好地使用表演。

小开

最佳答案

昨天我发布了一个小站点 ^*来跟踪您的代表，该代表为所有访问者使用了一个共享的 SQLite 数据库。不幸的是，即使它给我的主机带来了适度的负载，它的运行速度还是相当慢。这是因为每次有人查看页面时，整个数据库都被锁定，因为它包含更新/插入。我很快转向了 MySQL，虽然我没有太多时间来测试它，但它似乎比 SQLite 更具可伸缩性。我只记得在 sqlite 中尝试执行 shell 查询时，页面加载速度很慢，偶尔会出现数据库锁定错误。也就是说，我正在使用 SQLite 运行另一个站点。不同之处在于站点是静态的(也就是说，我是唯一一个可以更改数据库的人) ，所以它对于并发读取来说工作得很好。这个故事的寓意是: 只对数据库更新很少的网站使用 SQLite (比加载的每个页面都少)。

Edit : 我刚刚意识到我可能对 SQLite 不公平——当我在网页上为 SQLite 数据库服务时，我没有索引它的任何列。这在一定程度上导致了我正在经历的减速。然而，对数据库锁定的观察-如果您有特别繁重的更新，SQLite 的性能将不能与 MySQL 或 Postgres 相匹配。

另一个编辑: 自从我3个月前发布这篇文章以来，我有机会仔细研究 SQLite 的可伸缩性，通过一些技巧，它可以非常可伸缩。正如我在第一次编辑中所提到的，数据库索引显著地减少了查询时间，但这更多是对数据库的一般观察，而不是对 SQLite 的观察。但是，还可以使用另一个技巧来加速 SQLite: 交易。每当您必须执行多个数据库写操作时，将它们放在一个事务中。不是每次发出写查询时都写入(并锁定)文件，而是只在事务完成时进行一次写入。

我在第一段中提到的我发布的站点已经被切换回 SQLite，并且在我对代码进行了一些调优之后，它运行得非常平稳。

^{* 该网站已不再可用}

小开

这么想吧。每次有人使用 SQLLite 时，它都会被锁定(SQLite 不锁定读取)。因此，如果您提供的网页或应用程序有多个并发用户，只有一个可以使用您的应用程序与 SQLLite 的时间。所以这里存在一个尺度问题。如果它是一个人的应用程序，比如说一个音乐库，你可以在其中保存数百个标题、评分、信息、使用情况、播放时间，那么 SQL Lite 可以很漂亮地保存数千条记录(如果不是数百万条的话)

另一方面，MySQL 适用于服务器应用程序，所有人都将同时使用它。它不会锁，而且尺寸很大。所以对于你的音乐库来说，只有一个人可以看到 MySql，除非这是一个共享的音乐库，成千上万的人可以添加或更新它。然后 MYSQL 将是一个使用。

所以理论上 MySQL 比 Sqlite 扩展得更好，因为它可以处理多个用户，但是对于单个用户应用程序来说有些过头了。

小开

SQLite 的网站(您引用的部分)表明它可以用于各种多用户情况。

我觉得它可以承受很多。根据我的经验，它一直都是非常快的。当然，您需要为表建立索引，并且在根据表编写代码时，您需要确保使用参数化查询等。基本上与使用任何数据库来提高性能相同。

小开

你读过这个 SQLite 文档 -http://www.sqlite.org/whentouse.html吗？

SQLite 通常作为中低级数据库引擎流量网站(也就是说, 99.9% 的网站) 当然，这取决于网站使用其资料库说起来，任何网站，得到较少超过每天10万的点击量应该没问题每天10万的点击量是一个保守的估计，而不是一个硬上限。 SQLite 已经演示了10次那么大的流量。

小开

我认为一个(在数字1)服务数以百计的客户端的网络服务器出现在后端与数据库的单一连接，不是吗？

因此在数据库中没有并发访问，所以我们可以说数据库在“单用户模式”下工作。在这种情况下讨论多用户访问是没有意义的，因此 SQLite 可以像其他任何基于服务器的数据库一样工作。

小开

SQLite 的可伸缩性在很大程度上取决于所使用的数据及其格式。我有一些艰难的经验与额外的长表(GPS 记录，每秒一记录)。经验表明，SQLite 会逐步放慢速度，部分原因是持有索引的不断增长的二叉树的不断重新平衡(并且使用带时间戳的索引，你只需要知道这个树就会得到大量的重新平衡，但它对你的搜索是至关重要的)。因此，最终在大约1GB (我知道大概是1GB)的情况下，查询会变得缓慢。你的情况会有所不同。

有一件事要记住，尽管吹嘘，SQLite 不是为数据仓库而生的。SQLite 有多种用法不推荐。SQLite 背后的精英们自己说:

另一种看待 SQLite 的方式是: SQLite 不是为取代 Oracle 而设计的。它被设计用来替代 fopen ()。

这就引出了主要的争论(不是定量的，抱歉，而是定性的) ，SQLite 并不适用于所有的用途，而 MySQL 可以涵盖许多不同的用途，即使不是理想的用途。例如，您可以使用 MySQL 存储 Firefox cookie (而不是 SQLite) ，但是您需要始终运行该服务。另一方面，您可以在 SQLite 上运行事务性网站(正如许多人所做的那样) ，而不是在 MySQL 上运行，但是预计会有很多停机时间。

小开

SQLite 驱动 SQLite.org 网站和其他流量大的网站。他们建议，如果您每天有不到10万点击量，SQLite 应该可以正常工作。这是在他们发布“ Writeahead 日志记录”功能之前写的。

如果希望使用 SQLite 加快速度，请执行以下操作:

升级到 SQLite 3.7. x
启用预写式日志
运行以下实用程序: “ PRAGMA cache _ size = Number-of-pages;”默认大小(Number-of-page)为2000页，但是如果您提高这个数字，那么您将提高直接运行在内存中的数据量。

你可能想看看我在 YouTube 上的视频“ 利用 Writeahead 日志提高 SQLite 性能”，这个视频展示了如何使用预写式日志，并展示了写作速度提高5倍的效果。