多くの Redis チュートリアル (この例など) では、データはセットに格納されますが、複数の値が文字列に結合されます (つまり、ユーザー アカウントは "user:1000:username" と "user:1000:username" の 2 つのエントリとしてセットに格納される場合があります)。 "ユーザー:1000:パスワード")。
ただし、Redis にはハッシュもあります。「username」エントリと「password」エントリを含む「user:1000」ハッシュを使用する方が理にかなっているようです。文字列を連結して特定の値にアクセスするのではなく、ハッシュで直接アクセスするだけです。
では、なぜあまり使われていないのでしょうか。これらは単なる古いチュートリアルですか? または、Redis ハッシュにはパフォーマンスの問題がありますか?
Redis ハッシュは、質問で提案されているように、より複雑なデータを保存するのに適しています。私はまさにそのためにそれらを使用します - キャッシュする必要がある複数の属性を持つオブジェクトを保存するため (具体的には、e コマース サイトの特定の製品の在庫データ)。もちろん、連結された文字列を使用することもできますが、それではクライアント コードが不必要に複雑になり、個々のフィールドを更新することはできません。
あなたは正しいかもしれません - チュートリアルは単にハッシュが導入される前のものかもしれません. オブジェクト表現を格納するために明確に設計されています: http://oldblog.antirez.com/post/redis-weekly-update-1.html
単純な String SET コマンドと比較した場合、新しいアイテムが挿入されたときに Redis がサービスを提供する必要があるコマンドの数 (n 個のコマンド、n はハッシュ内のフィールドの数) が 1 つの懸念になると思います。Redis に 1 日あたり約 100 万回アクセスするサービスでは、これが問題になることはまだありません。私にとって適切なデータ構造を使用することは、パフォーマンスへの影響が無視できるほど重要ではありません。
(また、Redis Sets と Redis Strings に関する私のコメントを参照してください。あなたの質問は Strings について言及していると思いますが、間違っている場合は修正してください!)
ハッシュは、Redis にデータを保存するための最も効率的な方法の 1 つであり、可能な限り効果的に使用することを推奨しています。
http://redis.io/topics/memory-optimization
可能であればハッシュを使用する
小さなハッシュは非常に小さなスペースにエンコードされるため、可能な限りハッシュを使用してデータを表現するようにしてください。たとえば、Web アプリケーションでユーザーを表すオブジェクトがある場合、名前、姓、電子メール、パスワードに異なるキーを使用する代わりに、すべての必須フィールドで単一のハッシュを使用します。