Desain key

Topik ini membahas konvensi penamaan key pada Redis, mulai dari pemisah titik dua, namespace per aplikasi dan modul, pola penamaan yang lazim, hingga pertimbangan panjang key. Redis menyimpan setiap key sebagai satu string tunggal tanpa pengelompokan bawaan, sehingga seluruh struktur yang tampak pada nama key merupakan kesepakatan yang dibangun di sisi aplikasi. Setelah membaca topik ini, skema penamaan key untuk sebuah aplikasi dapat dirancang secara konsisten, lengkap dengan alasannya. Seluruh contoh dijalankan dengan redis-cli menggunakan awalan app:, dan keluaran aslinya disertakan langsung.

Hierarki key dengan pemisah titik dua#

Konvensi penamaan yang paling luas digunakan di komunitas Redis menyusun nama key dari segmen-segmen yang dipisah tanda titik dua, dengan urutan objek:identitas:bidang. Key app:sesi:42 menandai session bernomor 42 pada segmen identitasnya. Segmen objek menyatakan jenis datanya, segmen identitas memilih satu entri di antara banyak entri yang serupa, dan segmen bidang menandai tujuan penyimpanan apabila satu objek memerlukan lebih dari satu key. Key app:produk:1750:cache mengikuti pola yang sama dengan segmen bidang berupa cache pada akhirnya.

Tanda titik dua dalam nama key hanyalah karakter biasa dan tidak diberi makna khusus oleh server. Redis menyimpan seluruh key dalam satu keyspace, yakni satu ruang penyimpanan key yang datar, sehingga tidak ada pohon direktori maupun hubungan induk dan anak di antara key yang tampak berjenjang. Dua key yang hanya berbeda pada segmen terakhirnya adalah dua key yang sepenuhnya berdiri sendiri. Contoh berikut menulis key sesi, membacanya kembali, lalu membaca nama induk yang tidak pernah dibuat.

# menulis key sesi dengan hierarki aplikasi, objek, dan identitas
redis-cli SET app:sesi:42 "Ali"
# membaca key tersebut kembali
redis-cli GET app:sesi:42
# membaca nama induk yang tidak pernah dibuat
redis-cli GET app:sesi

OK
Ali

Baris terakhir keluaran kosong karena app:sesi memang tidak pernah dibuat, sebagaimana key apa pun yang tidak ada. Keberjenjangan pada nama key bermanfaat bagi manusia dan alat, bukan bagi struktur internal server. Nama yang berjenjang mudah dibaca saat penelusuran masalah dan mudah dipilih sebagai satu kelompok melalui pola MATCH pada perintah SCAN, sehingga penulisan yang seragam sejak awal mempermudah pengelolaan di kemudian hari.

Namespace untuk mencegah tabrakan nama#

Sebuah namespace adalah awalan pada nama key yang menandai pemiliknya, misalnya nama aplikasi atau nama modul. Server Redis yang digunakan bersama oleh banyak aplikasi mudah mengalami tabrakan nama tanpa namespace, yaitu dua aplikasi menulis key dengan nama yang sama sehingga saling menimpa nilai tanpa peringatan. Segmen pertama pada konvensi topik ini, yaitu app, berperan sebagai namespace aplikasi, sedangkan segmen kedua memisahkan modul atau jenis data di dalamnya.

Namespace membuat dua modul yang menyimpan data untuk identitas yang sama tetap terpisah. Modul sesi dan modul kuis keduanya menyimpan data untuk nomor 42, tetapi key masing-masing berbeda karena segmen modulnya berbeda. Contoh berikut menulis key milik modul kuis, lalu membaca keduanya dalam satu permintaan MGET.

# modul kuis menyimpan hasil untuk identitas 42 pada namespace sendiri
redis-cli SET app:kuis:42 "skor 80"
# membaca kedua key dengan identitas sama dari modul berbeda
redis-cli MGET app:sesi:42 app:kuis:42

OK
Ali
skor 80

Keluaran di atas menunjukkan kedua key tetap berdiri sendiri meski segmen identitasnya sama. Tanpa namespace, modul kuis yang menulis key app:sesi:42 akan menimpa session pengguna 42 tanpa peringatan. Penimpaan semacam itu jarang menimbulkan pesan error, sehingga sulit dilacak, sedangkan pemisahan melalui namespace menghilangkan kemungkinan tersebut sejak key pertama dibuat.

Pola penamaan yang lazim#

