SQLite的可扩展性如何？

我最近阅读了关于SQLite vs MySQL的这个问题,答案指出SQLite不能很好地扩展,官方网站排序也证实了这一点.

SQLite的可扩展性如何？它的最大限制是什么？

1> Kyle Cronin..：

---

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

编辑:我刚刚意识到我可能对SQLite不公平 - 当我从网页上提供它时,我没有索引SQLite数据库中的任何列.这部分导致了我所经历的放缓.但是,观察数据库锁定站 - 如果你有特别繁重的更新,SQLite性能将无法匹配MySQL或Postgres.

另一个编辑:自从我差不多3个月前发布这篇文章以来,我有机会仔细研究SQLite的可扩展性,并且通过一些技巧可以实现可扩展性.正如我在第一次编辑中提到的,数据库索引大大减少了查询时间,但这更像是对数据库的一般观察,而不是SQLite.但是,您可以使用另一个技巧来加速SQLite:事务.每当您必须执行多个数据库写入时,请将它们放在事务中.每次发出写入查询时,写入只会在事务完成时发生一次,而不是写入(并锁定)文件.

我在第一段中提到的网站已经切换回SQLite,一旦我在几个地方调整了代码,它运行得非常顺利.

^{*该网站不再可用}

---

@porneL:是的,但是没有索引的SQLite比没有索引的MySQL慢一个数量级,我还在第二次编辑中包含了一些关于事务的内容.我仍然认为答案的进展是有道理的 - 它显示了我最初对SQLite的天真使用以及性能相对差.我希望平台的新手会遇到类似的问题,我希望他们能够识别第一段,然后阅读以下编辑,并意识到有一些方法可以加快SQLite的性能.

---

MySQL的"经典"数据库引擎MyISAM在与SQLite的并发读/写操作方面存在同样的问题.实际上,它会锁定在写入操作中触及的每一​​行,从而无法扩展写入密集型应用程序.尽管如此,它还是很好地为许多Web应用程序服

---

在较新的SQLite版本中还提供了预写日志记录(WAL),这可能会消除一些读/写周期的痛苦.事情会改变的.

2> angry person..：

---

Sqlite在单用户方面是可扩展的,我有几千兆字节的数据库,表现非常好,我没有遇到太多问题.

但它是单用户,所以它取决于你所谈论的缩放比例.

回应评论.请注意,没有什么阻止了利用多用户环境中的SQLite数据库,但每一笔交易(实际上,修改数据库的每个SQL语句)上就是一个锁文件,这将阻止其他用户访问数据库的所有.

因此,如果您对数据库进行了大量修改,那么您实际上将非常快速地解决扩展问题.另一方面,如果与写访问相比,您有很多读访问权限,那么它可能不会那么糟糕.

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

---

SQLite 3支持在其他用户写入时进行读取.

---

请注意，以上注释已过时，对于新的WAL系统，可以同时执行写入和读取操作，从而提高了可伸缩性。

3> Jay Godse..：

---

SQLite驱动sqlite.org网站和其他拥有大量流量的网站.他们建议,如果你每天点击次数少于10万,那么SQLite应该可以正常工作.这是在他们发布"Writeahead Logging"功能之前编写的.

如果您想使用SQLite加快速度,请执行以下操作:

升级到SQLite 3.7.x.

启用预写日志记录

运行以下编译指示:"PRAGMA cache_size = Number-of-pages;" 默认大小(页数)是2000页,但如果你提高了这个数字,那么你将提高直接从内存中运行的数据量.

您可能需要查看我在YouTube上的视频" 使用Writeahead日志记录提高SQLite性能 ",该视频演示了如何使用预写日志记录并演示写入速度提高了5倍.

4> Joel Coehoor..：

---

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

对于需要支持对数据存储的并发写访问的任何应用程序而言,桌面数据库本质上不是一个好的选择.这包括在某种程度上创建的大多数网站.如果您甚至需要登录任何内容,您可能需要对数据库的写访问权限.

---

我不同意"这包括几乎每个创建过的网站." 评论.如果网站负载很高,那你就是对的.例如,Trac默认使用SQLite,对于小型团队来说,它的开箱即用性非常好.

---

@正义.这个答案没有关于SQLite可扩展性的支持证据.没有人的答案要好得多.

---

你怎么定义为扼流圈？从你的回复我猜你没有太多的SQLite经验.SQLite会将整个文件锁定在操作上,因此您可能会遇到延迟,但在您提议的情况下几乎不可能让它"窒息".

---

安德鲁,因为SQL Lite适用于小型团队,不能使其可扩展,因此可扩展性要求很好地扩展,这意味着它应该与大型团队一起运行良好.据我所知,SQL Lite无法扩展到超过相当低阈值的大型团队/并发数据库操作.

---

给它一点时间：您将让两个开发人员同时访问同一字段，这将使您感到窒息。

5> Sam..：

---

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

SQLite通常可以作为中低流量网站的数据库引擎(也就是所有网站的99.9%).当然,SQLite可以处理的Web流量大小取决于网站使用其数据库的程度.一般来说,每天点击次数少于100K的网站应该可以正常使用SQLite.100K点击/天的数字是一个保守估计,而不是一个硬上限.SQLite已被证明可以使用10倍的流量.

---

"100k点击/天"的指标完全是垃圾."点击"通常被定义为HTTP GET,带有一堆切片图像的网站每页浏览可能会获得40多次"点击" - 没有一个触及数据库.即使文档犯了hit == pageview的错误,它仍然会产生误导.SQLite在写入时锁定整个DB.虽然它可能有价值地提供仅浏览记录的人的100k页面浏览量,但它会在写密集型应用程序(电子商务,留言板等)中崩溃.

---

我非常同意这一点.如果您愿意,可以使用SQLLite处理99%的网站.但是,另一方面,99%的网络流量占最大的1%的网站.

6> MPelletier..：

---

SQLite可伸缩性将高度依赖于所使用的数据及其格式.我对超长桌子(GPS记录,每秒一个记录)有一些艰难的经历.经验表明,SQLite会逐步减速,部分原因是持续重新平衡不断增长的持有索引的二叉树(以及带时间戳的索引,你只知道树会重新平衡很多,但它对你来说至关重要)搜索).所以最终大约1GB(非常棒球,我知道),在我的情况下,查询变得迟钝.你的里程会有所不同.

有一点要记住,尽管吹牛,但SQLite并不是为了数据仓库.SQLite 不建议使用各种用途.SQLite背后的好人自己说:

另一种看待SQLite的方法是:SQLite不是为了取代Oracle而设计的.它旨在取代fopen().

这导致了主要论点(不是定量的,抱歉的,而是定性的),SQLite并非适用于所有用途,而MySQL可以涵盖许多不同的用途,即使不理想.例如,您可以让MySQL存储Firefox cookie(而不是SQLite),但您需要始终运行该服务.另一方面,您可以在SQLite上运行一个事务性网站(与许多人一样)而不是MySQL,但预计会有很多停机时间.