Redisで使用できるのは単純なデータ構造のみであり、値で構成することはできません（CouchDBやMongoDBなどのドキュメント指向データベースで行うことができるように）。ただし、参照によってデータ構造を構成することは可能であり、これは非常に一般的なパターンです。
たとえば、セットに含まれるアイテムは、他のオブジェクト（リスト、ハッシュテーブル、他のセットなど）のキーにすることができます。これをあなたの例に適用してみましょう。
顧客とデバイス+ポート間の関係をモデル化するために、顧客IDを含むセットを使用できます。顧客に関する情報を保存するには、顧客ごとに1つのハッシュテーブルで十分です。
お客様は次のとおりです。
hmset c:1 name Smith protocol tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:2 name Jackson protocol udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:3 name Davis protocol tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4
これらのレコードのキーはc：ID
です。それらのうちの2つをデバイスとポートに関連付けましょう：
sadd d:Los_Angeles:11 2 3
このセットのキーはd：device：portです。 c：およびd：プレフィックスは単なる慣例です。デバイス/ポートごとに、1つのセットを作成する必要があります。特定の顧客は複数のセットに属している可能性があります（したがって、複数のデバイス/ポートに関連付けられている可能性があります）。
これで、このデバイス/ポートに接続された配信方法を持つ顧客を見つけるために、セットのコンテンツを取得する必要があります。
smembers d:Los_Angeles:11
1) "2"
2) "3"
次に、対応する顧客情報は、いくつかのhgetallコマンドをパイプライン化することで取得できます。
hgetall c:2
hgetall c:3
1) "name"
2) "Jackson"
3) "protocol"
4) "udp"
5) "snmp_dest"
6) "127.0.0.1"
7) "syslog_dest"
8) "127.0.0.2"
1) "name"
2) "Davis"
3) "protocol"
4) "tcp"
5) "snmp_dest"
6) "127.0.0.3"
7) "syslog_dest"
8) "127.0.0.4"
コマンドの数を恐れないでください。これらは非常に高速であり、ほとんどのRedisクライアントにはクエリをパイプライン処理する機能があるため、必要なラウンドトリップ数は最小限です。 1つのメンバーと複数のhgetallを使用するだけで、2回の往復で問題を解決できます。
今では、ユビキタスなSORTコマンドのおかげで、もう少し最適化することができます。これはおそらくRedisで最も複雑なコマンドであり、ここでラウンドトリップを保存するために使用できます。
sort d:Los_Angeles:11 by nosort get c:*->name get c:*->protocol get c:*->snmp_dest get c:*->syslog_dest
1) "Jackson"
2) "udp"
3) "127.0.0.1"
4) "127.0.0.2"
5) "Davis"
6) "tcp"
7) "127.0.0.3"
8) "127.0.0.4"
1つのコマンドで、デバイス/ポートセットのコンテンツを取得し、対応する顧客情報を取得します。
この例は簡単でしたが、より一般的には、Redisを使用して複雑なデータ構造を表すことはできますが、すぐにはできません。構造とデータアクセスの両方の観点からモデルを慎重に検討する必要があります（つまり、設計時に、データに固執する ユースケース）。