LSM to AOF, który chcesz czasem przeczytać. Wykonujesz trochę pracy nad głową, aby później móc ją szybciej przeczytać. Redis został zaprojektowany tak, abyś nigdy lub tylko w specjalnym przypadku go nie czytał. Z drugiej strony Cassandra często czyta go, aby obsłużyć żądania.
A to, co Redis nazywa powolnym, jest w rzeczywistości bardzo bardzo szybkie dla db jak Cassandra.
============================AKTUALIZACJA
Okazuje się, że zbyt wcześnie wyciągałem wnioski. Z punktu widzenia projektowania wszystko powyżej jest prawdziwe, ale implementacje różnią się tak bardzo. Pomimo tego, że Cassandra twierdzi, że jest absolutną trwałością, nie fsync na każdej transakcji i nie można tego wymusić (ale każdą transakcję można zsynchronizować). Najlepsze, co mogłem zrobić, to „fsync w trybie wsadowym co najmniej 1 ms po poprzednim fsync”. Oznacza to, że dla 4-wątkowego testu porównawczego, którego używałem, robiłem 4 zapisy na fsync, a wątki czekały na wykonanie fsync. Z drugiej strony Redis robił fsync przy każdym zapisie, więc 4 razy częściej. Dzięki dodaniu większej liczby wątków i większej ilości przegród w tabeli, Cassandra mogła wygrać jeszcze więcej. Pamiętaj jednak, że opisany przez Ciebie przypadek użycia nie jest typowy. I inne różnice architektoniczne (Cassandra jest dobra w partycjonowaniu, Redis jest dobra w licznikach, LUA i innych) nadal obowiązują.
Liczby:
Polecenie Redis:set(KEY + (tstate.i++), TEXT);
Polecenie Cassandra:execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)
Gdzie TEXT = "Wake up, Neo. We have updated our privacy policy."
Redis fsync co sekundę, 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 przy każdym zapisie, 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 przy każdym zapisie, 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, fsync co sekundę, 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, zsynchronizuj każdą partię, ale poczekaj co najmniej 1 ms, 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)
