それはすべて、それをどのように使用するかによって異なります。たとえば、クラウドサービスに転送されるkBごとに支払う必要がある場合など、すべてのバイトが重要な場合は、コストを計算できます。数学は簡単です。バイトは、ワイヤ上のバイトです。 redisの内部では、値が大きい場合も同様に簡単です。小さい値の場合、Redisはメモリの最適化を行います。
HSETで たとえば、メンバーを分割します。これは、ほとんどの場合、メンバーを互いに分離する必要がある場合にのみ意味があります。より良いアプローチ-かもしれない- be：HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' 。キー/メンバーを分離すると、パフォーマンスの面で、長い文字列よりもはるかに多くのコストがかかります。 1つの完全な半静的エンティティとしてのみ使用される場合は、テーブル全体またはデータセットを1つのメンバーに配置することもできます。
速度とサイズ：キーには顕著な違いがあります および値 。
キー： 一般に、短いほどメモリ効率が高く、速度効率も高くなります。 redisのソート済みセットを使用する場合は、「数字」をキーとして使用することもできます（ソート済みセットの「メンバー」と「スコア」）。スコアは技術的にはfloat64であるため、「数値」と言いますが、IDとして使用するには、小数部分を含まない-999999999999999から999999999999999（15桁）を含む必要があります。 Redisは、ソートされたセットのオンザフライソート（スキップリストを使用、簡略化）を高速かつスケーラブルに行うため、これは非常に役立ちます。
値： MsgPack形式（非圧縮）は、特に定義を1回保存し、値を多数保存する場合に、占有するスペースが最小になります。 JSONはメモリ効率が少し劣りますが、もちろん、このような一般的なIPC形式であるため、省略してはなりません。生の文字列、文字区切り、固定長（ugh）、希望に応じて使用できます。データをRedisに保存する前に、いつでもデータを圧縮できます。これまでのところメモリ効率 。 速度に関しては 、それはそれほど単純ではありません。 Luaサーバーサイドスクリプトを使用する場合（これを使用する必要があります）、圧縮データでは何もできません。 JSONとMsgPackは逆シリアル化できますが、「全体として」のみです。ほとんどのシナリオではこれで問題ありません。最も柔軟なのは（たとえばHSETのメンバーとして）個別の値を格納することですが、これには代償も伴います（ほとんどの場合、価格が高すぎます）。これらすべてを組み合わせることもできます。最もよく使用するのは、区切り文字で区切られた2つまたは3つの値のプレフィックスと、それに続くMsgPackペイロードです。
私の一般的なアドバイスは次のとおりです。HSETとZSETのみを使用することから始め、一緒に属するデータを分割せず、10〜25文字のキーに説明的なPascalCased名を使用し、キー（名前空間）に区切り文字が必要な場合は「：」を使用します、JSONとしてシリアル化し（簡単にするためですが、MsgPackに簡単に切り替えるためのコード）、Luaスクリプトを使用します（Luaを知らなくても、Redisで使用するサブセットはごくわずかです）。
プロジェクトの起動段階ではあまり心配しません。後でいつでも変更して、補間可能なデータができたらすぐにA/B比較を行うことができます。
これがお役に立てば幸いです、TW