Det kommer helt an på, hvordan du skal bruge det. Hvis hver byte tæller, for eksempel når du skal betale for hver kB, der overføres til en cloud-tjeneste, kan du beregne omkostningerne. Matematikken er enkel; en byte er en byte 'på ledningen'. Inde i redis, for større værdier er det lige så enkelt. For mindre værdier udfører Redis noget hukommelsesoptimering.
I din HSET for eksempel deler du medlemmerne ud, hvilket kun giver mening, hvis du har brug for dem adskilt fra hinanden det meste af tiden. En bedre tilgang -kan- være:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Separate tangenter/medlemmer 'koster' meget mere end længere strenge, præstationsmæssigt. Du kan endda lægge en hel tabel eller et datasæt i ét medlem, hvis det kun skal bruges som en komplet semi-statisk enhed.
Hastighed og størrelse:Der er en bemærkelsesværdig forskel mellem nøgler og værdier .
Nøgler: Kortere er generelt mere hukommelseseffektiv såvel som hastighedseffektiv. Hvis du bruger et redis Sorteret Sæt, kan du endda bruge 'tal' som nøgler (sorteret sæt 'medlemmer' plus 'score'). Jeg siger "tal", fordi en score teknisk set er en float64, men for at blive brugt som et ID skal den være mellem -999999999999999 og 9999999999999999 inklusive (det er 15 cifre), uden nogen del. Dette kan være virkelig nyttigt, da Redis udfører hurtig og skalerbar O(log(n))-on-the-fly sortering af sorterede sæt (ved hjælp af overspringslister, forenklet).
Værdier: MsgPack-formatet (ukomprimeret) fylder mindst, især hvis du gemmer definitionerne én gang og værdierne mange. JSON er en smule mindre hukommelseseffektiv, men er selvfølgelig et så almindeligt IPC-format, at det ikke bør udelades. Rå strenge, karakteradskilt, fast længde (ugh), hvad end du ønsker, er det muligt at bruge. Du kan altid komprimere dine data, før du gemmer dem i Redis. Indtil videre hukommelseseffektivitet . Når det kommer til hastighed , det er mindre enkelt. Hvis du vil bruge Lua server-side scripting (hvilket du burde), kan du ikke gøre noget med komprimerede data. JSON og MsgPack kan deserialiseres, men kun 'som en helhed'. Hvilket er fint i de fleste scenarier. Det mest fleksible er at gemme separate værdier (f.eks. som medlemmer af et HSET), men det har også en pris (det meste af tiden:en for høj pris). Du kan også kombinere alle disse. Det, vi bruger mest:et præfiks med to eller tre adskilte værdier efterfulgt af en MsgPack-nyttelast.
Mit generelle råd er:start med kun at bruge HSET's og ZSET's, lad være med at dele data ud, der hører sammen, brug beskrivende PascalCased-navne til dine nøgler mellem 10-25 tegn, brug ':', hvis du har brug for skilletegn i dine nøgler (namespaces) , serialiser som JSON (for nemheds skyld, men kode for nemt at skifte til MsgPack), brug Lua scripting (selvom du ikke kender Lua, er den delmængde, du bruger i Redis, lille).
Jeg ville ikke bekymre mig for meget om det i opstartsfasen af dit projekt, du kan altid ændre det senere og lave nogle A/B-sammenligninger, så snart du har nogle interpolerbare data.
Håber dette hjælper, TW