Redis AOF fsync(ALWAYS)与LSM树 [英] Redis AOF fsync (ALWAYS) vs. LSM tree

问题描述

我对日志结构化合并树(LSM树)的理解是，通过将更新附加到预写日志中并返回到客户端.我的理解是，这仍然可以立即提供持久性，而且速度仍然非常快.

My understanding of log structured merge trees (LSM trees) is that it takes advantage of the fact that appending to disk is very fast (since it requires no seeks) by just appending the update to a write-ahead log and returning to the client. My understanding was that this still provides immediate persistence, while still being extremely fast.

Redis(我不认为它使用LSM树)似乎具有一种可以在每次写入时进行AOF + fsync的模式. https://redis.io/topics/latency .该文档说:

Redis, which I don't think uses LSM trees, seems to have a mode where you can AOF+fsync on every write. https://redis.io/topics/latency . The documentation says:

AOF + fsync always: this is very slow, you should use it only if you know what you are doing.

我很困惑为什么这样做会很慢，因为原则上您仍然只在每次更新时都将文件追加到文件中，就像Cassandra这样的LSM-tree数据库一样.

I'm confused why this would be very slow, since in principle you are still only appending to a file on every update, just like LSM-tree databases like Cassandra are doing.

推荐答案

LSM是您有时希望实际读取的AOF.您需要进行一些日常工作，以便以后可以更快地阅读.Redis的设计使您从不或仅在特殊情况下阅读它.另一方面，Cassandra经常读取它来满足请求.

LSM is AOF that you want to actually read sometimes. You do some overhead work so you can read it faster later. Redis is designed so you never or only in a special case read it. On the other hand, Cassandra often reads it to serve requests.

对于像Cassandra这样的数据库，Redis所说的慢实际上是非常快的.

And what Redis calls slow is actually very very fast for a db like Cassandra.

事实证明，我下结论还为时过早.从设计的角度来看，以上所有内容都是正确的，但实现方式却相差甚远.尽管Cassandra声称具有绝对的持久性，但它不会对每个事务进行 fsync ，也没有办法强制这样做(但是每个事务都可以进行fsync).我能做的最好的事情是在以前的fsync之后至少1毫秒以批处理模式进行fsync".这意味着对于我正在使用的4个线程基准测试，每个fsync执行4次写入操作，并且线程正在等待fsync完成.另一方面，Redis在每次写入时都执行fsync，因此频率提高了4倍.通过增加表的更多线程和分区，Cassandra可以赢得更大的收益.但是请注意，您描述的用例不是典型的.其他架构差异(Cassandra擅长分区，Redis擅长计数器，LUA等)仍然适用.

It turns out, I jumped into conclusions too early. From design standpoint everything above is true, but implementation differ so much. Despite Cassandra claiming absolute durability, it does not fsync on each transaction and there is no way to force it do so (but each transaction could be fsynced). The best I could do is 'fsync in batch mode at least 1ms after previous fsync'. It means for 4 thread benchmark I was using it was doing 4 writes per fsync and threads was waiting for fsync to be done. On the other hand, Redis did fsync on every write, so 4 times more often. With addition of more threads and more partitions of the table, Cassandra could win even bigger. But note, that the use case you described is not typical. And other architectural differences (Cassandra is good at partitioning, Redis is good at counters, LUA and other) still apply.

Redis命令: set(KEY +(tstate.i ++)，TEXT);

Cassandra命令: execute(插入到test.test(id，data)值(?，?)中的值(?，?)"，state.i ++，TEXT)

Cassandra command: execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)

其中 TEXT =醒来，Neo.我们已更新了我们的隐私政策."

Redis每秒同步一次HDD

Redis fsync every sec, HDD

Benchmark              (address)   Mode  Cnt      Score      Error  Units
LettuceThreads.shared  localhost  thrpt   15  97535.900 ± 2188.862  ops/s

  97535.900 ±(99.9%) 2188.862 ops/s [Average]
  (min, avg, max) = (94460.868, 97535.900, 100983.563), stdev = 2047.463
  CI (99.9%): [95347.038, 99724.761] (assumes normal distribution)

Redis在每次写入硬盘时都进行同步

Redis fsync every write, HDD

Benchmark              (address)   Mode  Cnt   Score   Error  Units
LettuceThreads.shared  localhost  thrpt   15  48.862 ± 2.237  ops/s

  48.862 ±(99.9%) 2.237 ops/s [Average]
  (min, avg, max) = (47.912, 48.862, 56.351), stdev = 2.092
  CI (99.9%): [46.625, 51.098] (assumes normal distribution)

Redis，每次写入均同步，NVMe(Samsung 960 PRO 1tb)

Redis, fsync every write, NVMe (Samsung 960 PRO 1tb)

Benchmark              (address)   Mode  Cnt    Score   Error  Units
LettuceThreads.shared     remote  thrpt   15  449.248 ± 6.475  ops/s

  449.248 ±(99.9%) 6.475 ops/s [Average]
  (min, avg, max) = (441.206, 449.248, 462.817), stdev = 6.057
  CI (99.9%): [442.773, 455.724] (assumes normal distribution)

Cassandra，每秒同步一次，HDD

Cassandra, fsync every sec,HDD

Benchmark                  Mode  Cnt      Score     Error  Units
CassandraBenchMain.write  thrpt   15  12016.250 ± 601.811  ops/s

  12016.250 ±(99.9%) 601.811 ops/s [Average]
  (min, avg, max) = (10237.077, 12016.250, 12496.275), stdev = 562.935
  CI (99.9%): [11414.439, 12618.062] (assumes normal distribution)

Cassandra，每批fsync，但至少要等待1毫秒，HDD

Cassandra, fsync every batch, but wait at least 1ms, HDD

Benchmark                  Mode  Cnt    Score   Error  Units
CassandraBenchMain.write  thrpt   15  195.331 ± 3.695  ops/s

  195.331 ±(99.9%) 3.695 ops/s [Average]
  (min, avg, max) = (186.963, 195.331, 199.312), stdev = 3.456
  CI (99.9%): [191.637, 199.026] (assumes normal distribution)

这篇关于Redis AOF fsync(ALWAYS)与LSM树的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！