この例を考えると:
user:1 email bob@bob.com
user:1 name bob
私の調査に基づいて、すべての例は次のような「インデックス」を作成します。
user:bob@bob.com 1
私の質問は、「user:1」として保存したほうがよいのではないでしょうか? これにより、コード内で文字列を連結する必要がなくなります。文字列全体を保存しない他の理由はありますか? もしかして記憶?
この例を考えると:
user:1 email bob@bob.com
user:1 name bob
私の調査に基づいて、すべての例は次のような「インデックス」を作成します。
user:bob@bob.com 1
私の質問は、「user:1」として保存したほうがよいのではないでしょうか? これにより、コード内で文字列を連結する必要がなくなります。文字列全体を保存しない他の理由はありますか? もしかして記憶?
質問は、完全なキーをインデックスに格納するか、このキーの一部である数値 ID だけを格納するかについてでした。
Redis には、一般的なメモリ消費量を削減するために活用できる多くのメモリ最適化があります。これらの最適化の 1 つが intset (整数のセットを表す効率的な構造) です。
多くの場合、セットはインデックス エントリとして使用されます。その場合、intset の最適化を利用するには、英数字キーではなく数値 ID を格納する方がはるかに優れています。
特定の電子メール アドレスは 1 人のユーザーにのみ関連付ける必要があるため、例は少し異なります。一意のハッシュ オブジェクトは、インデックス全体を格納するのに適しています。数値 ID はよりコンパクトであり、将来の Redis 最適化の恩恵を受ける可能性があるため、ここでは引き続き数値 ID を使用します。
これまでに伝えてきたことに基づいて、Redisハッシュを使用します。たとえば、データを少し非正規化し、ストアはas hmset users:1 email bob@bob.com name Bob
and'hset users:lookup:emailbob@bob.com1'とします。
このようにして、電子メールIDまたはユーザーIDの両方を使用してユーザーを取得できます。必要に応じて、より多くのルックアップハッシュを作成できます。
より便利なパターンについては、サルヴァトーレサンフィリッポ自身が書いたLittleRedisの本をご覧ください。