Tout dépend de la façon dont vous allez l'utiliser. Si chaque octet compte, par exemple lorsque vous devez payer pour chaque Ko transféré vers un service cloud, vous pouvez calculer les coûts. Le calcul est simple; un octet est un octet 'sur le fil'. À l'intérieur de redis, pour des valeurs plus importantes, c'est tout aussi simple. Pour les valeurs plus petites, Redis effectue une optimisation de la mémoire.
Dans votre HSET Par exemple, vous divisez les membres, ce qui n'a de sens que si vous avez besoin qu'ils soient séparés les uns des autres la plupart du temps. Une meilleure approche -pourrait- être :HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Des clés/membres séparés "coûtent" beaucoup plus que des chaînes plus longues, en termes de performances. Vous pouvez même mettre une table entière ou un ensemble de données dans un membre s'il ne doit être utilisé que comme une entité semi-statique complète.
Vitesse et taille :il existe une différence notable entre les clés et valeurs .
Clés : Plus court est généralement plus efficace en termes de mémoire et de vitesse. Si vous utilisez un ensemble trié redis, vous pouvez même utiliser des "nombres" comme clés (ensemble trié "membres" plus "scores"). Je dis "chiffres" parce qu'un score est techniquement un float64, mais pour être utilisé comme ID, il doit être compris entre -999999999999999 et 999999999999999 y compris (c'est 15 chiffres), sans aucune partie fractionnaire. Cela peut être très utile, car Redis effectue un tri à la volée O(log(n)) rapide et évolutif des ensembles triés (à l'aide de listes de sélection simplifiées).
Valeurs : Le format MsgPack (non compressé) prend le moins de place, surtout si vous stockez les définitions une fois et les valeurs plusieurs. JSON est un peu moins économe en mémoire, mais c'est bien sûr un format IPC si courant qu'il ne devrait pas être laissé de côté. Chaînes brutes, caractères séparés, longueur fixe (pouah), quel que soit votre désir, il est possible de l'utiliser. Vous pouvez toujours compresser vos données avant de les stocker dans Redis. Jusqu'à présent, l'efficacité de la mémoire . Quand il s'agit de vitesse , c'est moins simple. Si vous souhaitez utiliser les scripts côté serveur Lua (ce que vous devriez faire), vous ne pouvez rien faire avec les données compressées. JSON et MsgPack peuvent être désérialisés, mais uniquement "dans leur ensemble". Ce qui est bien dans la plupart des scénarios. Le plus flexible consiste à stocker des valeurs séparées (par exemple en tant que membres d'un HSET), mais cela a également un prix (la plupart du temps :un prix trop élevé). Vous pouvez également combiner tout cela. Ce que nous utilisons le plus :un préfixe de deux ou trois valeurs séparées par des délimiteurs, suivi d'une charge utile MsgPack.
Mon conseil général est le suivant :commencez par utiliser uniquement les HSET et les ZSET, ne divisez pas les données qui vont ensemble, utilisez des noms PascalCased descriptifs pour vos clés entre 10 et 25 caractères, utilisez ':' si vous avez besoin de délimiteurs dans vos clés (espaces de noms) , sérialisez en JSON (pour plus de simplicité, mais codez pour passer facilement à MsgPack), utilisez les scripts Lua (même si vous ne connaissez pas Lua, le sous-ensemble que vous utilisez dans Redis est minuscule).
Je ne m'en soucierais pas trop dans la phase de démarrage de votre projet, vous pouvez toujours le changer plus tard et faire des comparaisons A/B dès que vous avez des données interpolables.
J'espère que cela vous aidera, TW
