sql >> Databasteknik >  >> NoSQL >> Redis

Redis AOF fsync (ALLTID) kontra LSM-träd

LSM är AOF som man faktiskt vill läsa ibland. Du gör en del overheadarbete så att du kan läsa det snabbare senare. Redis är designad så att du aldrig eller bara i ett speciellt fall läser den. Å andra sidan läser Cassandra det ofta för att betjäna förfrågningar.

Och vad Redis kallar långsam är faktiskt väldigt väldigt snabbt för en db som Cassandra.

=============================UPPDATERING

Det visade sig att jag drog för tidigt slutsatser. Ur designsynpunkt är allt ovan sant, men implementeringen skiljer sig så mycket åt. Trots att Cassandra hävdar absolut hållbarhet, fsync gör den inte på varje transaktion och det finns inget sätt att tvinga den att göra det (men varje transaktion kan fsynkroniseras). Det bästa jag kunde göra är "fsync i batch-läge minst 1ms efter föregående fsync". Det betyder att för 4-tråds benchmark som jag använde gjorde det 4 skrivningar per fsync och trådar väntade på att fsync skulle göras. Å andra sidan gjorde Redis fsync vid varje skrivning, alltså 4 gånger oftare. Med tillägg av fler trådar och fler partitioner på bordet kan Cassandra vinna ännu större. Men observera att användningsfallet du beskrev inte är typiskt. Och andra arkitektoniska skillnader (Cassandra är bra på att partitionera, Redis är bra på diskar, LUA och annat) gäller fortfarande.

Siffror:

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

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

Där TEXT = "Wake up, Neo. We have updated our privacy policy."

Ändra fsync varje sekund, hårddisk

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)

Ändra fsync varje skrivning, 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 every write, 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 varje 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, fsync varje batch, men vänta minst 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)


  1. Spring Redis Error Handle

  2. MongoDB updateMany()

  3. Redis att hitta hash efter fältvärden

  4. MongoDB-aggregat, hur man addToSet varje element av array i grupppipeline