Kapan menggunakan CouchDB di atas MongoDB dan sebaliknya

638

Saya terjebak di antara dua database NoSQL ini.

Dalam proyek saya, saya akan membuat basis data di dalam basis data. Sebagai contoh, saya butuh solusi untuk membuat tabel dinamis.

Jadi pengguna dapat membuat tabel dengan kolom dan baris. Saya pikir MongoDB atau CouchDB akan bagus untuk ini, tapi saya tidak yakin yang mana. Saya juga perlu paging yang efisien juga.

— Luke101
sumber

19

Saya berharap mereka akan memodifikasi sistem untuk lebih memudahkan pembuatan pertanyaan tentang topik yang mereka cari, dan untuk mengarahkan pengguna yang lebih baik ke pertanyaan itu. Saya tidak tahu apakah pertanyaan ini pernah diatasi dan tidak ada cara mudah untuk melacaknya.

— doub1ejack

45

Saya berharap mereka akan menambahkan fungsionalitas di situs web ini di mana kita dapat "meningkatkan" atau "menurunkan" alasan itu sendiri yang diberikan untuk pertanyaan ini sebagai "di luar topik" yang mungkin membantu mengembalikan jenis pertanyaan ini kembali ke "pada topik".

— Sanjay

9

++ Tidak jelas bagi saya mengapa ini di luar topik. Pertanyaannya memang memiliki jawaban obyektif yang jelas - OP tidak meminta pendapat tetapi untuk informasi obyektif tentang kedua sistem ini. user799188 memberikan jawaban objektif yang bagus.

— user48956

3

Saya kira admin hanya melihat pertanyaan jika berisi potongan kode dan bukan pada jenis informasi yang dicari .. Btw Anda selalu dapat memilih untuk membuka kembali pertanyaan.

— Tarun

11

Pertanyaannya baru saja dibuka kembali. Selamat datang kembali, semuanya ...

— Alexis Dufrenoy

523

Dari C, A & P (Konsistensi, Ketersediaan & Toleransi partisi) mana 2 yang lebih penting bagi Anda? Referensi cepat, Panduan Visual Ke Sistem NoSQL

MongodB: Konsistensi dan Toleransi Partisi
CouchDB: Ketersediaan dan Toleransi Partisi

Sebuah posting blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j perbandingan memiliki skenario ' Terbaik digunakan ' untuk setiap database NoSQL dibandingkan. Mengutip tautan,

MongoDB: Jika Anda membutuhkan kueri dinamis. Jika Anda lebih suka menentukan indeks, bukan memetakan / mengurangi fungsi. Jika Anda membutuhkan kinerja yang baik pada DB besar. Jika Anda menginginkan CouchDB, tetapi data Anda terlalu banyak berubah, mengisi disk.
CouchDB: Untuk mengakumulasikan, terkadang mengubah data, yang menjalankan kueri yang telah ditentukan sebelumnya. Tempat di mana pembuatan versi penting.

Perbandingan terkini (Feb 2012) dan lebih komprehensif oleh Riyad Kalla,

MongoDB: Replikasi Master-Slave SAJA
CouchDB: Replikasi Master-Master

Sebuah posting blog (Okt 2011) oleh seseorang yang mencoba keduanya, A MongoDB Guy Learns CouchDB mengomentari halaman CouchDB yang tidak berguna.

Benchmark tanggal (Juni 2009) oleh Kristina Chodorow ( bagian dari tim di belakang MongoDB ),

Saya akan memilih MongoDB.

Semoga ini bisa membantu.

— pengguna799188
sumber

8

Dari apa yang saya mengerti MongoDB tidak konsisten dengan cara apa pun: ivoras.sharanet.org/blog/tree/…

— sheerun

2

Info bagus untuk saat ini, tetapi ini benar-benar tua ... banyak yang telah berubah (termasuk antarmuka REST untuk Mongo).

— rICh

4

