关于可伸缩性：SQLite的可伸缩性如何？

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

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

---

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

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

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

我在第一段中提到的网站已切换回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？

SQLite usually will work great as the
database engine for low to medium
traffic websites (which is to say,
99.9% of all websites). The amount of web traffic that SQLite can handle
depends, of course, on how heavily the
website uses its database. Generally
speaking, any site that gets fewer
than 100K hits/day should work fine
with SQLite. The 100K hits/day figure
is a conservative estimate, not a hard
upper bound. SQLite has been
demonstrated to work with 10 times
that amount of traffic.

---

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

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

Another way to look at SQLite is this: SQLite is not designed to replace Oracle. It is designed to replace 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构建的数据库服务器。

---