MongoDB dengan redis

Adakah yang bisa memberikan contoh kasus penggunaan kapan Anda akan mendapat manfaat dari penggunaan Redis dan MongoDB dalam hubungannya dengan satu sama lain?

Redis dan MongoDB dapat digunakan bersama dengan hasil yang baik. Sebuah perusahaan terkenal untuk menjalankan MongoDB dan Redis (bersama dengan MySQL dan Sphinx) adalah Craiglist. Lihat presentasi ini dari Jeremy Zawodny.

MongoDB menarik untuk persisten, berorientasi dokumen, data diindeks dengan berbagai cara. Redis lebih menarik untuk data volatil, atau data semi-persisten yang sensitif terhadap latensi.

Berikut adalah beberapa contoh penggunaan konkret Redis di atas MongoDB.

• Pra-2.2 MongoDB belum memiliki mekanisme kedaluwarsa. Koleksi yang dibatasi tidak dapat benar-benar digunakan untuk mengimplementasikan TTL yang sebenarnya. Redis memiliki mekanisme kedaluwarsa berbasis TTL, membuatnya nyaman untuk menyimpan data volatil. Misalnya, sesi pengguna biasanya disimpan di Redis, sedangkan data pengguna akan disimpan dan diindeks di MongoDB. Perhatikan bahwa MongoDB 2.2 telah memperkenalkan mekanisme kedaluwarsa dengan akurasi rendah di tingkat pengumpulan (untuk digunakan untuk menghapus data misalnya).

• Redis menyediakan tipe data set yang nyaman dan operasi terkaitnya (gabungan, persimpangan, perbedaan pada beberapa set, dll ...). Sangat mudah untuk mengimplementasikan mesin pencari atau penandaan segi dasar di atas fitur ini, yang merupakan tambahan yang menarik untuk kemampuan pengindeksan MongoDB yang lebih tradisional.

• Redis mendukung operasi pop pemblokiran yang efisien pada daftar. Ini dapat digunakan untuk menerapkan sistem antrian terdistribusi ad-hoc. Ini lebih fleksibel daripada IMO kursor tailable MongoDB, karena aplikasi backend dapat mendengarkan beberapa antrian dengan batas waktu, mentransfer item ke antrian lain secara atomik, dll ... Jika aplikasi memerlukan antrian, masuk akal untuk menyimpan antrian di Redis , dan pertahankan data fungsional yang persisten di MongoDB.

• Redis juga menawarkan mekanisme pub / sub. Dalam aplikasi terdistribusi, sistem perambatan peristiwa mungkin berguna. Ini sekali lagi merupakan kasus penggunaan yang sangat baik untuk Redis, sementara data persisten disimpan di MongoDB.

Karena jauh lebih mudah mendesain model data dengan MongoDB daripada dengan Redis (Redis lebih rendah levelnya), menarik untuk memanfaatkan fleksibilitas MongoDB untuk data persisten utama, dan dari fitur tambahan yang disediakan oleh Redis (latensi rendah , kedaluwarsa item, antrian, pub / sub, blok atom, dll ...). Ini memang kombinasi yang bagus.

Harap dicatat Anda tidak boleh menjalankan server Redis dan MongoDB di mesin yang sama. Memori MongoDB dirancang untuk ditukar, Redis tidak. Jika MongoDB memicu beberapa aktivitas swapping, kinerja Redis akan menjadi bencana besar. Mereka harus diisolasi pada node yang berbeda.

Jelas ada jauh lebih banyak perbedaan dari ini, tapi untuk gambaran yang sangat tinggi:

Untuk kasus penggunaan:

• Redis sering digunakan sebagai lapisan caching atau papan tulis bersama untuk komputasi terdistribusi.
• MongoDB sering digunakan sebagai pengganti swap-out untuk database SQL tradisional.

Secara teknis:

• Redis adalah db dalam memori dengan persistensi disk (seluruh db harus muat dalam RAM).
• MongoDB adalah db yang didukung disk yang hanya membutuhkan cukup RAM untuk indeks.

Ada beberapa tumpang tindih, tetapi sangat umum untuk menggunakan keduanya. Inilah alasannya:

• MongoDB dapat menyimpan lebih banyak data dengan lebih murah.
• Redis lebih cepat untuk seluruh kumpulan data.
• Budaya MongoDB adalah "simpan semuanya, cari tahu pola aksesnya nanti"
• Budaya Redis adalah "pertimbangkan dengan cermat bagaimana Anda akan mengakses data, lalu menyimpannya"
• Keduanya memiliki alat sumber terbuka yang bergantung padanya, banyak di antaranya digunakan bersama.

