我对日志结构化合并树（LSM树）的理解是它利用了这样一个事实：只需将更新附加到预写日志并返回到磁盘，就可以非常快速地附加到磁盘上（因为它不需要搜索）客户端。 我的理解是，这仍然提供了直接的持久性，同时仍然非常快。
我不认为使用LSM树的Redis似乎有一种模式，你可以在每次写入时使用AOF + fsync。 https://redis.io/topics/latency。文档说：
AOF + fsync always: this is very slow, you should use it only if you know what you are doing.
我很困惑为什么这会非常慢，因为原则上你仍然只是在每次更新时附加一个文件，就像Cassandra这样的LSM树数据库正在做。
答案 0 :(得分：1)
这有点比较苹果和橘子，它们解决了不同的问题。
Redis应该适合内存，非常快。如果配置为fsync每秒秒，它仍然会非常快，并且通过一些聪明的客户端复制将提供与Cassandra基本相同的持久性。
Cassandra的设计在多个节点和数据中心的许多tbs或PB之间。你可以期望每个节点都有tb，你不能只是fsync整个数据集，并且在commitlog中安装整个集合会使重放时间过长。因此，对于LSM树，您只需同步更改并推迟成本，直到读取和写入路径压缩为止。
我的理解是，这仍然提供了直接的持久性，同时仍然非常快。
默认情况下，commitlog是周期性的fsync，而不是每个请求，所以它只是一个内存附加，这就是为什么要写入~10微秒。您将需要使用批处理（或组以获得更好的延迟/吞吐量）来保证每个副本级别的持久性，这会将写入时间提高到~10毫秒（非常手动）。这在实践中处理时具有更高的复制因子，包括交叉DC，但如果整个副本集在瞬间（不是流星证明）发生故障，您仍然可能会丢失数据。因此，具有默认设置的单个主机群集不持久。强烈建议使用少于三个节点集群或RF <3，因为它根本不安全。我认为高可用性是Cassandras的卖点，而不是它的性能，并且可用性部分提供了一些耐用性。