Desain data

Topik ini membahas perancangan struktur data, key, dan TTL proyek leaderboard kuis kelas, lalu merangkum keputusannya sebagai kontrak data yang menjadi rujukan tahap implementasi. Dua key dirancang dengan tanggung jawab yang terpisah, yaitu kuis:papan:kuis-01 untuk isi papan dan kuis:meta:kuis-01 untuk informasi kuis yang dikelola guru. Keluaran utama topik ini berupa tabel kontrak data, tabel operasi beserta kompleksitasnya, dan satu sesi tulis-baca lengkap di redis-cli. Seluruh contoh dijalankan pada server Redis 8.0.2 di port 6379, dan papan diisi melalui kenaikan tetap sepuluh poin agar setiap keluaran deterministik dan dapat dihitung ulang.

Dua key dengan tanggung jawab berbeda#

Papan dan meta disimpan pada dua key yang terpisah karena keduanya memiliki penulis, pembaca, dan frekuensi akses yang berbeda. Key papan bertipe sorted set dengan anggota berupa nama peserta dan skor berupa poin kumulatif, ditulis aplikasi setiap jawaban benar dicatat. Key meta bertipe hash dengan field judul, jumlah_soal, dan status, ditulis guru ketika kuis disiapkan dan ketika kuis berakhir. Key papan dibaca setiap kali layar siswa memuat papan, sedangkan key meta dibaca jauh lebih jarang untuk menampilkan judul dan menentukan apakah kuis masih berjalan.

Pemisahan tersebut juga melindungi data dari perubahan yang tidak diminta. Aplikasi kuis tidak pernah menulis field meta, dan guru tidak pernah menyentuh skor peserta, sehingga kesalahan pada satu sisi tidak menjalar ke sisi lainnya. Nama kedua key mengikuti konvensi penamaan dengan pemisah titik dua pada jalur ini, yaitu segmen namespace kuis, segmen objek, lalu segmen identitas kuis-01 untuk kuis pertama. Kuis kedua di kemudian hari menggunakan key dengan identitas kuis-02 tanpa mengubah struktur apa pun.

Kontrak data proyek#

Kontrak data merangkum keputusan perancangan dalam satu tabel yang mengikat tahap implementasi. Setiap baris memuat nama key, tipe, penulis, pembaca, isi, skala, dan aturan TTL. Tabel berikut memuat kontrak lengkap untuk proyek kuis kelas.

Skor pada papan selalu berupa kelipatan sepuluh karena setiap jawaban benar bernilai tetap, yaitu sepuluh poin. Nilai yang tetap ini menjadikan papan deterministik, artinya urutan dan skornya dapat dihitung ulang dari daftar jawaban tanpa menjalankan ulang kuisnya. Field status bernilai berjalan atau selesai, dan nilainya menentukan apakah aplikasi masih menerima pencatatan jawaban. Segmen identitas kuis-01 menyatukan kedua key pada kuis yang sama, sehingga dua baris pada tabel sudah mencakup seluruh key proyek. Kedua key hidup tanpa TTL selama kuis berjalan, sedangkan pembersihannya diatur sebagai klausul tersendiri pada bagian akhir hidup data.

Operasi dan kompleksitasnya#

Setiap aksi pada proyek dipetakan ke satu perintah utama beserta kompleksitas kasarnya menurut dokumentasi resmi. Notasi N menyatakan jumlah anggota pada papan atau jumlah field pada hash, sedangkan M menyatakan jumlah anggota yang dikembalikan oleh satu perintah baca. Kompleksitas pada tabel dimaksudkan untuk membandingkan urutan besar antar perintah, dan bukan untuk memperkirakan waktu tempuh dalam satuan milidetik.

