この記事はここで多くの洞察を提供することができます:http://redis.io/topics/memory-optimization
オブジェクトの配列をRedis(スポイラー)に保存する方法はたくさんあります :ほとんどのユースケースでオプション1が好きです):
-
オブジェクト全体をJSONでエンコードされた文字列として単一のキーに保存し、セット(またはより適切な場合はリスト)を使用してすべてのオブジェクトを追跡します。例:
INCR id:users SET user:{id} '{"name":"Fred","age":25}' SADD users {id}
一般的に言って、これはほとんどの場合おそらく最良の方法です。オブジェクトに多数のフィールドがあり、オブジェクトが他のオブジェクトとネストされておらず、一度にフィールドの小さなサブセットにしかアクセスしない傾向がある場合は、オプション2を使用することをお勧めします。
利点 :「グッドプラクティス」と見なされます。各オブジェクトは本格的なRedisキーです。 JSONの解析は高速です。特に、このオブジェクトの多くのフィールドに一度にアクセスする必要がある場合はそうです。 短所 :単一のフィールドにアクセスするだけでよい場合は遅くなります。
-
各オブジェクトのプロパティをRedisハッシュに保存します。
INCR id:users HMSET user:{id} name "Fred" age 25 SADD users {id}
利点 :「グッドプラクティス」と見なされます。各オブジェクトは本格的なRedisキーです。 JSON文字列を解析する必要はありません。 短所 :オブジェクトのすべて/ほとんどのフィールドにアクセスする必要がある場合は、遅くなる可能性があります。また、ネストされたオブジェクト(オブジェクト内のオブジェクト)は簡単に保存できません。
-
各オブジェクトをJSON文字列としてRedisハッシュに保存します。
INCR id:users HMSET users {id} '{"name":"Fred","age":25}'
これにより、少し統合して、多くのキーではなく2つのキーのみを使用できます。明らかな欠点は、TTL(およびその他のもの)を各ユーザーオブジェクトに設定できないことです。これは、TTLがRedisハッシュの単なるフィールドであり、本格的なRedisキーではないためです。
利点 :JSON解析は高速です。特に、このオブジェクトの多くのフィールドに一度にアクセスする必要がある場合はそうです。メインキーの名前空間の「汚染」が少なくなります。 短所 :オブジェクトが多い場合の#1とほぼ同じメモリ使用量。単一のフィールドにのみアクセスする必要がある場合は、#2よりも遅くなります。おそらく「グッドプラクティス」とは見なされません。
-
各オブジェクトの各プロパティを専用のキーに保存します。
INCR id:users SET user:{id}:name "Fred" SET user:{id}:age 25 SADD users {id}
上記の記事によると、このオプションはほとんどありません 推奨(オブジェクトのプロパティに特定のTTLなどが必要な場合を除く)。
利点 :オブジェクトのプロパティは本格的なRedisキーであり、アプリにとってやり過ぎではない可能性があります。 短所 :低速で、より多くのメモリを使用し、「ベストプラクティス」とは見なされません。メインキーの名前空間の汚染がたくさんあります。
全体の概要
オプション4は一般的には好ましくありません。オプション1と2は非常に似ており、どちらもかなり一般的です。オプション1(一般的に言えば)を好むのは、より複雑なオブジェクト(複数のネストのレイヤーなど)を格納できるためです。オプション3は、本当に気にかける場合に使用されます。 メインのキー名前空間を汚染しないことについて(つまり、データベースに多くのキーが存在することを望まず、TTLやキーシャーディングなどは気にしない)。
ここで問題が発生した場合は、コメントを残して、反対票を投じる前に回答を修正できるようにすることを検討してください。ありがとう! :)