Yang saya inginkan bukanlah perbandingan antara Redis dan MongoDB. Saya tahu mereka berbeda; kinerja dan API sangat berbeda.

Redis sangat cepat, tetapi API sangat 'atomik'. MongoDB akan memakan lebih banyak sumber daya, tetapi API sangat sangat mudah digunakan, dan saya sangat senang dengannya.

Keduanya mengagumkan, dan saya ingin menggunakan Redis dalam penyebaran sebanyak yang saya bisa, tetapi sulit untuk dikodekan. Saya ingin menggunakan MongoDB dalam pengembangan sebanyak yang saya bisa, tetapi membutuhkan mesin yang mahal.

Jadi apa yang Anda pikirkan tentang penggunaan keduanya? Kapan memilih Redis? Kapan harus memilih MongoDB?

Saya akan mengatakan, itu tergantung pada jenis tim dev Anda dan kebutuhan aplikasi Anda.

Misalnya, jika Anda memerlukan banyak permintaan , itu sebagian besar berarti akan lebih sulit bagi pengembang Anda untuk menggunakan Redis, di mana data Anda mungkin disimpan dalam berbagai struktur data khusus, disesuaikan untuk setiap jenis objek untuk efisiensi. Di MongoDB, kueri yang sama mungkin lebih mudah karena strukturnya lebih konsisten di seluruh data Anda. Di sisi lain, di Redis, kecepatan respons terhadap pertanyaan-pertanyaan itu adalah imbalan untuk pekerjaan ekstra berurusan dengan berbagai struktur data Anda mungkin disimpan.

MongoDB menawarkan kesederhanaan, kurva belajar yang jauh lebih pendek untuk pengembang dengan pengalaman DB dan SQL tradisional. Namun, pendekatan non-tradisional Redis membutuhkan lebih banyak upaya untuk belajar, tetapi fleksibilitas yang lebih besar.

Misalnya. Sebuah Cache lapisan mungkin dapat lebih baik diterapkan di Redis. Untuk data yang lebih banyak skema, MongoDB lebih baik. [Catatan: baik MongoDB dan Redis secara teknis licik]

Jika Anda bertanya kepada saya, pilihan pribadi saya adalah Redis untuk sebagian besar persyaratan.

Terakhir, saya harap sekarang Anda telah melihat http://antirez.com/post/MongoDB-and-Redis.html

Saya hanya memperhatikan bahwa pertanyaan ini sudah cukup lama. Meskipun demikian, saya menganggap aspek-aspek berikut ini layak untuk ditambahkan:

• Gunakan MongoDB jika Anda belum tahu bagaimana Anda akan menanyakan data Anda.

  MongoDB cocok untuk Hackathons, startup atau setiap kali Anda tidak tahu bagaimana Anda akan meminta data yang Anda masukkan. MongoDB tidak membuat asumsi apa pun tentang skema dasar Anda. Sementara MongoDB adalah schemaless dan non-relasional, ini tidak berarti bahwa tidak ada skema sama sekali. Ini berarti bahwa skema Anda perlu didefinisikan dalam aplikasi Anda (misalnya menggunakan Mongoose). Selain itu, MongoDB sangat bagus untuk membuat prototipe atau mencoba berbagai hal. Kinerjanya tidak terlalu bagus dan tidak bisa dibandingkan dengan Redis.

• Gunakan Redis untuk mempercepat aplikasi Anda yang sudah ada.

  Redis dapat dengan mudah diintegrasikan sebagai cache LRU . Sangat jarang menggunakan Redis sebagai sistem database mandiri (beberapa orang lebih suka menyebutnya sebagai "nilai kunci" -store). Situs web seperti Craigslist menggunakan Redis di sebelah basis data utama mereka . Antirez (pengembang Redis) berdemonstrasi menggunakan Lamernews bahwa memang mungkin untuk menggunakan Redis sebagai sistem database yang berdiri sendiri.

• Redis tidak membuat asumsi apa pun berdasarkan data Anda.

  Redis menyediakan banyak struktur data yang berguna (mis. Set, Hash, Daftar), tetapi Anda harus secara eksplisit menentukan bagaimana Anda ingin menyimpan data Anda. Singkatnya, Redis dan MongoDB dapat digunakan untuk mencapai hal serupa. Redis lebih cepat, tetapi tidak cocok untuk prototyping. Itu adalah satu kasus penggunaan di mana Anda biasanya lebih suka MongoDB. Selain itu, Redis sangat fleksibel. Struktur data yang mendasarinya menyediakan blok bangunan sistem DB kinerja tinggi.