Saya pikir itu mungkin agak menyesatkan, tetapi versi di couchdb bukan argumen. Skema versi yang digunakan oleh couchdb tidak boleh digunakan sebagai versi per katakan. Ini digunakan untuk menangani partisi. Selama pemadatan basis data, revisi akan terhapus seperti pada yang benar-benar dihapus. Dan hanya rantai putaran yang harus tetap berada dalam database. Jika Anda ingin menangani versi di couchdb, itu harus dilakukan sama seperti yang bisa dilakukan di mongodb.

— Loïc Faure-Lacroix

2

Saya akan menambahkan ke daftar bahwa couchdb dapat memiliki aplikasi web mandiri. Seperti pada couchdb sebenarnya adalah server web.

— Loïc Faure-Lacroix

41

Saya terkejut 332 orang untuk jawaban yang salah. MongoDB adalah CP secara default dan CouchDB adalah AP stackoverflow.com/questions/11292215/…

— adnan kamili

219

Jawaban di atas memperumit cerita.

Jika Anda berencana memiliki komponen seluler, atau membutuhkan pengguna desktop untuk bekerja offline dan kemudian menyinkronkan pekerjaan mereka ke server, Anda memerlukan CouchDB.
Jika kode Anda hanya akan berjalan di server, lanjutkan dengan MongoDB

Itu dia. Kecuali Anda membutuhkan kemampuan CouchDB (luar biasa) untuk mereplikasi ke perangkat seluler dan desktop, MongoDB memiliki keunggulan kinerja, komunitas, dan peralatan saat ini.

— Ewan Makepeace
sumber

18

Ringkas, mereka sangat suka.

— Ely

Saya suka jawaban sederhana yang tidak terlalu teknis seperti ini. Terima kasih!

jawaban ini cocok untuk mereka yang mencari ponsel, offline, dan sinkron! terima kasih

— Erik Kaplun

Saya tertawa ketika membaca "replikasi ke perangkat seluler" lol seberapa kecil data Anda?

— Daniel W.

3

"lol, seberapa sedikit data Anda?" - Apakah itu benar-benar benda? Saya mungkin memilih CDB karena data saya besar - atau saya mungkin memilihnya karena memiliki replikasi yang lebih baik daripada alternatifnya. Dalam hal ini kami memfilter dataset hingga sekitar 100Mb-200Mb per perangkat. Itu adalah hal yang buruk?

— Ewan Makepeace

62

Pertanyaan yang sangat lama tetapi ada di atas Google dan saya tidak begitu suka jawaban yang saya lihat jadi ini milik saya.

Ada lebih banyak hal untuk Couchdb daripada kemampuan untuk mengembangkan CouchApps. Kebanyakan orang menggunakan CouchDb dalam arsitektur web 3-tier klasik.

Dalam praktiknya, faktor penentu bagi kebanyakan orang adalah kenyataan bahwa MongoDb memungkinkan kueri ad-hoc dengan sintaks seperti SQL sementara CouchDb tidak (Anda harus membuat peta / mengurangi tampilan yang membuat sebagian orang mati meskipun membuat tampilan ini ramah pengembangan aplikasi cepat - tidak ada hubungannya dengan prosedur tersimpan)

Untuk mengatasi poin yang muncul dalam jawaban yang diterima: CouchDb memiliki sistem versi yang bagus, tetapi itu tidak berarti bahwa itu hanya cocok (atau lebih cocok) untuk tempat-tempat di mana versi penting. Juga, couchdb sangat ramah terhadap penulisan karena sifatnya yang hanya menambahkan (operasi menulis kembali dalam waktu singkat sambil menjamin bahwa tidak ada data yang akan hilang).

Satu hal yang sangat penting yang tidak disebutkan oleh siapa pun adalah fakta bahwa CouchDb bergantung pada indeks b-tree. Ini berarti apakah Anda memiliki 1 "baris" atau 20 miliar, waktu kueri akan selalu tetap di bawah 10 ms. Ini adalah pengubah permainan yang menjadikan CouchDb basis data latensi rendah dan ramah-baca, dan ini benar-benar tidak boleh diabaikan.

Agar adil dan lengkap, keuntungan yang dimiliki MongoDb atas CouchDb adalah perkakas dan pemasaran. Mereka memiliki alat warga negara kelas satu untuk semua bahasa dan platform utama yang mempermudah penggunaannya dan ini ditambahkan ke permintaan adhoc mereka membuat transisi dari SQL menjadi lebih mudah.

