LSM est AOF que vous voulez réellement lire parfois. Vous faites des travaux généraux afin de pouvoir le lire plus rapidement plus tard. Redis est conçu pour que vous ne le lisiez jamais ou seulement dans un cas particulier. D'un autre côté, Cassandra le lit souvent pour répondre aux demandes.
Et ce que Redis appelle lent est en fait très très rapide pour une base de données comme Cassandra.
===========================MISE À JOUR
Il s'avère que j'ai sauté trop tôt dans les conclusions. Du point de vue de la conception, tout ce qui précède est vrai, mais la mise en œuvre diffère tellement. Bien que Cassandra revendique une durabilité absolue, elle ne fait pas fsync sur chaque transaction et il n'y a aucun moyen de le forcer à le faire (mais chaque transaction peut être fsynced). Le mieux que je puisse faire est de "fsync en mode batch au moins 1 ms après la précédente fsync". Cela signifie que pour le benchmark à 4 threads que j'utilisais, il faisait 4 écritures par fsync et que les threads attendaient que fsync soit fait. D'un autre côté, Redis a fait fsync à chaque écriture, donc 4 fois plus souvent. Avec l'ajout de plus de threads et de plus de partitions de la table, Cassandra pourrait gagner encore plus gros. Mais notez que le cas d'utilisation que vous avez décrit n'est pas typique. Et d'autres différences architecturales (Cassandra est bonne pour le partitionnement, Redis est bonne pour les compteurs, LUA et autres) s'appliquent toujours.
Chiffres :
Commande Redis :set(KEY + (tstate.i++), TEXT);
Commande Cassandra :execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)
Où TEXT = "Wake up, Neo. We have updated our privacy policy."
Redis fsync toutes les secondes, disque dur
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 à chaque écriture, disque dur
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 à chaque écriture, NVMe (Samsung 960 PRO 1 To)
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 toutes les secondes, disque dur
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 chaque lot, mais attendez au moins 1 ms, disque dur
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)