Skema penamaan bekerja paling baik apabila setiap jenis data di aplikasi memiliki pola yang tetap. Pola yang tetap membuat nama key mudah ditebak saat dibaca dan mudah diperiksa kesesuaiannya. Tabel berikut memuat lima pola yang paling sering muncul beserta contoh key dan isinya.

Dua baris terakhir menunjukkan variasi yang sama pentingnya dengan pola dasarnya. Key rate-limit menyimpan parameter pengguna, yaitu alamat IP, pada segmen identitasnya sehingga batas permintaan dihitung terpisah untuk setiap alamat. Segmen bidang pada cache menyatakan tujuan key secara eksplisit, sehingga key data asli dan key cache untuk objek yang sama tidak tertukar.

Key yang mengikuti pola yang sama mudah diperlakukan sebagai satu kelompok. Tiga key sesi dengan bentuk yang sama dapat ditulis dalam satu perintah MSET, lalu dibaca kembali dalam satu perintah MGET. Contoh berikut menggunakan tiga key sesi milik pengguna yang berbeda.

# menulis tiga key sesi dalam satu perintah MSET
redis-cli MSET app:sesi:43 "Budi" app:sesi:44 "Citra" app:sesi:45 "Dewi"
# membaca ketiga key tersebut dalam satu perintah MGET
redis-cli MGET app:sesi:43 app:sesi:44 app:sesi:45

OK
Budi
Citra
Dewi

Penulisan dan pembacaan batch menghemat waktu bolak-balik jaringan karena tiga key ditangani dalam satu permintaan. Keuntungan semacam ini hanya muncul bila pola penamaannya seragam sejak awal, sehingga konvensi penamaan berperan sebagai fondasi bagi pola akses yang efisien.

Panjang key dan biaya memori#

Nama key tersimpan di memori server selama key itu ada, sehingga biayanya diperhitungkan pada setiap key tanpa terkecuali. Nilai dapat dipangkas atau dibuang melalui masa kedaluwarsa dan eviksi, tetapi nama key tetap diperlukan selama key tersebut masih dimaksudkan untuk disimpan, sehingga penghematannya hanya mungkin dengan memperpendek nama itu sendiri. Pada server dengan ratusan ribu key, kelebihan beberapa byte per nama key sudah menumpuk menjadi penggunaan memori yang terukur.

Ukuran nilai dan ukuran nama memengaruhi memori dengan cara yang berbeda. Nilai yang besar menjadi biaya satu key saja, sedangkan pola nama key yang panjang diperhitungkan ulang pada setiap key yang dibuat mengikuti pola itu. Karena itu nama key cukup mendeskripsikan isinya dengan jelas tanpa menjadi kalimat lengkap, misalnya app:sesi:42 sudah memadai tanpa tambahan kata seperti data atau penyimpanan.

Beberapa kebiasaan membantu menjaga nama key tetap pendek. Gunakan nomor identitas yang pendek dan hindari Universally Unique Identifier (UUID) yang panjangnya 36 karakter apabila aplikasi sudah memiliki nomor yang lebih pendek. Singkatan diperbolehkan asalkan tercantum pada dokumentasi konvensi sehingga maknanya sama untuk seluruh anggota tim. Bila jumlah key diperkirakan sangat besar, rata-rata panjang nama key patut dihitung sejak perancangan bersama perencanaan memori keseluruhan.

Ringkasan#

• Tanda titik dua adalah pemisah konvensi pada nama key, sedangkan server menyimpan seluruh key dalam keyspace yang datar tanpa hubungan induk dan anak.
• Namespace pada segmen awal menandai pemilik key dan mencegah tabrakan nama antar aplikasi maupun antar modul yang berbagi satu server.
• Pola penamaan yang tetap per jenis data membuat key mudah dipindai sebagai kelompok dan ditangani secara batch dengan MSET dan MGET.
• Nama key tersimpan di memori selama key ada, sehingga panjangnya dijaga pendek dengan tetap jelas, berbeda dari nilai yang boleh besar.

Referensi#

• Keyspace — Redis — Panduan resmi penyimpanan key yang memuat konvensi titik dua, saran skema objek:id, dan batas ukuran 512 MB.
• Data types — Redis — Tutorial resmi tipe data Redis sebagai latar penyimpanan nilai pada key.
• MSET — Redis — Dokumentasi resmi perintah MSET untuk menulis banyak key dalam satu panggilan atomik.
• MGET — Redis — Dokumentasi resmi perintah MGET untuk membaca banyak key sekaligus beserta balasan nil untuk key yang tidak ada.