luwak vs mongodb (modul / ekstensi nodejs), mana yang lebih baik? dan mengapa?


109

Saya baru saja tiba di Node.js dan melihat bahwa ada banyak lib untuk digunakan dengan MongoDB, yang paling populer tampaknya adalah dua ini: (mongoose dan mongodb). Bisakah saya mendapatkan pro dan kontra dari ekstensi tersebut? Apakah ada alternatif yang lebih baik untuk keduanya?

Sunting: Menemukan perpustakaan baru yang tampaknya juga menarik node-mongolian dan "Mongolian DeadBeef adalah driver node.js DB Mongo mengagumkan yang mencoba untuk mendekati shell mongodb." (readme.md)

https://github.com/marcello3d/node-mongolian

Ini hanya untuk menambahkan lebih banyak sumber daya ke orang-orang baru yang melihat ini, jadi pada dasarnya Mongolia itu seperti ODM ...


Mengapa menggunakan lapisan skema untuk database tanpa skema. Jika Anda ingin database berbasis skema, gunakan sesuatu yang lain yang dibuat untuk itu. (Mongoose hanyalah abstraksi skema dari mongodb)
Simon Dragsbæk

Jawaban:


123

Mongoose adalah level yang lebih tinggi dan menggunakan driver MongoDB (ini adalah dependensi, periksa package.json), jadi Anda akan menggunakannya dengan cara apa pun jika diberikan opsi tersebut. Pertanyaan yang harus Anda tanyakan pada diri sendiri adalah, "Apakah saya ingin menggunakan driver mentah, atau apakah saya memerlukan alat pemodelan dokumen objek?" Jika Anda mencari alat pemodelan objek (ODM, mitra ORM dari dunia SQL) untuk melewati beberapa pekerjaan tingkat yang lebih rendah, Anda ingin Mongoose.

Jika Anda menginginkan driver, karena Anda bermaksud melanggar banyak aturan yang mungkin diberlakukan oleh ODM, gunakan MongoDB. Jika Anda menginginkan pengemudi yang cepat, dan dapat hidup dengan beberapa fitur yang hilang, cobalah DeadBeef Mongolia: https://github.com/marcello3d/node-mongolian


34

