algorithm - 随机更新磁盘是否在标准和仅附加数据库中受限？

Question

如果我有大型数据集并进行随机更新，那么我认为更新主要受磁盘限制(如果仅附加数据库，我认为与搜索无关，而与带宽有关)。当我稍微更新记录时，必须更新一个数据页，所以如果我的磁盘可以写入 10MB/s 的数据并且页面大小为 16KB，那么我每秒最多可以进行 640 次随机更新。仅附加数据库每秒约 320，因为一次更新可能占用两页 - 索引和数据。在其他数据库中，由于 ranom 试图就地更新页面可能更糟，例如每秒 100 次更新。

我假设缓存中的一页在写入前只有一次更新(随机更新)。在所有数据页周围随机插入(例如，不是按时间排序的 UUID)或什至更糟。

我指的是脏页(更新后)必须刷新到磁盘并同步(不能再留在缓存中)的情况。那么每秒更新计数在这种情况下磁盘带宽是否有限？我的计算可能是每秒 320 次更新吗？也许我遗漏了什么？

Answer 1

“这取决于。”

为了完整起见，还有其他事情需要考虑。

首先，随机更新与追加的唯一区别是涉及的寻头。随机更新会使整个盘子的头部都在跳舞，而理想情况下，追加只会像电唱机一样进行跟踪。这还假设每个磁盘写入都是完整写入并且完全独立于所有其他写入。

当然，那是在一个完美的世界里。

对于大多数现代数据库，每次更新通常至少涉及 2 次写入。一个用于实际数据，另一个用于日志。

在典型情况下，如果您更新一行，数据库将在内存中进行更改。如果您提交该行，数据库将通过在日志中做一个注释来确认这一点，同时将实际的脏页保留在内存中。稍后，当数据库检查点时，它会将脏页正确写入磁盘。但是当它这样做时，它会对 block 进行排序并尽可能按顺序写入它们。然后它将一个检查点写入日志。

在恢复期间，当数据库崩溃并且无法检查点时，数据库读取日志直到最后一个检查点，“前滚”并将这些更改应用到实际磁盘页面，标记最终检查点，然后使系统可用于服务。

日志写入是顺序的，数据写入大多是顺序的。

现在，如果日志是普通文件的一部分(今天很典型)，那么您将写入日志记录，它会附加到磁盘文件中。 FILE SYSTEM 然后(可能)将您刚刚所做的更改附加到 ITS 日志，以便它可以更新其本地文件系统结构。稍后，文件系统还将提交其脏页并使其元数据更改永久化。

因此，您可以看到，即使是简单的追加也可以调用多次写入磁盘。

现在考虑像 CouchDB 这样的“仅附加”设计。 Couch 会做的是，当您进行简单的写入时，它没有日志。该文件是它自己的日志。 Couch DB 文件无休止地增长，并且在维护期间需要压缩。但是当它进行写入时，它不仅会写入数据页，还会写入任何受影响的索引。并且当索引受到影响时，Couch 将重写索引更改的整个 BRANCH 从根到叶。因此，在这种情况下，简单的写入可能比您最初想象的要昂贵。

现在，当然，您加入了所有随机读取来破坏您的随机写入，这一切很快就会变得非常复杂。不过我学到的是，虽然流带宽是 IO 操作的一个重要方面，但每秒的整体操作更为重要。您可以拥有 2 个具有相同带宽的磁盘，但盘片和/或磁头速度较慢的磁盘每秒的操作次数较少，这仅来自磁头行程时间和盘片寻道时间。

理想情况下，您的数据库使用专用原始存储而不是文件系统进行存储，但现在大多数都没有这样做。基于文件系统的存储在操作上的优势通常超过性能优势。

如果您在文件系统上，那么预分配的顺序文件是一个好处，这样您的“仅追加”就不会简单地跳过文件系统上的其他文件，从而变得类似于随机更新。此外，通过使用预分配的文件，您的更新只是在写入期间更新数据库数据结构，而不是在文件扩展时更新数据库和文件系统数据结构。

将日志、索引和数据放在不同的磁盘上，可以让多个驱动器同时工作，干扰更少。与与随机数据读取或索引更新作斗争相比，您的日志实际上只能追加。

因此，所有这些因素都会影响数据库的吞吐量。