Allt beror på hur du ska använda den. Om varje byte räknas, till exempel när du ska betala för varje kB som överförs till en molntjänst, kan du räkna ut kostnaderna. Matematiken är enkel; en byte är en byte "på tråden". Inuti redis, för större värden är det lika enkelt. För mindre värden gör Redis en del minnesoptimering.
I din HSET till exempel delar du ut medlemmarna, vilket bara är vettigt om du behöver dem separerade från varandra för det mesta. Ett bättre tillvägagångssätt -kan- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Separata nycklar/medlemmar "kostar" mycket mer än längre strängar, prestandamässigt. Du kan till och med lägga in en hel tabell eller datauppsättning i en medlem om den bara ska användas som en komplett semistatisk enhet.
Hastighet och storlek:Det finns en anmärkningsvärd skillnad mellan nycklar och värden .
Nycklar: Kortare är i allmänhet mer minneseffektivt såväl som hastighetseffektivt. Om du använder en redis sorterad uppsättning kan du till och med använda "siffror" som nycklar (sorterade uppsättning "medlemmar" plus "poäng"). Jag säger "siffror" eftersom en poäng tekniskt sett är en float64, men för att kunna användas som ett ID måste den vara mellan -999999999999999 och 9999999999999999 inklusive (det är 15 siffror), utan någon bråkdel. Detta kan vara väldigt användbart, eftersom Redis gör snabb och skalbar O(log(n))-sortering av sorterade uppsättningar (med hjälp av överhoppningslistor, förenklat).
Värden: MsgPack-formatet (okomprimerat) tar minst plats, speciellt om du lagrar definitionerna en gång och värdena många. JSON är lite mindre minneseffektivt, men är givetvis ett så vanligt IPC-format att det inte bör utelämnas. Råsträngar, teckenseparerade, fast längd (ugh), vad du än vill så går det att använda. Du kan alltid komprimera din data innan du lagrar den i Redis. Hittills minneseffektivitet . När det gäller hastighet , det är mindre enkelt. Om du vill använda Lua server-side scripting (vilket du borde) kan du inte göra något med komprimerad data. JSON och MsgPack kan deserialiseras, men bara "som en helhet". Vilket är bra i de flesta scenarier. Det mest flexibla är att lagra separata värden (till exempel som medlemmar i en HSET), men detta har också ett pris (för det mesta:för högt pris). Du kan också kombinera alla dessa. Det vi använder mest:ett prefix med två eller tre avgränsningsseparerade värden, följt av en MsgPack-nyttolast.
Mitt allmänna råd är:börja med att bara använda HSET:s och ZSET:s, dela inte ut data som hör ihop, använd beskrivande PascalCased-namn för dina nycklar mellan 10-25 tecken, använd ':' om du behöver avgränsare i dina nycklar (namnrymder) , serialisera som JSON (för enkelhetens skull, men kod för att enkelt byta till MsgPack), använd Lua-skript (även om du inte känner till Lua, är delmängden du använder i Redis liten).
Jag skulle inte oroa mig för mycket i startfasen av ditt projekt, du kan alltid ändra det senare och göra några A/B-jämförelser så fort du har några interpolerbara data.
Hoppas detta hjälper, TW