Kompleksitas tersebut menjelaskan mengapa pembacaan papan yang paling sering tetap terjangkau anggaran latensi. Papan dengan belasan peserta memiliki N yang kecil, sehingga biaya logaritmiknya nyaris konstan pada skala kelas. Aksi tulis tidak pernah memerlukan pembacaan skor lama lebih dahulu karena ZINCRBY menambahkan nilai relatif langsung di server. ZREVRANGE memang mengembalikan seluruh anggota, dan yang dibayar pada bagian M adalah jumlah anggota yang dikembalikan, sedangkan HGETALL pada meta hanya melibatkan tiga field sehingga biayanya dapat diabaikan.

Sesi tulis dan baca lengkap#

Sesi berikut mengeksekusi kontrak dari awal sampai akhir di redis-cli. Blok pertama membersihkan key milik proyek dengan pola awalannya, menulis meta, lalu mencatat sembilan jawaban benar dari tiga putaran soal. Ali dan Citra menjawab benar tiga kali, Budi dua kali, dan Dewi satu kali, sehingga skor akhirnya 30, 30, 20, dan 10. Setiap ZINCRBY mengembalikan skor terbaru pesertanya, sehingga keberhasilan pencatatan terlihat tanpa perintah tambahan.

# membersihkan seluruh key proyek agar sesi dimulai dari keadaan kosong
redis-cli --scan --pattern 'kuis:*' | xargs -r redis-cli del >/dev/null
# guru menulis meta kuis pada key hash
redis-cli hset kuis:meta:kuis-01 judul "Kuis Matematika Kelas 8" jumlah_soal 3 status berjalan
# putaran pertama: Ali dan Citra menjawab benar
redis-cli zincrby kuis:papan:kuis-01 10 Ali
redis-cli zincrby kuis:papan:kuis-01 10 Citra
# putaran kedua: Ali, Budi, dan Citra menjawab benar
redis-cli zincrby kuis:papan:kuis-01 10 Ali
redis-cli zincrby kuis:papan:kuis-01 10 Budi
redis-cli zincrby kuis:papan:kuis-01 10 Citra
# putaran ketiga: Ali, Budi, Citra, dan Dewi menjawab benar
redis-cli zincrby kuis:papan:kuis-01 10 Ali
redis-cli zincrby kuis:papan:kuis-01 10 Budi
redis-cli zincrby kuis:papan:kuis-01 10 Citra
redis-cli zincrby kuis:papan:kuis-01 10 Dewi

3
10
10
20
10
20
30
20
30
10

Blok kedua membaca hasilnya sebagaimana aplikasi papan membacanya, lalu menutup kuis dengan perubahan status.

# papan lengkap dalam urutan menurun beserta skornya
redis-cli zrevrange kuis:papan:kuis-01 0 -1 withscores
# peringkat pribadi Ali dan Dewi, dihitung mulai dari nol
redis-cli zrevrank kuis:papan:kuis-01 Ali
redis-cli zrevrank kuis:papan:kuis-01 Dewi
# seluruh field meta kuis
redis-cli hgetall kuis:meta:kuis-01
# sisa masa hidup kedua key saat kuis berjalan
redis-cli ttl kuis:papan:kuis-01
redis-cli ttl kuis:meta:kuis-01
# guru menandai kuis selesai lalu membaca statusnya kembali
redis-cli hset kuis:meta:kuis-01 status selesai
redis-cli hget kuis:meta:kuis-01 status

Citra
30
Ali
30
Budi
20
Dewi
10
1
3
judul
Kuis Matematika Kelas 8
jumlah_soal
3
status
berjalan
-1
-1
0
selesai

Keluaran ZREVRANGE memperlihatkan Citra dan Ali sama-sama berada pada skor 30, dan keduanya tersusun dengan Citra lebih dahulu karena pembalikan urutan papan ikut membalik urutan nama pada anggota yang berskor sama. Balasan ZREVRANK untuk Ali adalah 1, dan nomor peringkat yang ditampilkan aplikasi adalah balasan ditambah satu, yaitu dua. Nilai TTL keduanya -1 menegaskan kontrak bahwa tidak ada masa hidup yang dipasang saat kuis berjalan, sedangkan balasan 0 pada HSET status menandakan field lama diperbarui dan bukan field baru.

Akhir hidup data#

