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

Последователно хеширане като начин за мащабиране на записите

Има две причини да използвате множество възли в клъстер:

  • Шардиране за ограничаване на количеството данни, съхранявани на всеки възел
  • Дублиране за намаляване на натоварването при четене и позволяване на премахване на възел без загуба на данни.

Двете са коренно различни, но можете да приложите и двете - използвайте последователно хеширане, за да посочите набор от възли със стандартна настройка главен/подчинен, а не един възел.

Ако клъстерът е основното ви хранилище за данни, а не кеш, ще ви е необходима различна стратегия за преразпределение, която включва копиране на данните.

Моята реализация се основава на това, че клиентът избере една от 64k ​​кофи за хеш и има таблица, която съпоставя тази кофа с възел. Първоначално всички картографирани към възел №1.

Когато възел #1 стане твърде голям, неговият подчинен става главен възел #2 и таблицата се актуализира, за да съпостави половината от ключовете на възел #1 към възел #2. В този момент всички четения и записвания ще работят с новото съпоставяне и просто трябва да почистите ключовете, които сега са на грешен възел. В зависимост от изискванията за производителност, можете да проверите всички ключове наведнъж или да проверите произволен избор на ключове, както прави системата за изтичане на срока.




  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Redis / Node.js - 2 клиента (1 pub/sub), причиняващи проблеми с записите

  2. Всяко повикване в рамките на повикване multi() в phpredis води ли до ново мрежово двупосочно пътуване до redis?

  3. Как да деактивирате Redis RDB и AOF?

  4. Защо производителността на Redis SET е по-добра от GET?

  5. съхранявайте IP диапазони в Redis