Redis
 sql >> база данни >  >> NoSQL >> Redis

Redis AOF fsync (ВИНАГИ) срещу LSM дърво

LSM е AOF, който искате да четете понякога. Правите някаква режийна работа, за да можете да я прочетете по-бързо по-късно. Redis е проектиран така, че никога или само в специален случай да го четете. От друга страна, Касандра често го чете, за да обслужва заявки.

И това, което Redis нарича бавно, всъщност е много много бързо за db като Cassandra.

============================АКТУАЛИЗИРАНЕ

Оказа се, че съм направила заключения твърде рано. От гледна точка на дизайна всичко по-горе е вярно, но изпълнението се различава много. Въпреки че Cassandra претендира за абсолютна издръжливост, тя не fsync за всяка транзакция и няма начин да го накарате да го направи (но всяка транзакция може да бъде fsynced). Най-доброто, което мога да направя, е „fsync в пакетен режим най-малко 1 мс след предишно fsync“. Това означава, че за бенчмарк за 4 нишки, който използвах, той правеше 4 записа на fsync и нишките чакаха да се извърши fsync. От друга страна, Redis правеше fsync при всяко записване, така че 4 пъти по-често. С добавяне на повече нишки и повече дялове на масата, Касандра може да спечели още по-голямо. Но имайте предвид, че описаният от вас случай на употреба не е типичен. И други архитектурни различия (Cassandra е добра в разделянето, Redis е добър в гишетата, LUA и други) все още важат.

Числа:

Команда Redis:set(KEY + (tstate.i++), TEXT);

Команда на Cassandra:execute("insert into test.test (id,data) values (?,?)", state.i++, TEXT)

Където TEXT = "Wake up, Neo. We have updated our privacy policy."

Redis fsync на всяка секунда, 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 всяко записване, 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 при всяко записване, 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)

Касандра, fsync всяка секунда, 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)

Касандра, fsync всяка партида, но изчакайте поне 1 мс, 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. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Как да проверите дали сокетът е жив (свързан) в socket.io с множество възли и socket.io-redis

  2. Faye или Redis Pubsub

  3. Python Reddis Queue ValueError:Функциите от модула __main__ не могат да бъдат обработени от работници

  4. Как да отстраним грешката, когато командата OOM не е разрешена, когато се използва памет> 'maxmemory' в Redis?

  5. Redis списък с вложени ключове