Luwak, sejauh ini, adalah yang paling populer. Saya menggunakannya, dan belum menggunakan yang lain. Jadi saya tidak dapat berbicara tentang yang lain, tetapi saya dapat memberi tahu Anda keluhan saya dengan Mongoose.

  • Dokumentasi yang sulit / buruk
  • Model digunakan. Dan mereka menentukan struktur untuk dokumen Anda. Namun ini tampak aneh bagi Mongo di mana salah satu keuntungannya adalah Anda dapat memasukkan kolom (err, atribut?) Atau tidak menambahkannya.
  • Model peka huruf besar-kecil - Saya dan pengembang lain yang saya tangani memiliki masalah di mana kasus nama koleksi yang didefinisikan model dapat menyebabkannya tidak menyimpan apa pun, tanpa kesalahan. Kami telah menemukan bahwa menggunakan semua nama huruf kecil bekerja paling baik. Misalnya daripada melakukan sesuatu seperti mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })itu lebih baik dilakukan (meskipun nama koleksi benar-benar MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Tapi sejujurnya, ini sangat berguna. Masalah terbesar adalah dokumentasinya. Itu ada di sana, tetapi kering dan sulit menemukan apa yang Anda butuhkan. Itu bisa menggunakan penjelasan yang lebih baik dan lebih banyak contoh. Tapi begitu Anda melewati hal-hal ini, itu bekerja dengan sangat baik.


11
Re: dokumentasi. Saya sangat setuju. Dokumentasinya buruk dan juga memperburuk keadaan, salah di beberapa tempat. Saya sering menemukan diri saya memecahkan kode (yang bukan hal yang buruk), tetapi karena masalah dokumentasi.
JP Richardson

1
Nama koleksi AFAIK peka huruf besar / kecil dalam bahasa Mongo, bukan Mongoose.
Nick Campbell

34
Jika ada yang bertanya-tanya, dokumentasinya cukup bagus sekarang.
Kevin Beal

7
Saya tidak setuju, Dokumentasi masih terlambat.
Steve K

5
Juga setuju bahwa dokumentasinya masih kurang
Brendan Weinstein

25

Saya sedang membangun aplikasi baru dan sekarang merancang strukturnya, berikut adalah beberapa pemikiran tentang mengapa menggunakan atau tidak menggunakan luwak:

  1. Mongoose akan lebih lambat (untuk aplikasi besar)
  2. Mongoose lebih sulit dengan kueri yang lebih rumit
  3. Akan ada situasi ketika Anda menginginkan kecepatan lebih dan Anda akan memilih untuk pergi tanpa luwak maka Anda akan memiliki setengah pertanyaan dengan luwak dan setengah w / o. Itu situasi gila, dulu ..
  4. Mongoose akan membuat Anda membuat kode lebih cepat dengan aplikasi sederhana dengan struktur db sederhana
  5. Mongoose akan membuat Anda membaca dokumen mongodb DAN dokumen mongoose
  6. Dengan luwak, tumpukan Anda akan mendapatkan satu hal lagi untuk diandalkan dan satu lagi kemungkinan untuk rusak dan terbakar menjadi abu.

pengemudi mongodb adalah pengemudi mentah, Anda berkomunikasi langsung ke mongodb. luwak adalah lapisan abstraksi. Anda mendapatkan I / O lebih mudah ke db sementara struktur db Anda cukup sederhana.

Abstraksi membawa persyaratannya dan Anda harus mengikutinya. Aplikasi Anda akan lebih lambat, memakan lebih banyak RAM, dan menjadi lebih rumit, tetapi jika Anda tahu cara menggunakannya, Anda dapat lebih cepat menulis objek sederhana, menyimpannya ke database.

Tanpa luwak Anda akan memiliki aplikasi yang lebih cepat dengan koneksi langsung ke mongodb. Tidak ada yang mengatakan, bahwa Anda tidak dapat menulis model Anda sendiri untuk menyimpan barang ke db. Kamu bisa. Dan saya pikir itu lebih mudah. Anda menulis kode, yang akan Anda gunakan, Anda tahu apa yang Anda butuhkan. Lapisan abstraksi Anda akan jauh lebih kecil, kemudian luwak.

Saya berasal dari dunia PHP, di sana kami memiliki sql mentah dengan fungsi mysql_ terdepresiasi, lalu kami mendapat PDO - lapisan abstraksi berorientasi objek untuk berkomunikasi dengan sql. Atau Anda dapat memilih ORM yang berat seperti Doctrine untuk memiliki hal yang mirip dengan luwak di mongoDB. Objek dengan metode penyetel / pengambil / simpan dan seterusnya. Tidak apa-apa, tetapi dengan menambahkan lebih banyak abstraksi Anda menambahkan lebih banyak file, lebih banyak logika, lebih banyak dokumentasi, lebih banyak ketergantungan. Saya suka membuat hal-hal sederhana dan memiliki lebih sedikit ketergantungan di tumpukan saya. BTW, itulah mengapa saya pindah dari PHP ke Javascript klien-server di tempat pertama ..

Dengan luwak menurut saya bagus untuk menulis beberapa aplikasi sederhana, yang memiliki struktur db sederhana yang mirip dengan sql . Ketika Anda mulai memiliki subdocuments dan ingin membuat semua pertanyaan gila itu, saya merasa sangat sulit dengan luwak. Anda harus melihat dokumen mongodb, kemudian melihat dokumen mongoose untuk mengetahui cara membuat kueri yang Anda inginkan. Kadang-kadang Anda akan menemukan, bahwa masa depan X dari mongodb tidak ada di luwak, jadi Anda pergi ke pengemudi mongodb mentah dan menulis pertanyaan mongodb mentah di satu atau tempat lain. Tanpa luwak, Anda melihat dokumen mongodb dan melakukan kueri Anda.


3
Saya juga berpikir mongodb lebih baik daripada luwak karena cepat dan mungkin untuk melakukan query yang rumit. Lebih baik untuk aplikasi besar dan Anda harus menggunakan driver mongodb mentah. Saya sangat setuju dengan anda
Abdul Alim Shakir

Saya sangat setuju dengan Anda meskipun Anda tidak membuat aplikasi besar. Pertanyaan kompleks jauh lebih mudah bagi pengemudi mongo dibandingkan melakukannya di luwak
Juan

14

Saya hanya menggunakan mongodb. Menurut pendapat pribadi saya, saya akan merekomendasikan memulai dengan sesuatu yang levelnya rendah dan kemudian naik. Jika tidak, Anda mungkin menemukan diri Anda menggunakan fitur lanjutan tambahan yang disediakan oleh driver tingkat yang lebih tinggi seperti luwak tanpa manfaat yang sebenarnya.

Masalah yang saya alami dengan mongodb, yang merupakan endemik node.js adalah dokumentasi yang buruk. Ada banyak dokumentasi dan banyak darinya tetapi tidak selalu yang paling membantu. Yang saya lihat sejauh ini tidak ada contoh penggunaan produksi yang baik dan menyeluruh dari pengemudi. Dokumentasi diisi dengan contoh template yang sama dari membuka koneksi, mengeluarkan perintah dan menutup koneksi. Anda dapat membedakannya disalin dan ditempelkan dari templat karena setiap contoh menyertakan diperlukan untuk semua yang mungkin diperlukan, bukan hanya yang diperlukan untuk setiap contoh.

Untuk memberikan contoh yang diambil seluruhnya secara acak:

  • raw {Boolean, default: false}, melakukan operasi menggunakan buffer bson mentah.

Apa sebenarnya yang dilakukan "melakukan operasi menggunakan buffer bson mentah"? Saya tidak dapat menemukannya dijelaskan di mana pun dan pencarian Google untuk frasa itu tidak membantu. Mungkin saya bisa Google lebih jauh tetapi saya tidak perlu melakukannya. Informasinya harus ada di sana. Apakah ada keuntungan kinerja, stabilitas, integritas, kompatibilitas, portabilitas, atau fungsional untuk mengaktifkan / menonaktifkan opsi ini? Saya benar-benar tidak tahu tanpa mendalami kode dan jika Anda berada di kapal saya, itu masalah serius. Saya memiliki daemon di mana ketekunan yang sempurna tidak diperlukan tetapi program harus sangat stabil saat runtime. Saya dapat berasumsi ini berarti bahwa ia mengharapkan saya untuk deserialisasi dan serialisasi ke JSON atau sesuatu tingkat rendah, internal dan transparan bagi pengguna tetapi saya bisa saja salah. Meskipun saya cenderung membuat asumsi yang baik, saya tidak dapat mengandalkan asumsi dan tebakan ketika membuat sistem penting. Jadi di sini saya dapat menguji pernyataan saya dengan kode atau menggali lebih dalam ke Google atau kodenya. Sebagai salah satu hal ini tidak terlalu buruk tetapi saya menemukan diri saya dalam situasi ini berkali-kali ketika membaca dokumentasi mereka. Perbedaannya bisa berarti hari-hari yang dihabiskan untuk tugas versus berjam-jam. Saya butuh konfirmasi dan dokumentasinya hampir tidak memberi saya penjelasan, apalagi konfirmasi.

Dokumentasi tergesa-gesa. Itu tidak menjelaskan peristiwa, memberikan detail yang tidak jelas tentang kapan kesalahan terjadi atau sifat dari kesalahan tersebut dan sering kali ada beberapa cara untuk mencapai konektivitas yang mungkin tidak jelas. Anda bisa bertahan dan itu tidak sepenuhnya tidak berguna, tetapi sangat kasar di tepinya. Anda akan menemukan beberapa hal tersisa untuk menebak dan bereksperimen.


Dengan dokumentasi yang bagus, hadir perangkat lunak yang hebat. Itu adalah salah satu bagian terpenting.
Lukas Liesis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.