sql >> Database teknologi >  >> NoSQL >> Redis

Har brug for hjælp til konceptualisering i Redis/NoSQL

Du har ret i, at kun simple datastrukturer er tilgængelige med Redis, og de kan ikke sammensættes efter værdi (som du kunne gøre med en dokumentorienteret database som CouchDB eller MongoDB). Det er dog muligt at sammensætte datastrukturer ved reference, og det er et meget almindeligt mønster.

For eksempel kan de elementer, der er indeholdt i et sæt, være nøglerne til andre objekter (lister, hash-tabeller, andre sæt osv...). Lad os prøve at anvende dette på dit eksempel.

For at modellere et forhold mellem kunder og enhed+port kan du bruge sæt, der indeholder kunde-id'er. For at gemme oplysninger om kunderne er en hash-tabel pr. kunde fint.

Her er kunderne:

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

Nøglerne til disse poster er c:ID

Lad os knytte to af dem til en enhed og port:

sadd d:Los_Angeles:11 2 3

Nøglen til dette sæt er d:device:port. Præfikserne c:og d:er kun en konvention. Der skal oprettes ét sæt pr. enhed/port. En given kunde kan tilhøre flere sæt (og derfor tilknyttet flere enheder/porte).

For nu at finde kunder med leveringsmetoder knyttet til denne enhed/port, skal vi bare hente indholdet af sættet.

smembers d:Los_Angeles:11
1) "2"
2) "3"

så kan den tilsvarende kundeinformation hentes ved at pipeline en række hgetall-kommandoer:

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"

Vær ikke bange for antallet af kommandoer. De er meget hurtige, og de fleste Redis-klienter har evnen til at pipeline forespørgslerne, så der kun er behov for et minimum antal returflyvninger. Ved blot at bruge en smembers og flere hgetall, kan problemet løses med kun to roundtrips.

Nu er det muligt at optimere lidt yderligere takket være den allestedsnærværende SORT-kommando. Dette er sandsynligvis den mest komplekse kommando i Redis, og den kan bruges til at gemme en rundrejse her.

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"

I én kommando henter den indholdet af en enhed/portsæt og henter de tilsvarende kundeoplysninger.

Dette eksempel var trivielt, men mere generelt, mens du kan repræsentere komplekse datastrukturer med Redis, er det ikke umiddelbart. Du skal nøje tænke over modellen både med hensyn til struktur og dataadgang (dvs. på designtidspunktet, hold dig til dine data OG dine use cases).




  1. Mongoose Unikt indeks virker ikke!

  2. Inside Santander's Near Real-Time Data Ingest Architecture (del 2)

  3. mongoose forskel på findOneAndUpdate og opdatering

  4. MongoDB Performance:Kørsel af MongoDB Map-Reduce Operations på sekundære