SQLite的可伸缩性如何？[关闭]

我最近阅读了有关SQLite与MySQL的问题，答案指出SQLite不能很好地扩展，但是官方网站的分类证实了这一点。

SQLite的可伸缩性如何？最高限制是多少？

昨天我发布了一个小网站^*跟踪对所有访问者使用共享SQLite数据库的代表。不幸的是，即使它在我的主机上承受的负载很小，它的运行速度仍然相当缓慢。这是因为每次有人查看该页面时，整个数据库都被锁定，因为该页面包含更新/插入。我很快就切换到MySQL，虽然我没有太多时间对其进行测试，但它似乎比SQLite更具可伸缩性。我只记得页面加载缓慢，并尝试从sqlite中的Shell执行查询时偶尔会出现数据库锁定错误。也就是说，我可以从SQLite运行另一个站点。区别在于该站点是静态的（即，我是唯一可以更改数据库的站点），因此对于并发读取来说，它工作得很好。故事的道德启示：

编辑：我只是意识到我可能对SQLite不公平-从网页提供服务时，我没有索引SQLite数据库中的任何列。这部分地导致了我遇到的速度下降。但是，观察到数据库锁定的立场-如果您进行的更新特别繁琐，则SQLite的性能将无法与MySQL或Postgres匹敌。

另一个编辑：自从我将近三个月前发布此文章以来，我有机会仔细检查SQLite的可伸缩性，并且通过一些技巧可以使它相当可伸缩。正如我在第一次编辑中提到的那样，数据库索引极大地减少了查询时间，但这更多地是关于数据库的一般观察，而不是关于SQLite的观察。但是，还有另一个技巧可以用来加快SQLite的速度：Transactions。每当您必须进行多次数据库写入时，请将它们放入事务中。而不是每次发出写查询时都写入（并锁定）文件，而是仅在事务完成时才执行一次写操作。

我在第一段中提到的网站已切换回SQLite，并且在一些地方调整了代码后，它的运行非常平稳。

^{*该站点不再可用}

Sqlite在单用户方面具有可伸缩性，我有数千兆字节的数据库，性能非常好，而且我也没有太大的问题。

但是它是单用户的，因此取决于您正在谈论的是哪种扩展。

在回应评论。请注意，没有什么可以阻止在多用户环境中使用Sqlite数据库，但是每个事务（实际上，每个修改数据库的SQL语句）都对该文件进行了锁定，这将阻止其他用户访问位于全部。

因此，如果您对数据库进行了大量修改，那么您实际上将非常迅速地解决扩展问题。另一方面，如果与写访问相比，您具有许多读访问权限，则可能还不错。

但SQLite的当然功能在多用户环境中，但不会执行好。

SQLite驱动sqlite.org网站和其他流量很大的网站。他们建议，如果您每天的点击量少于10万，则SQLite应该可以正常工作。这是在他们提供“ Writeahead日志记录”功能之前编写的。

如果要使用SQLite加快速度，请执行以下操作：

• 升级到SQLite 3.7.x
• 启用预写日志记录
• 运行以下编译指示：“ PRAGMA cache_size =页数；” 默认大小（页数）为2000页，但是如果增加该数目，则将增加直接用尽内存的数据量。

您可能想看一下我在YouTube上的视频“ 使用Writeahead日志记录提高SQLite性能 ”，该视频显示了如何使用预写日志记录，并演示了写入速度提高了5倍。

Sqlite是桌面数据库或进程内数据库。SQL Server，MySQL，Oracle及其兄弟都是服务器。

就需要支持对数据存储的并发写访问的任何应用程序而言，桌面数据库就其本质而言并不是一个好的选择。在某种程度上，这包括曾经创建的大多数网站。如果您什至必须登录，则可能需要对数据库的写权限。

您是否阅读过此SQLite文档-http: //www.sqlite.org/whentouse.html？

对于中低流量的网站（也就是说，所有网站的99.9％），SQLite通常都可以很好地用作数据库引擎。当然，SQLite可以处理的网络流量取决于网站使用其数据库的程度。一般来说，任何每天点击量少于10万的网站都可以在SQLite上正常运行。每天10万次点击是一个保守的估计，而不是一个硬上限。SQLite已被证明可以处理10倍的流量。

SQLite的可伸缩性将高度取决于所使用的数据及其格式。我在使用超长桌（GPS记录，每秒一条记录）方面有一些艰难的经验。经验表明，SQLite会分阶段降低速度，部分原因是不断增长的拥有索引的二叉树的重新平衡（以及带有时间戳的索引，您只知道树将得到大量的重新平衡，但这对您至关重要）搜索）。因此，最终只有大约1GB（据我所知），查询的速度变慢了。您的里程会有所不同。

要记住的一件事是，尽管吹牛，但SQLite并不是用于数据仓库的。不建议将各种用途用于SQLite。SQLite背后的好人自己说：

查看SQLite的另一种方法是：SQLite并非旨在取代Oracle。它旨在替代fopen（）。

这就引出了一个主要论点（不是定量的，对不起的，而是定性的），SQLite并不能用于所有用途，而MySQL可以涵盖许多不同的用途，即使不是理想的情况。例如，您可以让MySQL存储Firefox cookie（而不是SQLite），但是您需要一直运行该服务。另一方面，您可能有一个在SQLite上运行事务性网站（就像许多人一样）而不是MySQL，但是却会导致大量停机。

我认为一个（数量为1的）服务于客户端的网络服务器会在后端与数据库建立单一连接，不是吗？

因此，数据库中没有并发访问权限，因此可以说数据库正在“单用户模式”下工作。在这种情况下，对磁盘进行多用户访问是没有意义的，因此SQLite可以与任何其他基于服务器的数据库一起工作。

这样想吧。每当有人使用SQL Lite时，它将被锁定（SQLite不会在读取时锁定）。因此，如果您为网页或具有多个并发用户的应用程序提供服务，则只有一个人可以通过SQLLite一次使用您的应用程序。因此，存在扩展问题。如果它的一个人应用程序说一个音乐库，其中包含数百个标题，等级，信息，用法，播放，播放时间，则SQL Lite可以很好地扩展，可以容纳数千个甚至数百万个记录（硬盘愿意）

另一方面，MySQL非常适合服务器应用程序，在这些应用程序中，人们将同时使用它。它不会锁定，而且尺寸很大。因此，对于您的音乐库MySql来说，就像只有一个人看到的那样，它会被杀死，除非这是一个共享的音乐库，成千上万的音乐库会在其中添加或更新。然后，MYSQL将成为使用的那个。

因此，从理论上讲，MySQL的扩展性比Sqllite好，因为它可以处理多个用户，但是对于单个用户的应用程序而言却过于矫kill过正。

SQLite的网站（您所引用的部分）表明它可以用于多种多用户情况。

我会说它可以处理很多。以我的经验，它一直非常快。当然，您需要为表建立索引，并且在对表进行编码时，需要确保使用准参数化查询等。基本上，您可以使用任何数据库来提高性能。

值得一试的是REAL SQL Server，这是一个基于SQLite构建的数据库服务器。