Anda seharusnya tidak peduli dengan eksekusi perintah saat ini, tetapi tentang dampaknya terhadap semua perintah lainnya, karena Redis memproses perintah menggunakan satu utas (yaitu saat sebuah perintah sedang dieksekusi, semua yang lain harus menunggu sampai mengeksekusi satu utas).
Sementara keys atau scan mungkin memberi Anda kinerja serupa atau identik yang dijalankan sendiri dalam kasus Anda, beberapa milidetik memblokir Redis akan secara signifikan mengurangi keseluruhan I/O.
Ini alasan utama untuk menggunakan keys untuk tujuan pengembangan dan scan pada lingkungan produksi.
OP berkata:
"Sementara kunci atau pemindaian mungkin memberikan Anda kinerja yang serupa atau identik yang dijalankan sendiri dalam kasus Anda, beberapa milidetik memblokir Redis akan secara signifikan mengurangi keseluruhan I/O." - Kalimat ini tampaknya menunjukkan bahwa satu perintah memblokir Redis, dan yang lainnya tidak, yang tidak mungkin terjadi. Jika saya dijamin 100 hasil dari panggilan saya ke KEYS, dalam hal apa itu lebih buruk daripada SCAN? Mengapa Anda merasa bahwa satu perintah lebih rentan terhadap pemblokiran?
Seharusnya ada perbedaan yang baik ketika Anda dapat membuat halaman pencarian. Tidaklah sama dipaksa untuk mendapatkan 100 kunci dalam sekali jalan daripada mampu mengimplementasikan pagination dan mendapatkan 100 kunci, 10 kali 10 (atau 50 dan 50). Gangguan yang sangat kecil ini dapat membuat perintah lain yang dikirim oleh lapisan aplikasi diproses oleh Redis . Lihat apa yang dikatakan dokumentasi resmi Redis tentang ini:
Karena perintah ini memungkinkan untuk iterasi tambahan, mengembalikan hanya sejumlah kecil elemen per panggilan, mereka dapat digunakan dalam produksi tanpa kerugian dari perintah seperti KEYS atau SMEMBERS yang dapat memblokir server untuk waktu yang lama (bahkan beberapa detik) ketika dipanggil terhadap kumpulan kunci yang besar atau elemen
.
