Всичко зависи от това как ще го използвате. Ако всеки байт е от значение, например когато трябва да платите за всеки kB, прехвърлен към облачна услуга, можете да изчислите разходите. Математиката е проста; байтът е байт "по проводника". Вътре в redis, за по-големи стойности е еднакво просто. За по-малки стойности Redis прави известна оптимизация на паметта.
Във вашия HSET например, разделяте членовете, което има смисъл само ако имате нужда от тях отделени един от друг през повечето време. По-добър подход -може- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Отделните ключове/членове „коват“ много повече от по-дълги низове, по отношение на производителността. Можете дори да поставите цяла таблица или набор от данни в един член, ако ще се използва само като един пълен полустатичен обект.
Скорост и размер:Има забележима разлика между клавишите и стойности .
Ключове: По-късото обикновено е по-ефективно за паметта, както и за скоростта. Ако използвате redis Sorted Set, можете дори да използвате „числа“ като ключове (сортиран набор „членове“ плюс „резултати“). Казвам „числа“, защото резултатът технически е float64, но за да се използва като идентификатор, той трябва да бъде между -999999999999999 и 999999999999999, включително (това са 15 цифри), без никаква дробна част. Това може да бъде наистина полезно, тъй като Redis извършва бързо и мащабируемо O(log(n)) сортиране в движение на сортирани набори (с помощта на списъци за пропускане, опростено).
Стойности: Форматът MsgPack (некомпресиран) заема най-малко място, особено ако съхранявате дефинициите веднъж и стойностите много. JSON е малко по-малко ефективен от паметта, но разбира се е толкова често срещан IPC формат, че не бива да се пропуска. Необработени низове, разделени на символи, фиксирана дължина (ugh), каквото и да желаете, възможно е да използвате. Винаги можете да компресирате данните си, преди да ги съхраните в Redis. Досега ефективност на паметта . Когато става въпрос за скорост , по-малко е просто. Ако искате да използвате Lua скриптове от страна на сървъра (което трябва), не можете да направите нищо с компресирани данни. JSON и MsgPack могат да бъдат десериализирани, но само „като цяло“. Което е добре в повечето сценарии. Най-гъвкавото е съхраняването на отделни стойности (например като членове на HSET), но това също има цена (през повечето време:твърде висока цена). Можете също да комбинирате всичко това. Какво използваме най-често:префикс от две или три стойности, разделени с разделители, последвани от полезен товар MsgPack.
Моят общ съвет е:започнете с използването само на HSET и ZSET, не разделяйте данни, които принадлежат заедно, използвайте описателни имена на PascalCased за вашите ключове между 10-25 знака, използвайте ":", ако имате нужда от разделители във вашите ключове (пространства от имена) , сериализирайте като JSON (за простота, но код за лесно превключване към MsgPack), използвайте Lua скриптове (дори и да не познавате Lua, подмножеството, което използвате в Redis, е малко).
Не бих се тревожил много за това в началната фаза на вашия проект, винаги можете да го промените по-късно и да направите някои A/B сравнения, веднага щом имате някои интерполируеми данни.
Надявам се това да помогне, TW
