Pemilihan proyek

Topik ini menetapkan beban kerja untuk proyek terpandu pada modul pengerjaan proyek, yaitu leaderboard yang tersaji secara real-time untuk portal kuis sebuah kelas. Pemilihan dilakukan dengan empat kriteria, yaitu anggaran latensi baca dan tulis, tingkat kesamaan data antar pengguna, volume data, serta durasi hidup data. Setiap kandidat beban kerja dinilai terhadap keempat kriteria tersebut, kemudian satu kandidat dipilih beserta alasannya. Uji kecocokan kecil dijalankan pada redis-cli di akhir topik untuk menunjukkan bahwa kebutuhan papan terjawab langsung oleh Redis. Seluruh contoh dijalankan pada server Redis 8.0.2 di port 6379 menggunakan key berawalan kuis:, sehingga keluarannya dapat direproduksi ulang.

Empat kriteria pemilihan beban kerja#

Kriteria pertama adalah anggaran latensi, yaitu batas waktu yang dinyatakan secara eksplisit untuk setiap operasi yang sering terjadi. Anggaran ditulis sebagai angka dan menjadi bagian dari persyaratan proyek, misalnya papan terbaru harus tampil dalam waktu kurang dari 100 milidetik sejak permintaan diterima. Angka semacam ini berstatus target, bukan hasil pengukuran, sehingga kepatuhannya diperiksa ulang pada tahap implementasi. Tanpa angka yang tertulis, pernyataan cepat atau lambat tidak dapat dinilai kebenarannya.

Kriteria kedua adalah tingkat kesamaan data antar pengguna. Data yang isinya sama untuk seluruh pengguna, seperti papan peringkat kelas, dibaca banyak klien sekaligus sehingga satu salinan di server memadai. Data yang isinya berbeda untuk setiap pengguna, seperti session login, tidak memperoleh manfaat dari kesamaan tersebut. Kriteria ketiga adalah volume data, yaitu perkiraan jumlah key dan ukuran nilainya pada puncak penggunaan. Kriteria keempat adalah durasi hidup data, yaitu berapa lama data masih bernilai sebelum boleh dihapus atau dibiarkan kedaluwarsa. Empat kriteria ini digunakan bersama karena kandidat yang unggul pada satu kriteria belum tentu unggul pada kriteria lainnya.

Anggaran latensi proyek#

Proyek kuis kelas menetapkan dua anggaran latensi. Papan terbaru tampil kurang dari 100 milidetik sejak permintaan diterima, dan pencatatan satu jawaban benar selesai kurang dari 50 milidetik. Kedua angka ditetapkan dari kebutuhan tampilan kelas, yaitu layar papan yang dimuat ulang setiap beberapa detik dan jawaban yang dikirim ketika siswa menekan tombolnya. Anggaran tulis dipasang lebih longgar daripada anggaran baca karena pencatatan jawaban hanya terjadi sekali per jawaban, sedangkan pembacaan papan terjadi pada setiap muat ulang layar. Nilai 100 milidetik juga menyisakan ruang bagi waktu tempuh di jaringan, sehingga bagian terbesar anggaran tetap tersedia untuk pemrosesan di server.

Redis mendukung kedua anggaran tersebut dari dua sisi. Seluruh data disimpan di memori, dan urutan sorted set dijaga pada saat penulisan, sehingga pembacaan papan tidak memerlukan penyortiran tambahan di sisi aplikasi. Kesesuaian anggaran dengan perilaku server diperiksa kembali pada tahap implementasi, dan seluruh angka pada topik ini berstatus target yang ditetapkan lebih dahulu.

Membandingkan kandidat beban kerja#

Empat kandidat beban kerja dinilai terhadap keempat kriteria, yaitu leaderboard, session, antrean pekerjaan, dan pencarian teks penuh. Tabel berikut merangkum kesesuaian masing-masing kandidat untuk proyek kuis kelas beserta alasannya.

Leaderboard terpilih karena memenuhi keempat kriteria sekaligus. Data papan sama untuk seluruh siswa sehingga tingkat kesamaannya tinggi, volumenya kecil karena belasan peserta per kelas menghasilkan satu key dengan anggota sebanyak jumlah peserta, dan durasi hidupnya mengikuti berlangsungnya kuis. Penulisan skor terjadi bertahap setiap jawaban benar dicatat, sedangkan pembacaan papan terjadi setiap layar siswa dimuat. Ketimpangan frekuensi baca dan tulis semacam ini adalah pola yang paling diuntungkan oleh struktur yang urutannya sudah dirawat server, karena biaya penyortiran dibayar sekali pada saat penulisan dan bukan pada setiap pembacaan.

