SQLite 还是 MySQL 适合以阅读为主的网站?

发布于 2024-10-01 13:21:34 字数 423 浏览 4 评论 0原文

对于每月有 300,000 名独立访问者的网站,使用 SQLite 作为数据库后端是否实用?

对数据库的写入将非常有限 - 用户注册或登录、添加评论等。绝大多数使用只是根据 URL 中的主键获取内容的查询。我想知道 SQLite 是否可以作为网站后端,并且不会比 MySQL 慢得多。

我见过 this SO question 和其他问题,但它们并不完全相同,而且看起来像是现在也可能已经过时了。 http://www.sqlite.org/whentouse.html 建议没问题,但他们可能有点偏见!

Is it practical to use SQLite as the database backend for a website with, say, 300,000 unique visitors a month ?

Writes to the database will be pretty limited - user signing up or logging in, adding comments etc. The vast majority of the use will just be queries getting content based on a primary key in the URL. I'd like to know if SQLite can cope as a website backend and won't end up dramatically slower then MySQL.

I've seen this SO question and others, but they're not really the same and seem like they could be out-of-date now too. http://www.sqlite.org/whentouse.html suggests it'd be fine, but they might be a bit biased!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

听风吹 2024-10-08 13:21:34

SQLite 是一个非常酷的产品 - 随着 HTML5 的出现,对于任何 Web 开发人员来说,熟悉它都是一个好主意。但是您应该记住 sqlite 的扩展性不好。如果您需要在多个网络服务器之间共享数据,那么使用 sqlite 作为数据基础将会非常困难。

然而,为了简化开发,您可以查看 PHP 中的 PDO / dbx_,它提供了一个抽象层(即相同的代码与各种数据库进行对话),但是不同系统实现事务(例如事务)的方式之间存在一些细微的差异 - 以及SQL - 如果您确实走这条路,我建议在 PHP PDO/DBX 调用和您的应用程序之间维护您自己的抽象层 - 想想用 PHP 实现的存储过程。

每月 300,000 名独立访客?

啊啊啊啊啊!宠物讨厌。虽然您需要考虑您的站点将赚多少钱来规划预算,但这对于容量规划来说并不是一个有用的指标。您确实想查看预期的点击率/页数。

SQLite is a very cool product - and with HTML5 on the horizon, it's a good idea for any web developer to get acquainted with it. However you should bear in mind that sqlite does not scale well. If you ever need to share data across multiple webservers, it's going to be very difficult using sqlite as the data-substrate.

However to ease the development, you could look at PDO / dbx_ in PHP which provides an abstraction layer (i.e. same code talks to all sorts of databases) however there are some subtle variations between the way different systems implement stuff like transactions - and variations in SQL - if you do go down this route, I'd recommend maintaining your own abstraction layer between the PHP PDO/DBX calls and your application - think stored procedures implemented in PHP.

300,000 unique visitors a month ?

aaaarrrgghhhh! pet hate. While you need to think about how much money your site will be making in order to plan a budget, this is not a useful metric for capacity planning. Really you want to look at expected hit/page rates.

情话难免假 2024-10-08 13:21:34

我想你会没事的。 Sqlite 能够很好地支持多线程,并且由于您主要是从中读取内容,所以应该不会有问题。此外,如果您正在写入它,它也完全支持事务。但你必须记住,它仍然只是一个文件并且没有服务 - 所以如果你打算对它进行集群,你将不走运。也许你应该检查一下mysql到底有什么问题并解决它们。

I think you would be fine. Sqlite is able to support multi-threading just fine, and as you are mostly reading from it, there shouldn't be a problem. Also, if you are writing to it, it fully supports transactions as well. You have to remember though that it's still just one file and no service - so if you are going to cluster it you will be out of luck. Maybe you should check what problems exactly you have with mysql and solve them.

老旧海报 2024-10-08 13:21:34

sqlite 速度非常快,但是一旦需要集群就变得很难使用。然而,一旦需要集群,几乎所有数据库都会变得困难。如果您是以阅读为导向的,那么您使用哪一种应该不会太重要。只要确保您使用的是 memcached 即可。

sqlite is very fast, but it becomes difficult to use once you need to cluster. However pretty much all databases are difficult once you need to cluster. If you are read oriented, it shouldn't matter too much which you use. Just make sure you are using memcached.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文