Redis dapat digunakan sebagai pengganti datastore tradisional, tetapi paling sering digunakan dengan penyimpanan data "panjang" normal lainnya, seperti Mongo, Postgresql, MySQL, dll.

Redis bekerja sangat baik dengan MongoDB sebagai server caching. Inilah yang terjadi.

Setiap kali luwak mengeluarkan kueri cache, pertama-tama ia akan masuk ke server cache.

Server cache akan memeriksa untuk melihat apakah kueri yang tepat itu pernah dikeluarkan sebelumnya.

Jika belum, maka server cache akan mengambil kueri tersebut, mengirimkannya ke mongodb dan Mongo akan menjalankan kueri tersebut.

Kami kemudian akan mengambil hasil dari kueri itu, lalu kembali ke server cache, server cache akan menyimpan hasil kueri itu sendiri.

Ini akan mengatakan setiap kali saya menjalankan kueri itu, saya mendapatkan respons ini dan karenanya akan mempertahankan catatan antara kueri yang dikeluarkan dan respons yang kembali dari kueri tersebut.

Server cache akan mengambil respon dan mengirimkannya kembali ke luwak, luwak akan memberikannya untuk diungkapkan dan akhirnya berakhir di dalam aplikasi.

Kapan pun kueri yang sama persis dikeluarkan lagi, luwak akan mengirim kueri yang sama ke server cache, tetapi jika server cache melihat bahwa kueri ini dikeluarkan sebelum itu tidak akan mengirim kueri ke mongodb, sebagai gantinya akan mengambil respons ke pertanyaan yang didapatnya terakhir kali dan segera mengirimkannya kembali ke luwak. Tidak ada indeks di sini, tidak ada pemindaian tabel lengkap, tidak ada.

Kami melakukan pencarian sederhana untuk mengatakan apakah kueri ini telah dieksekusi? Iya? Oke, terima permintaannya dan segera kirim kembali dan jangan kirim apapun ke mongo.

Kami memiliki server luwak, server cache (Redis) dan Mongodb.

Di server cache mungkin ada penyimpanan data dengan tipe nilai kunci penyimpanan data di mana semua kunci adalah beberapa jenis kueri yang diterbitkan sebelumnya dan nilai hasil kueri tersebut.

Jadi mungkin kami mencari banyak postingan blog oleh _id.

Jadi mungkin kunci di sini adalah _id dari record yang telah kita cari sebelumnya.

Jadi mari kita bayangkan bahwa luwak mengeluarkan kueri baru di mana ia mencoba menemukan posting blog dengan _id dari 123, kueri mengalir ke server cache, server cache akan memeriksa untuk melihat apakah itu memiliki hasil untuk kueri apa pun yang mencari _id dari 123.

Jika tidak ada di server cache, kueri ini diambil dan dikirim ke instance mongodb. Mongodb akan mengeksekusi query tersebut, mendapatkan respon dan mengirimkannya kembali.

Hasil ini dikirim kembali ke server cache yang mengambil hasil itu dan segera mengirimkannya kembali ke luwak sehingga kami mendapatkan tanggapan secepat mungkin.

Tepat setelah itu, server cache juga akan mengambil kueri yang dikeluarkan, dan menambahkannya ke kumpulan kueri yang telah dikeluarkan dan mengambil hasil kueri dan menyimpannya tepat di atas kueri.

Jadi kita dapat membayangkan bahwa di masa depan kita mengeluarkan kueri yang sama lagi, itu mengenai server cache, itu melihat semua kunci yang dimilikinya dan berkata oh saya sudah menemukan posting blog itu, tidak menjangkau mongo, itu hanya membutuhkan hasil kueri dan mengirimkannya langsung ke luwak.

Kami tidak melakukan logika kueri yang kompleks, tidak ada indeks, tidak ada yang seperti itu. Ini secepat mungkin. Ini adalah pencarian nilai kunci yang sederhana.

Itulah gambaran umum tentang cara kerja server cache (Redis) dengan MongoDB.

Sekarang ada masalah lain. Apakah kita menyimpan data dalam cache selamanya? Bagaimana cara kami memperbarui catatan?

Kami tidak ingin selalu menyimpan data di cache dan membaca dari cache.

Server cache tidak digunakan untuk tindakan tulis apa pun. Lapisan cache hanya digunakan untuk membaca data. Jika kita pernah menulis data, penulisan akan selalu menuju ke instance mongodb dan kita perlu memastikan bahwa setiap kali kita menulis data, kita menghapus data yang disimpan di cache server yang terkait dengan catatan yang baru saja kita perbarui di Mongo.