Uji kecocokan di redis-cli#

Uji kecocokan memeriksa klaim pada tabel dengan beberapa perintah nyata. Key papan diisi dengan ZADD berisi skor contoh untuk keempat peserta, kemudian dibaca utuh dengan ZREVRANGE beserta opsi WITHSCORES. Perintah TYPE membaca tipe kedua key untuk menunjukkan bahwa key papan dan key meta berdiri sendiri, karena key meta memang belum dibuat pada uji ini. Penulisan skor pada proyek sesungguhnya dilakukan bertahap dengan ZINCRBY sebagaimana kontrak datanya, sedangkan ZADD pada uji ini hanya menyiapkan nilai contoh.

# membersihkan key proyek agar uji selalu dimulai dari keadaan kosong
redis-cli del kuis:papan:kuis-01 kuis:meta:kuis-01 >/dev/null
# mengisi key papan dengan skor contoh keempat peserta
redis-cli zadd kuis:papan:kuis-01 30 Ali 20 Budi 30 Citra 10 Dewi
# membaca papan lengkap dalam urutan menurun beserta skornya
redis-cli zrevrange kuis:papan:kuis-01 0 -1 withscores
# membaca tipe key papan dan key meta yang belum dibuat
redis-cli type kuis:papan:kuis-01
redis-cli type kuis:meta:kuis-01

4
Citra
30
Ali
30
Budi
20
Dewi
10
zset
none

Keluaran memperlihatkan papan terurut menurun tanpa penyortiran di sisi aplikasi. Citra dan Ali sama-sama menyimpan skor 30, dan keduanya tampil dengan Citra lebih dahulu karena pembalikan urutan papan ikut membalik urutan nama pada anggota yang berskor sama. Balasan zset mengonfirmasi key papan bertipe sorted set, sedangkan balasan none untuk key meta menegaskan bahwa key itu memang belum dibuat. Struktur ini sejalan dengan anggaran latensi baca karena satu perintah tunggal sudah mengembalikan papan lengkap beserta skornya tanpa penyortiran maupun pembacaan key lain.

Kesalahan umum#

Kesalahan pertama adalah menetapkan anggaran latensi tanpa dasar, misalnya menyalin angka dari aplikasi lain. Angka yang tidak berasal dari kebutuhan tampilan membuat hasil implementasi tidak dapat dinilai, dan perbaikannya adalah menghitung ulang angka dari frekuensi muat ulang layar papan. Kesalahan kedua adalah memilih struktur data karena kelengkapan perintahnya, bukan karena kecocokannya dengan kriteria. Beban kerja yang tidak memiliki urutan yang dibutuhkan bersama oleh banyak pembaca tidak memperoleh manfaat sorted set, sehingga keputusannya perlu diuji ulang dengan empat kriteria pada topik ini. Kesalahan ketiga adalah mengabaikan durasi hidup data sehingga key uji tertinggal di server setelah kelas usai. Kebiasaan tersebut menumpuk key yang tidak lagi dibaca siapa pun, dan perbaikannya berada pada kontrak data, yaitu mencatat kapan key dibersihkan beserta pihak yang bertanggung jawab atas pembersihannya.

Ringkasan#

• Pemilihan beban kerja menggunakan empat kriteria, yaitu anggaran latensi, tingkat kesamaan data antar pengguna, volume data, dan durasi hidup data.
• Proyek kuis kelas menetapkan papan terbaru tampil kurang dari 100 milidetik dan pencatatan jawaban selesai kurang dari 50 milidetik sebagai target.
• Dari empat kandidat, leaderboard terpilih karena data yang sama untuk seluruh siswa, volume yang kecil, frekuensi baca yang jauh melebihi tulis, dan durasi hidup yang mengikuti berlangsungnya kuis.
• Uji kecocokan pada redis-cli memperlihatkan papan terbaca terurut dari satu perintah ZREVRANGE, dengan key papan bertipe zset dan key meta belum dibuat.

Referensi#

• Sorted sets — Redis — Dokumentasi tipe data sorted set yang menjadi dasar kandidat leaderboard.
• ZADD — Redis — Perintah pengisian skor contoh pada uji kecocokan beserta balasannya.
• ZREVRANGE — Redis — Pembacaan papan dalam urutan menurun beserta opsi WITHSCORES.
• TYPE — Redis — Pembacaan tipe key beserta balasan none untuk key yang tidak ada.
• Data types — Redis — Ringkasan struktur data Redis yang menjadi kandidat beban kerja lain seperti list dan stream.