U hebt gelijk dat alleen eenvoudige gegevensstructuren beschikbaar zijn met Redis en dat ze niet kunnen worden samengesteld op basis van waarde (zoals u zou kunnen doen met een documentgeoriënteerde database zoals CouchDB of MongoDB). Het is echter mogelijk om gegevensstructuren op basis van referentie samen te stellen, en dit is een veel voorkomend patroon.
De items in een set kunnen bijvoorbeeld de sleutels zijn voor andere objecten (lijsten, hashtabellen, andere sets, enz ...). Laten we proberen dit op uw voorbeeld toe te passen.
Om een relatie tussen klanten en apparaat+poort te modelleren, kunt u sets met klant-ID's gebruiken. Om informatie over de klanten op te slaan, is één hashtabel per klant prima.
Dit zijn de klanten:
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
De sleutels van deze records zijn c:ID
Laten we er twee aan een apparaat en poort koppelen:
sadd d:Los_Angeles:11 2 3
De sleutel van deze set is d:device:port. De voorvoegsels c:en d:zijn slechts een conventie. Er moet één set per apparaat/poort worden gemaakt. Een bepaalde klant kan bij meerdere sets horen (en dus bij meerdere apparaten/poorten horen).
Om de klanten te vinden met leveringsmethoden die aan dit apparaat/poort zijn gekoppeld, hoeven we alleen maar de inhoud van de set op te halen.
smembers d:Los_Angeles:11
1) "2"
2) "3"
dan kan de bijbehorende klantinformatie worden opgehaald door een aantal hgetall-commando's te pipelinen:
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"
Wees niet bang voor het aantal commando's. Ze zijn erg snel en de meeste Redis-clients hebben de mogelijkheid om de query's te pijplijnen, zodat er slechts een minimum aantal retouren nodig is. Door slechts één lid en meerdere hgetall te gebruiken, kan het probleem worden opgelost met slechts twee retourvluchten.
Nu is het mogelijk om nog een beetje verder te optimaliseren, dankzij het alomtegenwoordige SORT-commando. Dit is waarschijnlijk de meest complexe opdracht in Redis en kan worden gebruikt om hier een retourtje op te slaan.
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"
In één opdracht haalt het de inhoud van een apparaat/poortset op en haalt het de bijbehorende klantinformatie op.
Dit voorbeeld was triviaal, maar meer in het algemeen, hoewel je met Redis complexe datastructuren kunt weergeven, is het niet onmiddellijk. U moet goed nadenken over het model, zowel in termen van structuur als van gegevenstoegang (d.w.z. houd u tijdens het ontwerpen aan uw gegevens EN uw gebruiksscenario's).