Redis
 sql >> Teknologi Basis Data >  >> NoSQL >> Redis

Mengonfigurasi redis untuk secara konsisten mengeluarkan data lama terlebih dahulu

AFAIK, tidak mungkin mengonfigurasi Redis untuk secara konsisten mengeluarkan data lama terlebih dahulu.

Ketika opsi *-ttl atau *-lru dipilih dalam maxmemory-policy, Redis tidak menggunakan algoritme yang tepat untuk memilih kunci yang akan dihapus. Algoritme yang tepat akan memerlukan daftar tambahan (untuk *-lru) atau tumpukan ekstra (untuk *-ttl) dalam memori, dan referensi silang dengan struktur data kamus Redis normal. Akan mahal dalam hal konsumsi memori.

Dengan mekanisme saat ini, evictions terjadi di loop peristiwa utama (yaitu, eviction potensial diperiksa pada setiap iterasi loop sebelum setiap perintah dieksekusi). Sampai memori kembali di bawah batas memori maksimum, Redis secara acak mengambil sampel n kunci, dan memilih untuk kedaluwarsa yang paling menganggur (untuk *-lru) atau yang paling dekat dengan batas kedaluwarsanya (untuk *-ttl). Secara default hanya 3 sampel yang dipertimbangkan. Hasilnya tidak deterministik.

Salah satu cara untuk meningkatkan akurasi algoritme ini dan mengurangi masalah adalah dengan meningkatkan jumlah sampel yang dipertimbangkan (parameter maxmemory-samples dalam file konfigurasi). Jangan menyetelnya terlalu tinggi, karena akan menghabiskan sebagian CPU. Ini adalah tradeoff antara akurasi penggusuran dan konsumsi CPU.

Sekarang jika Anda benar-benar membutuhkan perilaku yang konsisten, salah satu solusinya adalah menerapkan mekanisme pengusiran Anda sendiri di atas Redis. Misalnya, Anda dapat menambahkan daftar (untuk kunci yang tidak dapat diperbarui) atau kumpulan yang diurutkan (untuk kunci yang dapat diperbarui) untuk melacak kunci yang harus dikeluarkan terlebih dahulu. Kemudian, Anda menambahkan daemon yang tujuannya adalah untuk secara berkala memeriksa (menggunakan INFO) konsumsi memori dan menanyakan item dari daftar/set yang diurutkan untuk menghapus kunci yang relevan.

Harap dicatat sistem caching lain memiliki cara mereka sendiri untuk mengatasi masalah ini. Misalnya dengan memcached, ada satu struktur LRU per slab (yang bergantung pada ukuran objek), sehingga urutan eviction juga tidak akurat (walaupun lebih deterministik dibandingkan dengan Redis dalam praktiknya).




  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Benchmark Couchbase mengungkapkan INSERT dan GET yang sangat lambat (menggunakan operasi KeyValue); lebih lambat dari data MySQL yang bertahan

  2. Tidak bisa mendapatkan koneksi Jedis; Tidak bisa mendapatkan sumber daya dari kumpulan

  3. .NET Core menyuntikkan layanan singleton di layanan singleton lain

  4. Mengapa SQLite lebih cepat daripada Redis dalam benchmark sederhana ini?

  5. Cara mengatur penangan di RedMQ dari acara yang diangkat di domain saya