Kapan harus menggunakan Redis?

• Caching

  Caching menggunakan MongoDB tidak masuk akal. Itu akan terlalu lambat.

• Jika Anda punya cukup waktu untuk memikirkan desain DB Anda.

  Anda tidak bisa begitu saja memasukkan dokumen Anda ke Redis. Anda harus memikirkan cara Anda menyimpan dan mengatur data. Salah satu contoh adalah hash di Redis. Mereka sangat berbeda dari objek bersarang "tradisional", yang berarti Anda harus memikirkan kembali cara Anda menyimpan dokumen bersarang. Salah satu solusinya adalah dengan menyimpan referensi di dalam hash ke hash lain (sesuatu seperti kunci: [id hash kedua] ). Gagasan lain adalah menyimpannya sebagai JSON, yang tampaknya kontra-intuitif bagi kebanyakan orang dengan latar belakang * SQL.

• Jika Anda membutuhkan kinerja yang sangat tinggi.

  Mengalahkan kinerja yang disediakan Redis hampir tidak mungkin. Bayangkan database Anda menjadi secepat cache Anda. Seperti itulah rasanya menggunakan Redis sebagai basis data nyata .

• Jika Anda tidak peduli bahwa banyak tentang scaling.

  Scaling Redis tidak sesulit dulu. Misalnya, Anda dapat menggunakan semacam server proxy untuk mendistribusikan data di antara beberapa instance Redis. Replikasi master-budak tidak yang rumit, tetapi mendistribusikan Anda kunci di antara beberapa kebutuhan Redis-contoh yang harus dilakukan di situs aplikasi (misalnya menggunakan hash-fungsi, Modulo dll). Penskalaan MongoDB dengan perbandingan jauh lebih sederhana.

Kapan harus menggunakan MongoDB

• Prototyping, Startups, Hackathons

  MongoDB sangat cocok untuk pembuatan prototipe cepat. Namun demikian, kinerja tidak begitu baik. Juga perlu diingat bahwa kemungkinan besar Anda harus mendefinisikan semacam skema dalam aplikasi Anda.

• Ketika Anda perlu mengubah skema Anda dengan cepat.

  Karena tidak ada skema! Mengubah tabel dalam DBMS tradisional dan relasional sangat mahal dan lambat. MongoDB memecahkan masalah ini dengan tidak membuat banyak asumsi pada data dasar Anda. Namun demikian, ia mencoba untuk mengoptimalkan sejauh mungkin tanpa mengharuskan Anda untuk menentukan skema.

TL; DR - Gunakan Redis jika kinerjanya penting dan Anda bersedia menghabiskan waktu untuk mengoptimalkan dan mengatur data Anda. - Gunakan MongoDB jika Anda perlu membuat prototipe tanpa terlalu khawatir tentang DB Anda.

Bacaan lebih lanjut:

• Aspek menarik untuk dipertimbangkan saat menggunakan Redis sebagai penyimpan data primer

