Едно от нещата, които научавате бързо, докато работите с redis, е, че можете да проектирате структурата си от данни според нуждите си за достъп, особено когато става въпрос за връзки (в крайна сметка това не е релационна база данни)
Няма начин да търсите по "стойност" с времева сложност O(1), както вече забелязахте, но има начини да се доближите до това, което описвате с помощта на redis. Ето какво бих препоръчал:
- Съхранявайте потребителските си данни по потребителски идентификатор (напр. хеш), както вече правите.
- Да има допълнителен набор за всеки идентификатор на лектор, съдържащ всички потребителски идентификатори, които съответстват на въпросния идентификатор на лектора.
Това може да изглежда като дублиране на данните на връзката, тъй като вашите потребителски данни ще трябва да съхраняват идентификатора на лекцията, а данните от лекцията ще съхраняват потребителски идентификатори, но това е (малката) цена, която трябва да платите, ако човек трябва да изгради отношения в не -съхранение на релационни данни като redis. На практика това работи добре; паметта рядко е пречка за малки набори от данни (помислете за хиляди идентификатори).
За да получите по-добра представа за това как хората използват redis за моделиране на приложения с връзки, препоръчвам да прочетете Дизайн и внедряване на прост клонинг на Twitter и изходния код на Lamernews, като и двата са написани от автора на redis Салваторе Санфилипо.
