Эффективная таблица поиска в redis - реализована с использованием наборов redis?

Question

Я хочу использовать redis для хранения большого набора user_ids и с каждым из этих идентификаторов, «групповым идентификатором», которому этот пользователь был ранее назначен:

User_ID | Group_ID
   1043 | 2 
   2403 | 1

Количество user_ids довольнобольшой (~ 10 миллионов);число уникальных идентификаторов групп составляет около 3 - 5.

Моя цель для этого LuT - обычная процедура:

• найти идентификатор группы для данного пользователя ;и

• возвращает список других пользователей (указанной длины) с тем же идентификатором группы, что и у данного пользователя

Там может быть идиоматический способ сделать это в Redis или, по крайней мере, способ, который является наиболее эффективным.Если это так, я хотел бы знать, что это такое.Вот упрощенная версия моей рабочей реализации (с использованием клиента Python):

# assume a redis server is already running 
# create some model data:
import numpy as NP
NUM_REG_USERS = 100
user_id = NP.random.randint(1000, 9999, NUM_REG_USERS)
cluster_id = NP.random.randint(1, 4, NUM_REG_USERS)
D = zip(cluster_id, user_id)

from redis import Redis
# r = Redis()

# populate the redis LuT:
for t in D :
    r.sadd( t[0], t[1] )

# the queries:
# is user_id 1034 in Group 1?
r.sismember("1", 1034)

# return 10 users in the same Group 1 as user_id 1034:
r.smembers("1")[:10]     # assume user_id 1034 is in group 1

Итак, я реализовал этот LuT, используя обычные redis sets ;каждый набор привязан к идентификатору группы (1, 2 или 3), поэтому всего имеется три набора.

Является ли это наиболее эффективным способом хранения этих данных, учитывая тип запросов, к которым я хочу выполнитьэто?

Answer 1

Использование наборов является хорошим базовым подходом, хотя есть несколько вещей, которые вы можете изменить:

Если вы не сохраните идентификатор группы для каждого пользователя, вам потребуется 5 рейсов в оба конца.получить группу для конкретного пользователя - самой операцией является O (1), но вам все равно нужно учитывать задержку.Обычно это довольно легко сделать без особых усилий - у вас есть множество других свойств, сохраненных для каждого пользователя, поэтому добавить тривиальное для идентификатора группы тривиально.

Возможно, вы захотите SRANDMEMBER, а не SMEMBERS - ядумаю, что SMEMBERS каждый раз будет возвращать одни и те же 10 предметов из вашего миллиона предметов.