WAL怎么可能?提前写日志?有比直接写入磁盘更好的性能吗?

Kra*_* Li 8 database ceph rocksdb

WAL(Write-Ahead Log)技术已经在很多系统中使用。

WAL 的机制是,当客户端写入数据时,系统会做两件事:

  1. 日志写入磁盘并返回给客户端
  2. 数据异步写入磁盘、缓存或内存

有两个好处:

  1. 如果出现异常(即断电),我们可以从日志中恢复数据。
  2. 性能好,因为我们异步写入数据,可以批量操作

为什么不直接将数据写入磁盘?您将每次写入都直接写入磁盘。成功时,您告诉客户端成功,如果写入失败,则返回失败的响应或超时。

这样,您仍然拥有这两个好处。

  1. 在断电的情况下,您不需要恢复任何东西。因为返回给客户端的每个成功响应都意味着数据确实在磁盘上。
  2. 性能应该是一样的。虽然我们经常接触磁盘,但是 WAL 也是一样的(WAL 每次写入成功都意味着它在磁盘上成功)

那么使用 WAL 有什么好处呢?

jan*_*anm 5

表现。

  • 列表中的第二步是可选的。对于繁忙的记录,该值在再次更新之前可能无法从缓存中移出到磁盘上。不需要执行这些写入,只需执行日志写入以进行可能的恢复。

  • 日志写入可以批处理为更大的顺序写入。对于繁忙的工作负载,延迟日志写入然后执行单次写入可以显着提高吞吐量。

当旋转磁盘是标准技术时,这一点更为重要,因为寻道时间和旋转延迟有点问题。这是在读/写磁头下获取磁盘正确部分的物理过程。对于 SSD,这些考虑因素并不那么重要,但避免一些写入,大型顺序写入仍然有帮助。

更新:

SSD 在大顺序写入方面也有更好的性能,但原因不同。这并不像说“没有寻道时间或旋转延迟,因此只是随机写入”那么简单。例如,将大块写入 SSD 知道是“空闲”的空间(例如,通过对驱动器的 TRIM 命令)比读取-修改-写入更好,其中驱动器还需要管理磨损均衡并可能将更新映射到不同的内部块大小。

  • @Sush不,持久性保证仍然存在,因为写入完成后提交仍然完成。为了让它发挥作用,工作量需要足够高。这个想法是以某些事务的一些额外延迟为代价来提高整体系统吞吐量。 (2认同)