SQLite用于网站,但不用于客户端/服务器应用程序?

SQLite可以允许多个客户端读取,但只能允许单个客户端写入。见: https://www.sqlite.org/faq.html

客户机/服务器是指多个客户机同时向数据库写入数据的情况,例如有多个用户同时插入和更新信息的订单条目,或有多个同时编辑的多用户博客。

在只读的情况下,网站不是客户机/服务器,而是一个具有多个请求的服务器。在许多情况下,网站被大量缓存,数据库甚至不被访问,或者很少被访问。

对于一个使用较少的电子商务网站,比如说一些同时购物的用户,这可以由SQLite或MySQL支持。在某些地方,对于高度并发的数据库,性能比SQLite更好。

请注意,产品/页面的数量并不是确定SQLite上对MySQL的需求的好方法,而是确定并发用户的数量,在什么情况下,由于等待锁清除,它们的并发行为会经历缓慢。

用户的web浏览器不能直接访问数据库;web应用程序可以。通常,用户查看的每个页面的请求/响应周期都会非常快,通常会持续几秒钟。

IIRC,SQLite中的一个事务锁定整个数据库文件,这意味着如果一个web应用请求需要一个阻塞事务,那么所有通信量都将被有效地序列化。对于流量从低到中等的网站来说,这很好,因为每秒仍可以处理许多请求。

但是,在客户机-服务器数据库应用程序中,多个用户可能需要将连接保持长时间打开,并且可能还需要执行事务。对于更大的RDBMS系统来说,这远不是一个问题,因为可以以更细粒度的方式执行锁定。

在使用上下文中,网站不一定是客户机-服务器应用程序。

我认为当他们说网站,他们意味着网络应用程序将直接管理数据库。也就是说,数据库文件将位于网站内,不能通过任何其他方式访问。(简单地说,一个单一的接入点)

相反,客户机/服务器应用程序可以让网站访问数据存储 以及 另一个网站,SOAP客户端,甚至是智能客户端。在此上下文中,您有多个客户端访问一个数据库(服务器)。这就是网站将成为(又一个)客户的地方。

在分析这两者时要考虑的另一个方面是写操作与读操作的百分比。我认为,与读的数量相比,当很少有写的时候,SQLite会表现得很好。据我所知,SQLite在多写场景中表现不佳。它是为一个(少数?)操作它的过程。

我主要只在嵌入式应用程序上使用SQLite。(iOS,安卓系统)。对于更大、更复杂的网站(如您所描述的),我会使用类似mySQL的东西。