Ответ 1
Одна из вещей, которые вы быстро изучаете при работе с redis, заключается в том, что вы можете проектировать свою структуру данных вокруг ваших потребностей доступа, особенно когда дело касается отношений (это не реляционная база данных)
Невозможно выполнить поиск по "значению" с временной сложностью O (1), как вы уже заметили, но есть способы приблизиться к описанию с помощью redis. Вот что я бы рекомендовал:
- Сохраняйте свои пользовательские данные по идентификатору пользователя (например, хэшу), как вы уже делаете.
- У вас есть дополнительный набор для каждого идентификатора лектора, содержащий все идентификаторы пользователей, которые соответствуют идентификатору лектора.
Это может показаться дублирующим данные отношения, так как ваши пользовательские данные должны будут хранить идентификатор лекции, а ваши данные лекций будут хранить идентификаторы пользователей, но что (крошечная) цена для оплаты, если нужно строить отношения в нереляционном хранилище данных, таком как redis. На практике это работает хорошо; память редко является узким местом для небольших наборов данных (думаю, тысячи идентификаторов).
Чтобы получить более полное представление о том, как люди, использующие redis для моделирования приложений с отношениями, рекомендую читать Разработка и внедрение простого тэга Twitter и исходный код Lamernews, оба из которых написаны автором redis Сальваторе Санфилиппо.