LSM ist AOF, das möchte man eigentlich manchmal lesen. Sie erledigen etwas Überkopfarbeit, damit Sie es später schneller lesen können. Redis ist so konzipiert, dass Sie es nie oder nur in besonderen Fällen lesen. Auf der anderen Seite liest Cassandra es oft, um Anfragen zu erfüllen.
Und was Redis als langsam bezeichnet, ist für eine Datenbank wie Cassandra eigentlich sehr, sehr schnell.
===========================AKTUALISIERUNG
Es stellt sich heraus, dass ich zu früh voreilige Schlüsse gezogen habe. Aus gestalterischer Sicht ist alles oben Genannte wahr, aber die Implementierung unterscheidet sich so sehr. Obwohl Cassandra absolute Haltbarkeit behauptet, ist es nicht fsync bei jeder Transaktion und es gibt keine Möglichkeit, dies zu erzwingen (aber jede Transaktion könnte fsynct werden). Das Beste, was ich tun könnte, ist 'fsync im Batch-Modus mindestens 1 ms nach vorherigem fsync'. Dies bedeutet, dass für den von mir verwendeten 4-Thread-Benchmark 4 Schreibvorgänge pro fsync durchgeführt wurden und die Threads darauf warteten, dass fsync ausgeführt wurde. Auf der anderen Seite führte Redis bei jedem Schreibvorgang fsync aus, also viermal häufiger. Mit dem Hinzufügen von mehr Threads und mehr Partitionen der Tabelle könnte Cassandra noch größer gewinnen. Beachten Sie jedoch, dass der von Ihnen beschriebene Anwendungsfall nicht typisch ist. Und andere architektonische Unterschiede (Cassandra ist gut bei der Partitionierung, Redis ist gut bei Zählern, LUA und anderen) gelten immer noch.
Zahlen:
Redis-Befehl:set(KEY + (tstate.i++), TEXT);
Cassandra-Befehl:execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)
Wobei TEXT = "Wake up, Neo. We have updated our privacy policy."
Fsync jede Sekunde neu erstellen, 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 fsync bei jedem Schreibvorgang, 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, fsync bei jedem Schreibvorgang, NVMe (Samsung 960 PRO 1 TB)
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, fsync jede Sekunde, 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 jeden Batch, aber warte mindestens 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)
