Anda benar bahwa hanya struktur data sederhana yang tersedia dengan Redis, dan struktur tersebut tidak dapat disusun berdasarkan nilai (seperti yang dapat Anda lakukan dengan database berorientasi dokumen seperti CouchDB atau MongoDB). Namun, dimungkinkan untuk menyusun struktur data dengan referensi, dan ini adalah pola yang sangat umum.
Misalnya, item-item yang terdapat dalam satu set dapat menjadi kunci untuk objek lain (daftar, tabel hash, set lain, dll ...). Mari kita coba terapkan ini pada contoh Anda.
Untuk memodelkan hubungan antara pelanggan dan port+perangkat, Anda dapat menggunakan set yang berisi ID pelanggan. Untuk menyimpan informasi tentang pelanggan, satu tabel hash per pelanggan tidak masalah.
Berikut pelanggannya:
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
Kunci dari catatan ini adalah c:ID
Mari kita kaitkan keduanya ke perangkat dan port:
sadd d:Los_Angeles:11 2 3
Kunci dari set ini adalah d:device:port. Awalan c:dan d:hanyalah sebuah konvensi. Satu set per perangkat/port harus dibuat. Pelanggan tertentu dapat menjadi bagian dari beberapa set (dan oleh karena itu terkait dengan beberapa perangkat/port).
Sekarang untuk menemukan pelanggan dengan metode pengiriman yang dilampirkan ke perangkat/port ini, kita hanya perlu mengambil konten set.
smembers d:Los_Angeles:11
1) "2"
2) "3"
maka informasi pelanggan yang sesuai dapat diambil dengan menyalurkan sejumlah perintah 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"
Jangan takut dengan jumlah perintah. Mereka sangat cepat, dan sebagian besar klien Redis memiliki kemampuan untuk menyalurkan kueri sehingga hanya diperlukan jumlah minimum bolak-balik. Dengan hanya menggunakan satu anggota dan beberapa hgetall, masalah tersebut dapat diselesaikan hanya dengan dua perjalanan pulang pergi.
Sekarang, dimungkinkan untuk mengoptimalkan sedikit lebih jauh, berkat perintah SORT yang ada di mana-mana. Ini mungkin perintah yang paling kompleks di Redis, dan dapat digunakan untuk menghemat perjalanan pulang pergi di sini.
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"
Dalam satu perintah, ia mengambil konten perangkat/port set dan mengambil informasi pelanggan yang sesuai.
Contoh ini sepele, tetapi lebih umum, sementara Anda dapat mewakili struktur data yang kompleks dengan Redis, itu tidak langsung. Anda perlu hati-hati memikirkan model baik dari segi struktur dan akses data (yaitu pada waktu desain, tetap berpegang pada data Anda DAN kasus penggunaan Anda).
