有/没有服务器的数据库系统中的并发

发布于 2024-12-09 19:07:38 字数 349 浏览 0 评论 0原文

人们通常注意到,没有服务器的简单数据库系统(例如GDBM、SQLite 等)对于并发连接的能力较弱。

  1. 数据库服务器如何处理并发连接以获得更好的并发性?

  2. 我认为在没有服务器的数据库系统中读取并发性更好,因为从平面文件读取数据没有限制。限制应该是可用内存,对吗?

  3. 问题与写入并发有关,因为文件将被锁定。因此,一次只能写入一个。我认为Mysql也是如此(使用MyISAM引擎,因为InnoDB中的锁定仅限于行)。实际中是否存在并发写入?

总体而言,带服务器的数据库系统(例如Mysql)的并发性比不带服务器的系统(例如SQLite)的并发性能如何?

It is usually noted that simple database systems which does not have server (e.g. GDBM, SQLite, etc) are weaker for concurrent connections.

  1. How database server handles concurrent connections to have a better concurrency?

  2. I think read concurrency is better in database systems without server, as there is no limitation for reading data from a flat file. The limitation should be the available memory, am I right?

  3. The problem is about write concurrency, as the file will be locked. Thus, only one write at a time. I think this is also the case for Mysql (with MyISAM engine, as locking in InnoDB is limited to row). Is there concurrent write practically?

Overall, how concurrency of a database system with server (e.g. Mysql) is better than a system without server (e.g. SQLite)?

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

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

发布评论

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

评论(1

不必在意 2024-12-16 19:07:38
  1. 许多数据库服务器支持事务和行级锁定

  2. 无需写入的读取并发性非常容易获得。当更新的时候,让读者更难接受。具有行级锁定的数据库将允许在更新期间无法读取其他行、平面文件和 SQLite 表。

  3. 在许多实际系统中,您将混合进行读取和写入。实践中并发写入?想想 stackoverflow 或任何繁忙的论坛,都会有大量的并发写入。

SQLite 仅支持表级锁定,因此在存在许多并发用户的更新时会非常慢。另一方面,嵌入式数据库几乎是零设置,它们对于单个用户或并发用户数量有限的网络服务器来说非常有用。

我从 Trac 邮件列表中听说,SQLite 后端在大约少数开发人员使用一段时间后才实用。切换到 MySQL 或 Postgres 变得至关重要。

  1. Many database servers support transactions and row level locking

  2. Read concurrency without writes is very easy to obtain. It's more difficult to allow readers when updates are being made. Databases with row level locking will allow that on other rows, flat files and SQLite tables can't be read during updates.

  3. In many real system, you'll have a mix of read and writes. Concurrent writes in practice? Think of stackoverflow or any busy forum, there will be plenty of concurrent write.

SQLite supports only table level locking, thus in presence of updates of a many concurrent users would be very slow. On the other hand embedded databases are almost zero setup and they will do great for single users or also on a webserver with a limited number of concurrent user.

I've heard from the Trac mailing list, that SQLite backend is practical until about a handful of developers, after a switch to MySQL or Postgres becomes essential.

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