sql >> Database >  >> NoSQL >> Redis

Redis AOF fsync (ALTIJD) vs. LSM-boom

LSM is AOF die je soms echt wilt lezen. Je doet wat overheadwerk zodat je het later sneller kunt lezen. Redis is zo ontworpen dat je het nooit of alleen in een speciaal geval leest. Aan de andere kant leest Cassandra het vaak om verzoeken in te dienen.

En wat Redis traag noemt, is eigenlijk heel erg snel voor een db als Cassandra.

============================BIJWERKEN

Het blijkt dat ik te vroeg in conclusies ben gesprongen. Vanuit ontwerpstandpunt is alles hierboven waar, maar de uitvoering verschilt zo veel. Ondanks dat Cassandra absolute duurzaamheid claimt, fsync op elke transactie en er is geen manier om dit te forceren (maar elke transactie kan worden gesynchroniseerd). Het beste wat ik kon doen is 'fsync in batchmodus minstens 1ms na vorige fsync'. Het betekent dat voor de 4-thread-benchmark die ik gebruikte, het 4 schrijfbewerkingen per fsync deed en threads wachtten tot fsync was voltooid. Aan de andere kant deed Redis fsync bij elke schrijfactie, dus 4 keer vaker. Met toevoeging van meer threads en meer partities van de tafel, zou Cassandra nog groter kunnen winnen. Houd er echter rekening mee dat de use-case die u beschreef niet typisch is. En andere architecturale verschillen (Cassandra is goed in partitioneren, Redis is goed in balies, LUA en andere) zijn nog steeds van toepassing.

Cijfers:

Redis-opdracht:set(KEY + (tstate.i++), TEXT);

Cassandra-opdracht:execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)

Waar TEXT = "Wake up, Neo. We have updated our privacy policy."

Fsync elke seconde opnieuw, 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 elke keer schrijven, 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 elke keer schrijven, 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 elke seconde, 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 elke batch, maar wacht minstens 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)


  1. Aan de slag met Python en MongoDB

  2. geef resultaten door aan een ander commando in redis

  3. Gelijktijdigheid in gopkg.in/mgo.v2 (Mongo, Go)

  4. Hoe kan ik mongodb opvragen met mongoid/rails zonder time-out?