Прав сте, че само прости структури от данни са налични с Redis и те не могат да бъдат съставени по стойност (както бихте могли да направите с ориентирана към документи база данни като CouchDB или MongoDB). Възможно е обаче да се съставят структури от данни чрез препратка и това е много често срещан модел.
Например, елементите, съдържащи се в набор, могат да бъдат ключовете за други обекти (списъци, хеш таблици, други набори и т.н. ...). Нека се опитаме да приложим това към вашия пример.
За да моделирате връзка между клиенти и устройство+порт, можете да използвате набори, съдържащи идентификатори на клиенти. За съхраняване на информация за клиентите е добре една хеш таблица на клиент.
Ето клиентите:
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
Ключовете на тези записи са c:ID
Нека свържем две от тях с устройство и порт:
sadd d:Los_Angeles:11 2 3
Ключът на този набор е d:device:port. Префиксите c:и d:са просто конвенция. Трябва да се създаде един набор за устройство/порт. Даден клиент може да принадлежи към няколко набора (и следователно да е свързан с няколко устройства/портове).
Сега, за да намерим клиентите с методи за доставка, свързани към това устройство/порт, просто трябва да извлечем съдържанието на комплекта.
smembers d:Los_Angeles:11
1) "2"
2) "3"
тогава съответната информация за клиента може да бъде извлечена чрез конвейериране на редица команди hgetall:
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"
Не се страхувайте от броя на командите. Те са много бързи и повечето клиенти на Redis имат способността да насочват заявките, така че да са необходими само минимален брой двупосочни пътувания. Като използвате само един smembers и няколко hgetall, проблемът може да бъде решен само с две двупосочни пътувания.
Сега е възможно да се оптимизира още малко, благодарение на вездесъщата команда SORT. Това е може би най-сложната команда в Redis и може да се използва за запазване на двупосочно пътуване тук.
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"
С една команда той извлича съдържанието на устройство/набор портове и извлича съответната информация за клиента.
Този пример беше тривиален, но по-общо казано, въпреки че можете да представяте сложни структури от данни с Redis, той не е непосредствен. Трябва внимателно да обмислите модела както по отношение на структурата, така и по отношение на достъпа до данни (т.е. по време на проектиране, придържайте се към данните си И вашите случаи на употреба).
