Een van de dingen die u snel leert tijdens het werken met redis, is dat u uw gegevensstructuur kunt ontwerpen rond uw toegangsbehoeften, vooral als het gaat om relaties (het is tenslotte geen relationele database)
Er is geen manier om te zoeken op "waarde" met een O(1) tijdcomplexiteit zoals je al hebt opgemerkt, maar er zijn manieren om te benaderen wat je beschrijft met redis. Dit is wat ik zou aanraden:
- Bewaar uw gebruikersgegevens op gebruikers-ID (in bijvoorbeeld een hash) zoals u al doet.
- Zorg voor een extra set voor elke docent-ID met alle gebruikers-ID's die overeenkomen met de betreffende docent-ID.
Dit lijkt misschien op het dupliceren van de gegevens van de relatie, aangezien uw gebruikersgegevens de lezing-ID zouden moeten opslaan en uw lezingsgegevens gebruikers-ID's zouden opslaan, maar dat is de (kleine) prijs die moet worden betaald als men relaties wil opbouwen in een nee -relationele gegevensopslag zoals redis. In de praktijk werkt dit goed; geheugen is zelden een bottleneck voor kleine datasets (denk aan duizenden ID's).
Om een beter beeld te krijgen van hoe mensen redis gebruiken om applicaties met relaties te modelleren, raad ik aan om Ontwerp en implementatie van een eenvoudige Twitter-kloon en de broncode van Lamernews te lezen, die beide zijn geschreven door redis-auteur Salvatore Sanfilippo.