CouchDb tidak memiliki tingkat perkakas ini - meskipun ada banyak perpustakaan yang tersedia saat ini - tetapi CouchDb diekspos sebagai HTTP API dan karena itu cukup mudah untuk membuat pembungkus dalam bahasa favorit Anda untuk berbicara dengannya. Saya pribadi menyukai pendekatan ini karena menghindari mengasapi dan memungkinkan Anda untuk hanya mengambil apa yang Anda inginkan (prinsip pemisahan antarmuka).

Jadi saya akan mengatakan menggunakan satu atau yang lain sebagian besar adalah masalah kenyamanan dan preferensi dengan paradigma mereka. Pendekatan CouchDb "pas", untuk orang-orang tertentu, tetapi jika setelah mempelajari tentang fitur basis data (secara lengkap) panduan resmi ) Anda tidak memiliki momen "neraka ya", Anda mungkin harus melanjutkan.

Saya tidak ingin menggunakan CouchDb jika Anda hanya ingin menggunakan "alat yang tepat untuk pekerjaan yang tepat". karena Anda akan tahu bahwa Anda tidak bisa menggunakannya begitu saja dan Anda akan marah dan menulis posting blog seperti "Di mana bergabung di CouchDb?" dan "Di mana manajemen transaksi?". Memang Couchdb adalah - secara paradoks - sangat transparan tetapi pada saat yang sama membutuhkan perubahan paradigma dan perubahan dalam cara Anda mendekati masalah untuk benar-benar bersinar (dan benar-benar berfungsi).

Tetapi begitu Anda selesai melakukannya, itu akan bermanfaat. Saya pribadi membutuhkan alasan yang sangat kuat atau pemecah masalah besar pada suatu proyek untuk memilih database lain, tetapi sejauh ini saya belum pernah bertemu.

— tobiak777
sumber

12

Pembaruan 2016: Sejak versi 2.0 dirilis pada september 2016, CouchDb mendukung permintaan ad-hoc di luar kotak :)

— tobiak777

1

CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms.

Bukankah ini berlaku untuk hampir semua database? Dengan cara ini ungkapan ini menyatakan sebaliknya.

— Shelvacu

38

Ajukan pertanyaan ini sendiri? Dan Anda akan memutuskan pilihan DB Anda.

Apakah Anda membutuhkan master-master ? Lalu CouchDB. Terutama CouchDB mendukung replikasi master-master yang mengantisipasi node terputus untuk jangka waktu yang lama. MongoDB tidak akan bekerja dengan baik di lingkungan itu.
Apakah Anda memerlukan throughput MAKSIMUM R / W ? Lalu MongoDB
Apakah Anda memerlukan daya tahan server tunggal yang luar biasa karena Anda hanya akan memiliki satu server DB? Lalu CouchDB.
Apakah Anda menyimpan kumpulan data MASSIVE yang perlu sharding sambil mempertahankan throughput yang gila? Lalu MongoDB.
Apakah Anda memerlukan konsistensi data yang kuat ? Lalu MongoDB.
Apakah Anda memerlukan ketersediaan database yang tinggi? Lalu CouchDB.
Apakah Anda berharap multi database dan multi tabel / koleksi? Lalu MongoDB
Anda memiliki pengguna offline aplikasi seluler dan ingin menyinkronkan data aktivitas mereka ke server? Maka Anda membutuhkan CouchDB.
Apakah Anda memerlukan berbagai macam mesin pencarian ? Lalu MongoDB
Apakah Anda memerlukan komunitas besar untuk menggunakan DB? Lalu MongoDB

— Somnath Muluk
sumber

# 9 adalah ikatan virtual antara CouchDB dan MongoDB pada CouchDB 2.x.

— Flimzy

27

Saya merangkum jawaban yang ditemukan dalam artikel itu:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-keuntungan-dan-kekurangan-of- masing-masing

MongoDB: Permintaan yang lebih baik, penyimpanan data di BSON (akses lebih cepat), konsistensi data yang lebih baik, beberapa koleksi