Redis. Katakanlah Anda telah menulis situs di php; untuk alasan apa pun, itu menjadi populer dan lebih maju dari waktu atau memiliki porno di atasnya. Anda menyadari php ini sangat lambat, "Saya akan kehilangan penggemar saya karena mereka tidak akan menunggu 10 detik untuk satu halaman." Anda tiba-tiba menyadari bahwa halaman web memiliki url konstan (tidak pernah berubah, whoa), kunci utama jika Anda mau, dan kemudian Anda ingat bahwa memori cepat sementara disk lambat dan php bahkan lebih lambat. :( Kemudian Anda membuat mekanisme penyimpanan menggunakan memori dan URL ini yang Anda panggil "kunci" sementara konten halaman web Anda memutuskan untuk memanggil "nilai." Hanya itu yang Anda miliki - kunci dan konten. Anda menyebutnya "meme cache." Anda suka Richard Dawkins karena dia luar biasa. Anda men-cache html Anda seperti tupai cache kacang mereka. Anda tidak perlu menulis ulang kode php omong kosong Anda. Anda senang. Kemudian Anda melihat bahwa orang lain telah melakukannya - tetapi Anda memilih Redis karena yang lain memiliki gambar kucing yang membingungkan, beberapa dengan taring.

Mongo. Anda telah menulis situs. Heck Anda sudah menulis banyak, dan dalam bahasa apa pun. Anda menyadari bahwa sebagian besar waktu Anda dihabiskan untuk menulis klausa SQL yang menyebalkan itu. Anda bukan dba, tetapi di sana Anda, menulis pernyataan sql yang bodoh ... bukan hanya satu tetapi panik di mana-mana. "pilih ini, pilih itu". Tetapi khususnya Anda ingat klausa WHERE yang menjengkelkan. Di mana nama belakang sama dengan "thornton" dan film sama dengan "santa buruk." Urgh. Anda berpikir, "mengapa dbas itu tidak hanya melakukan pekerjaan mereka dan memberi saya beberapa prosedur tersimpan?" Lalu Anda lupa beberapa bidang kecil seperti middlename dan kemudian Anda harus menghapus tabel, mengekspor semua 10G data besar dan membuat yang lain dengan bidang baru ini, dan mengimpor data - dan itu berlangsung 10 kali selama 14 hari ke depan saat Anda terus ingat omong kosong seperti salam, judul, ditambah menambahkan kunci asing dengan alamat. Maka Anda mengetahui bahwa nama belakang harus nama belakang. Hampir satu perubahan sehari. Lalu Anda mengatakan sialan. Saya harus melanjutkan dan menulis situs web / sistem, apalagi model data ini bs. Jadi Anda google, "Saya benci menulis SQL, tolong jangan SQL, buat itu berhenti" tetapi muncul 'nosql' dan kemudian Anda membaca beberapa hal dan mengatakan itu hanya membuang data tanpa skema. Anda ingat kegagalan minggu lalu menjatuhkan lebih banyak meja dan tersenyum. Maka Anda memilih mongo karena beberapa orang besar seperti 'airbud' situs sewa yang tepat menggunakannya. Manis. Tidak ada lagi perubahan model data karena Anda memiliki model yang terus Anda ubah.

Mungkin sumber daya ini bermanfaat membantu memutuskan di antara keduanya. Ini juga membahas beberapa database NoSQL lainnya, dan menawarkan daftar pendek karakteristik, bersama dengan penjelasan "apa yang akan saya gunakan untuk" masing-masing.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Pertanyaan sulit untuk dijawab - seperti halnya sebagian besar solusi teknologi, itu sangat tergantung pada situasi Anda dan karena Anda belum menggambarkan masalah yang Anda coba selesaikan, bagaimana orang bisa mengusulkan solusi?

Anda perlu menguji keduanya untuk melihat mana dari mereka yang memenuhi kebutuhan Anda .

Dengan itu, MongoDB tidak memerlukan perangkat keras yang mahal. Seperti solusi database lainnya, ini akan bekerja lebih baik dengan lebih banyak CPU dan memori tetapi tentu saja bukan keharusan - terutama untuk tujuan pengembangan awal.

Redis adalah penyimpanan data dalam memori , yang dapat mempertahankan statusnya ke disk (untuk mengaktifkan pemulihan setelah dimulai ulang). Namun, penyimpanan data dalam memori berarti ukuran penyimpanan data (pada satu node) tidak dapat melebihi total ruang memori pada sistem (RAM fisik + ruang swap). Pada kenyataannya, akan jauh lebih sedikit dari ini, karena Redis berbagi ruang itu dengan banyak proses lain pada sistem, dan jika itu menghabiskan ruang memori sistem itu kemungkinan akan dibunuh oleh sistem operasi.

Mongo adalah penyimpanan data berbasis disk , yang paling efisien ketika itu bekerja sesuai dengan RAM fisik (seperti semua perangkat lunak). Menjadi data berbasis disk berarti tidak ada batas intrinsik pada ukuran database Mongo, namun opsi konfigurasi, ruang disk yang tersedia, dan masalah lainnya dapat berarti bahwa ukuran basis data pada batas tertentu dapat menjadi tidak praktis atau tidak efisien.

Redis dan Mongo dapat dikelompokkan untuk ketersediaan tinggi, cadangan, dan untuk meningkatkan ukuran keseluruhan datastore.

Semua jawaban (pada saat penulisan ini) mengasumsikan masing-masing Redis, MongoDB, dan mungkin database relasional berbasis SQL pada dasarnya adalah alat yang sama: "menyimpan data". Mereka tidak mempertimbangkan model data sama sekali.

MongoDB: Data Kompleks

MongoDB adalah toko dokumen. Untuk membandingkan dengan database relasional yang digerakkan oleh SQL: database relasional menyederhanakan untuk file CSV yang diindeks, masing-masing file berupa tabel; penyimpanan dokumen menyederhanakan untuk mengindeks file JSON, setiap file menjadi dokumen, dengan beberapa file dikelompokkan bersama.

File JSON memiliki struktur yang mirip dengan file XML dan YAML, dan kamus seperti di Python, jadi pikirkan data Anda dalam hierarki semacam itu. Saat pengindeksan, struktur adalah kuncinya: Dokumen berisi kunci bernama, yang berisi dokumen lebih lanjut, array, atau nilai skalar. Pertimbangkan dokumen di bawah ini.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

Dokumen di atas memiliki kunci PhoneNumber.Mobile,, yang memiliki nilai 555 634-5789. Anda dapat mencari melalui kumpulan dokumen di mana kunci PhoneNumber.Mobile,, memiliki beberapa nilai; mereka diindeks.

Ia juga memiliki larik Accountsyang menampung banyak indeks. Hal ini dimungkinkan untuk query untuk dokumen mana Accountsberisi persis beberapa bagian dari nilai-nilai, semua dari beberapa bagian dari nilai-nilai, atau setiap beberapa subset dari nilai-nilai. Itu berarti Anda dapat mencari Accounts = ["379-1111", "379-2574"]dan tidak menemukan yang di atas; Anda dapat mencari Accounts includes ["379-1111"]dan menemukan dokumen di atas; dan Anda dapat mencari Accounts includes any of ["974-3785","414-6731"]dan menemukan dokumen di atas dan apa pun yang termasuk akun "974-3785", jika ada.

Dokumen masuk sedalam yang Anda inginkan. PhoneNumber.Mobiledapat menyimpan array, atau bahkan sub-dokumen ( PhoneNumber.Mobile.Workdan PhoneNumber.Mobile.Personal). Jika data Anda sangat terstruktur, dokumen merupakan langkah besar dari database relasional.

Jika sebagian besar data Anda datar, relasional, dan terstruktur kaku, Anda lebih baik dengan database relasional. Sekali lagi, tanda besarnya adalah apakah model data Anda paling baik untuk koleksi file CSV yang saling terkait atau koleksi file XML / JSON / YAML.

Untuk sebagian besar proyek, Anda harus berkompromi, menerima penyelesaian kecil di beberapa area kecil di mana SQL atau Document Store tidak cocok; untuk beberapa proyek besar dan kompleks yang menyimpan penyebaran data yang luas (banyak kolom; baris tidak relevan), masuk akal untuk menyimpan beberapa data dalam satu model dan data lain dalam model lain. Facebook menggunakan SQL dan basis data grafik (tempat data dimasukkan ke dalam node, dan node terhubung ke node lain); Craigslist digunakan untuk menggunakan MySQL dan MongoDB, tetapi telah mencari untuk pindah sepenuhnya ke MongoDB. Ini adalah tempat di mana rentang dan hubungan data menghadapi cacat signifikan jika diletakkan di bawah satu model.

Redis: Nilai-Kunci

Redis, pada dasarnya, adalah toko kunci-nilai. Redis memungkinkan Anda memberikan kunci dan mencari nilai tunggal. Redis sendiri dapat menyimpan string, daftar, hash, dan beberapa hal lainnya; Namun, hanya mencari nama.

Cache invalidation adalah salah satu masalah sulit ilmu komputer; yang lainnya adalah penamaan. Itu berarti Anda akan menggunakan Redis ketika Anda ingin menghindari ratusan pencarian berlebih ke back-end, tetapi Anda harus mencari tahu kapan Anda membutuhkan pencarian baru.

Kasus pembatalan yang paling jelas adalah pembaruan saat menulis: jika Anda membaca user:Simon:lingots = NOTFOUND, Anda dapat SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simondan menyimpan hasilnya 100,, sebagai SET user:Simon:lingots = 100. Kemudian ketika Anda penghargaan Simon 5 lingots, Anda membaca user:Simon:lingots = 100, SET user:Simon:lingots = 105dan UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Sekarang Anda memiliki 105 di database Anda dan di Redis, dan bisa dapatkan user:Simon:lingotstanpa meminta database.

Kasus kedua adalah memperbarui informasi dependen. Katakanlah Anda menghasilkan potongan halaman dan menyimpan hasilnya. Header menunjukkan pengalaman pemain, level, dan jumlah uang; halaman Profil pemain memiliki blok yang menunjukkan statistik mereka; Dan seterusnya. Pemain mendapatkan beberapa pengalaman. Nah, sekarang Anda memiliki beberapa templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, dan sebagainya ladang di mana Anda cache output dari database setengah lusin query dijalankan melalui mesin template. Biasanya, ketika Anda menampilkan halaman-halaman ini, Anda mengatakan:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

Karena Anda baru saja memperbarui hasil GetStatsFromDatabase("Simon"), Anda harus templates:*:Simonkeluar dari cache nilai kunci Anda. Ketika Anda mencoba merender salah satu templat ini, aplikasi Anda akan menghasilkan data dari database Anda (PostgreSQL, MongoDB) dan memasukkannya ke dalam templat Anda; maka itu akan menyimpan hasilnya di Redis dan, mudah-mudahan, tidak repot-repot membuat query database dan rendering template saat nanti menampilkan blok output itu.

Redis juga memungkinkan Anda melakukan antrian pesan berlangganan penerbit dan semacamnya. Itu topik lain sepenuhnya. Intinya di sini adalah Redis adalah cache nilai kunci, yang berbeda dari database relasional atau penyimpanan dokumen.

Kesimpulan

Pilih alat Anda berdasarkan kebutuhan Anda. Kebutuhan terbesar biasanya adalah model data, karena itu menentukan seberapa kompleks dan rawan kesalahan kode Anda. Aplikasi khusus akan bersandar pada kinerja, tempat di mana Anda menulis semuanya dalam campuran C dan Assembly; sebagian besar aplikasi hanya akan menangani case umum dan menggunakan sistem caching seperti Redis atau Memcached, yang jauh lebih cepat daripada database SQL kinerja tinggi atau toko dokumen.

Dan Anda sebaiknya tidak menggunakan keduanya jika Anda memiliki banyak RAM. Redis dan MongoDB datang ke harga alat tujuan umum. Ini memperkenalkan banyak overhead.

Ada yang mengatakan bahwa Redis 10 kali lebih cepat dari Mongo. Itu mungkin tidak benar lagi. MongoDB (jika saya ingat dengan benar) diklaim dapat mengalahkan memcache untuk menyimpan dan menyimpan dokumen selama konfigurasi memori sama.

Bagaimanapun. Redis bagus, MongoDB bagus. Jika Anda peduli tentang substruktur dan perlu agregasi, pergilah ke MongoDB. Jika menyimpan kunci dan nilai-nilai adalah perhatian utama Anda semua tentang Redis. (atau toko nilai kunci lainnya).

Redis dan MongoDB keduanya merupakan basis data non-relasional tetapi mereka dari kategori yang berbeda.

Redis adalah database Key / Value, dan menggunakan penyimpanan dalam memori yang membuatnya sangat cepat. Ini adalah kandidat yang baik untuk caching barang dan penyimpanan data sementara (dalam memori) dan karena sebagian besar platform cloud (seperti Azure, AWS) mendukungnya, penggunaan memorinya dapat diskalakan. Tetapi jika Anda akan menggunakannya pada mesin Anda dengan sumber daya terbatas, pertimbangkan penggunaan memori.

MongoDB di sisi lain, adalah basis data dokumen. Ini adalah pilihan yang baik untuk menyimpan teks besar, gambar, video, dll dan hampir semua yang Anda lakukan dengan database kecuali transaksi. Misalnya jika Anda ingin mengembangkan blog atau jejaring sosial, MongoDB adalah pilihan yang tepat. Ini scalable dengan strategi skala-out. Menggunakan disk sebagai media penyimpanan, sehingga data akan tetap ada.

Jika proyek Anda bergerak memungkinkan Anda memiliki cukup memori RAM di lingkungan Anda - jawabannya adalah Redis. Terutama dengan mempertimbangkan Redis 3.2 baru dengan fungsi klaster.