TTL tidak dipasang pada kedua key selama kuis berjalan karena kedaluwarsa bekerja diam-diam, yaitu key yang habis masa hidupnya hilang tanpa pesan error, dan papan yang hilang di tengah kuis tidak dapat dipulihkan dari server. Durasi hidup data pada proyek ini karenanya ditentukan oleh keputusan, bukan oleh pengatur waktu. Setelah kelas usai dan nilai direkap, pembersihan dilakukan dengan SCAN beserta pola kuis:* lalu DEL atas hasil pemindaian, dan pihak yang menjalankannya dicantumkan pada kontrak. Perintah berikut mengeksekusi klausul pembersihan tersebut, kemudian memastikan kedua key sudah tidak ada.

# membersihkan seluruh key proyek setelah nilai direkap
redis-cli --scan --pattern 'kuis:*' | xargs -r redis-cli del >/dev/null
# kedua key tidak ada lagi
redis-cli type kuis:papan:kuis-01
redis-cli type kuis:meta:kuis-01

none
none

Keluaran none pada kedua baris menegaskan bahwa kedua key sudah terhapus dan tidak ada key lain yang terbawa pembersihan, karena pola kuis:* hanya mencocokkan awalan milik proyek ini. Rekap nilai pada praktiknya disalin ke media lain sebelum pembersihan dijalankan, karena setelah DEL dieksekusi, isi papan tidak dapat dibaca kembali dari server. Klausul pembersihan melengkapi baris-baris kontrak sebelumnya, sehingga seluruh siklus hidup data tercatat dari pembuatan sampai penghapusan.

Kesalahan umum#

Kesalahan pertama adalah mengisi papan dengan ZADD ketika skor bertambah bertahap. ZADD menimpa skor dengan nilai mutlak, sehingga dua pencatatan yang hampir bersamaan saling mengganti hasil dan papan kehilangan poin. Perbaikannya adalah menggunakan ZINCRBY yang menambahkan nilai relatif langsung di server sebagaimana kontrak ini. Kesalahan kedua adalah menyimpan skor setiap peserta pada key string terpisah, lalu menyortir seluruhnya di aplikasi setiap papan diminta. Pola itu memindahkan pekerjaan penyortiran ke setiap permintaan dan menuntut banyak pembacaan key, sedangkan satu sorted set menyerahkan urutan kepada server. Kesalahan ketiga adalah memasang TTL pada key meta di tengah kuis dengan anggapan memori akan lebih hemat. Key yang kedaluwarsa hilang tanpa pesan error, dan judul beserta status kuis ikut hilang, sehingga masa hidup data hanya boleh diubah melalui revisi kontrak.

Ringkasan#

• Kontrak proyek terdiri atas dua key, yaitu sorted set kuis:papan:kuis-01 untuk skor kumulatif dan hash kuis:meta:kuis-01 untuk field judul, jumlah_soal, serta status.
• Skor ditulis dengan ZINCRBY bernilai tetap sepuluh, sehingga papan akhir Ali 30, Budi 20, Citra 30, dan Dewi 10 dapat dihitung ulang dari daftar jawabannya.
• Operasi utama berskala O(log N) menurut dokumentasi, dan anggota yang berskor sama tersusun menurut nama terbalik ketika papan dibaca terbalik.
• Kedua key hidup tanpa TTL saat kuis berjalan, dan pembersihannya dilakukan dengan SCAN berpola kuis:* setelah nilai direkap.

Referensi#

• Sorted sets — Redis — Dokumentasi tipe data sorted set beserta aturan urutan anggota yang berskor sama.
• Hashes — Redis — Dokumentasi tipe data hash yang menjadi dasar key meta beserta operasi field-nya.
• ZINCRBY — Redis — Semantik kenaikan skor relatif beserta balasan skor terbaru dan kompleksitasnya.
• ZREVRANK — Redis — Peringkat menurun yang dihitung mulai dari nol beserta kompleksitasnya.
• HSET — Redis — Semantik penulisan field hash beserta balasan jumlah field yang benar-benar baru.