LSM é AOF que você quer realmente ler algumas vezes. Você faz algum trabalho de sobrecarga para poder lê-lo mais rapidamente mais tarde. O Redis foi projetado para que você nunca ou apenas em um caso especial o leia. Por outro lado, Cassandra costuma lê-lo para atender a solicitações.
E o que o Redis chama de lento é realmente muito, muito rápido para um banco de dados como o Cassandra.
============================ATUALIZAÇÃO
Acontece que tirei conclusões precipitadas muito cedo. Do ponto de vista do design, tudo acima é verdade, mas a implementação difere muito. Apesar de Cassandra alegar durabilidade absoluta, ela não
fsync em cada transação e não há como forçá-lo (mas cada transação pode ser sincronizada). O melhor que eu poderia fazer é 'fsync no modo de lote pelo menos 1ms após o fsync anterior'. Isso significa que para o benchmark de 4 threads que eu estava usando estava fazendo 4 gravações por fsync e os threads estavam esperando que o fsync fosse feito. Por outro lado, o Redis fez fsync em todas as gravações, portanto, 4 vezes mais frequentemente. Com adição de mais threads e mais partições da tabela, Cassandra poderia ganhar ainda mais. Mas observe que o caso de uso que você descreveu não é típico. E outras diferenças arquitetônicas (Cassandra é boa em particionamento, Redis é boa em contadores, LUA e outros) ainda se aplicam. Números:
Comando Redis:
set(KEY + (tstate.i++), TEXT); Comando Cassandra:
execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT) Onde
TEXT = "Wake up, Neo. We have updated our privacy policy." Redis fsync a cada segundo, 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 a cada gravação, 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 a cada gravação, 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 a cada segundo, 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 a cada lote, mas espere pelo menos 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)
