私のプロジェクトでRedisを使用する方法を学んでいます。私が頭を悩ませていないことの1つは、キーの名前にコロンが正確に使用されていることです。
私はこれらのようなキーの名前を見てきました：
users:bob
color:blue
item:bag
コロンはキーをカテゴリに分け、キーの検索を高速化しますか？その場合、キーに名前を付けるときに複数のコロンを使用して、キーをサブカテゴリに分類できますか？最後に、Redisサーバー内でさまざまなデータベースを定義することと関係がありますか？
私はドキュメントを読み、この問題について多くのGoogle検索を行いましたが、奇妙なことに、これについて議論しているものは何も見つかりません。
コロンは、名前空間データを格納するための概念として、以前の redis バージョンにありました。初期のバージョンでは、redis は文字列のみをサポートしていました。電子メールと 'bob' の年齢を保存したい場合は、すべてを文字列として保存する必要があったため、コロンが使用されました。
SET user:bob:email bob@example.com
SET user:bob:age 31
それらには、redis での特別な処理やパフォーマンス特性はありませんでした。唯一の目的は、データを再度見つけるための名前空間です。現在、ハッシュを使用して、コロン付きのキーのほとんどを保存できます。
HSET user:bob email bob@example.com
HSET user:bob age 31
ハッシュに「user:bob」という名前を付ける必要はありません。「bob」という名前にすることもできますが、user-prefix を使用して名前空間を指定すると、このハッシュが持つべき/持つことができる情報がすぐにわかります。
コロンは、キーを構造化する方法です。redis によって解釈されることはありません。他の任意の区切り文字を使用することも、まったく使用しないこともできます。個人的には を好み/ます。これにより、キーがファイル システム パスのように見えます。パフォーマンスに影響はありませんが、redis はすべてのキーをメモリに保持する必要があるため、過度に長くするべきではありません。
SQL の結合に対する redis の回答である sort コマンドの機能を活用するには、適切なキー構造が重要です。
GET user:bob:color -> 'blue'
GET user:alice:color -> 'red'
SMEMBERS user:peter:friends -> alice, bob
SORT user:peter:friends BY NOSORT GET user:*:color -> 'blue', 'red'
キー構造により、構造化されたキーを参照することで SORT がユーザーの色を検索できることがわかります。