CouchDB: Replikasi yang lebih baik, dengan replikasi master dan master dan resolusi konflik, penyimpanan data dalam JSON (dapat dibaca oleh manusia, akses yang lebih baik melalui layanan REST), kueri melalui pengurangan peta.

Jadi kesimpulannya, MongoDB lebih cepat, CouchDB lebih aman.

Juga: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

— Alexis Dufrenoy
sumber

7

Jawaban yang berguna, tetapi kesimpulannya sulit untuk disukai.

— Erik Kaplun

Apa yang Anda maksud dengan "sulit disukai"?

— Alexis Dufrenoy

23

Waspadai masalah dengan indeks unik yang jarang di MongoDB. Saya telah memukulnya dan itu sangat rumit untuk diselesaikan.

Masalahnya adalah ini - Anda memiliki bidang, yang unik jika ada dan Anda ingin menemukan semua objek di mana bidang tersebut tidak ada. Cara jarang indeks unik diimplementasikan dalam Mongo adalah bahwa objek di mana bidang yang hilang tidak ada dalam indeks sama sekali - mereka tidak dapat diambil oleh kueri di bidang itu - {$exists: false}hanya tidak berfungsi.

Satu-satunya solusi yang saya buat adalah memiliki keluarga nol khusus nilai, di mana nilai kosong diterjemahkan ke awalan khusus (seperti null :) yang disatukan dengan uuid. Ini benar-benar sakit kepala, karena kita harus berhati-hati mengubah ke / dari nilai kosong saat menulis / quering / membaca. Gangguan besar.

Saya tidak pernah menggunakan eksekusi javascript sisi server di MongoDB (tidak disarankan pula) dan peta / pengurangannya memiliki kinerja yang buruk ketika hanya ada satu simpul Mongo. Karena semua alasan ini saya sekarang mempertimbangkan untuk memeriksa CouchDB, mungkin lebih cocok untuk skenario khusus saya.

BTW, jika ada yang tahu tautan ke masalah Mongo masing-masing yang menggambarkan masalah indeks unik yang jarang - silakan bagikan.

— menandai
sumber

3

Maaf, tapi saya punya firasat bahwa itu bukan ide yang baik dan perasaan yang saya pelajari untuk tidak diabaikan

— eaglestorm

8

Yah, aku tidak bisa berdebat dengan perasaan. Yang saya tahu adalah bahwa saya perlu indeks unik jarang, karena bidang opsional, yang unik jika ada.

— tandai

37

Saya mengerti Anda memiliki kasus penggunaan aktual yang menjelaskan masalah ini, tetapi bagaimana dengan usus saya?

— Chev

14

Saya tidak tahu. Bagaimana dengan itu?

— tandai

2

ROTFL. +1 Alex Ford & tandai untuk komentar lucu Anda. :-)) @mark, saya tidak yakin bahwa masalah yang Anda daftarkan benar-benar membenarkan peralihan dari MongoDB ke CouchDB. Saya telah bekerja dengan baik MongoDB maupun CouchDB, tetapi nyali saya memberi tahu saya bahwa Anda akan mengalami beberapa batasan kompleks dengan CouchDB, dan membuang waktu lagi untuk mengatasinya. Jika sekarang Anda sudah menguasai MongoDB, maka Anda mungkin harus tetap menggunakannya. Tapi sekali lagi, saya belum pernah ke Nosql-tanah, ini hanya usus saya berbicara.

— MiniQuark

6

Saya yakin Anda bisa dengan Mongo (lebih akrab dengannya), dan cukup yakin Anda bisa dengan sofa juga.

Keduanya berorientasi pada dokumen (berbasis JSON) sehingga tidak akan ada "kolom" melainkan bidang dalam dokumen - tetapi keduanya bisa sepenuhnya dinamis.

Mereka berdua melakukannya, Anda mungkin ingin melihat faktor-faktor lain yang digunakan: fitur-fitur lain yang Anda pedulikan, popularitas, dll. Google wawasan, posting pekerjaan sesungguhnya.com akan menjadi cara untuk melihat popularitas.

Anda bisa mencobanya, saya pikir Anda harus dapat menjalankan mongo dalam 5 menit.

— dm.
sumber