Tutto dipende da come lo utilizzerai. Se ogni byte conta, ad esempio quando devi pagare per ogni kB trasferito su un servizio cloud, puoi calcolare i costi. La matematica è semplice; un byte è un byte 'sul cavo'. All'interno di redis, per valori maggiori è altrettanto semplice. Per valori inferiori, Redis esegue un po' di ottimizzazione della memoria.
Nel tuo HSET ad esempio, dividi i membri, il che ha senso solo se hai bisogno che siano separati l'uno dall'altro per la maggior parte del tempo. Un approccio migliore -potrebbe- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Chiavi/membri separati "costano" molto di più delle stringhe più lunghe, dal punto di vista delle prestazioni. Puoi persino inserire un'intera tabella o un set di dati in un membro se verrà utilizzato solo come un'entità semistatica completa.
Velocità e dimensioni:c'è una notevole differenza tra i tasti e valori .
Chiavi: Più breve è generalmente più efficiente in termini di memoria e velocità. Se usi un set ordinato redis puoi anche usare i "numeri" come chiavi (set ordinato "membri" più "punteggi"). Dico "numeri" perché un punteggio è tecnicamente un float64, ma per essere utilizzato come ID deve essere compreso tra -99999999999999999 e 9999999999999999 inclusi (sono 15 cifre), senza alcuna parte frazionaria. Questo può essere davvero utile, dal momento che Redis esegue l'ordinamento al volo O(log(n)) veloce e scalabile degli insiemi ordinati (usando le skiplist, semplificato).
Valori: Il formato MsgPack (non compresso) occupa meno spazio, soprattutto se si memorizzano le definizioni una volta ei valori molti. JSON è un po' meno efficiente in termini di memoria, ma ovviamente è un formato IPC così comune che non dovrebbe essere escluso. Stringhe grezze, separate da caratteri, lunghezza fissa (ugh), qualunque sia il tuo desiderio, è possibile usarle. Puoi sempre comprimere i tuoi dati prima di archiviarli in Redis. Finora efficienza della memoria . Quando si tratta di velocità , è meno semplice. Se desideri utilizzare lo scripting lato server Lua (cosa che dovresti), non puoi fare nulla con i dati compressi. JSON e MsgPack possono essere deserializzati, ma solo "nel complesso". Il che va bene nella maggior parte degli scenari. La più flessibile è la memorizzazione di valori separati (ad esempio come membri di un HSET), ma anche questo ha un prezzo (il più delle volte:un prezzo troppo alto). Puoi anche combinare tutti questi. Ciò che utilizziamo di più:un prefisso di due o tre valori separati da delimitatori, seguito da un payload MsgPack.
Il mio consiglio generale è:inizia usando solo HSET e ZSET, non dividere i dati che appartengono insieme, usa nomi descrittivi PascalCased per le tue chiavi tra 10-25 caratteri, usa ':' se hai bisogno di delimitatori nelle tue chiavi (spazi dei nomi) , serializza come JSON (per semplicità, ma codice per passare facilmente a MsgPack), usa lo scripting Lua (anche se non conosci Lua, il sottoinsieme che usi in Redis è minuscolo).
Non me ne preoccuperei troppo nella fase di avvio del tuo progetto, puoi sempre cambiarlo in seguito e fare dei confronti A/B non appena hai dei dati interpolabili.
Spero che questo aiuti, TW
