Kapan menggunakan MongoDB atau sistem basis data berorientasi dokumen lainnya? [Tutup]


516

Kami menawarkan platform untuk klip video dan audio, foto dan vektor-grafika. Kami mulai dengan MySQL sebagai backend basis data dan baru-baru ini menyertakan MongoDB untuk menyimpan semua meta-informasi file, karena MongoDB lebih sesuai dengan persyaratan. Misalnya: foto mungkin memiliki informasi Exif , video mungkin memiliki trek audio tempat kami ingin menyimpan informasi meta juga. Video dan vektor-grafik tidak membagikan meta-informasi umum, dll. Jadi saya tahu, bahwa MongoDB sempurna untuk menyimpan data yang tidak terstruktur ini dan menjaganya tetap dapat dicari.

Namun, kami terus mengembangkan platform kami dan menambahkan fitur. Sekarang salah satu langkah selanjutnya akan menyediakan forum untuk pengguna kami. Pertanyaan yang sekarang muncul adalah: gunakan database MySQL, yang akan menjadi pilihan yang baik untuk menyimpan forum dan posting forum, dll. Atau menggunakan MongoDB untuk ini juga?

Jadi pertanyaannya adalah: kapan harus menggunakan MongoDB dan kapan harus menggunakan RDBMS. Apa yang akan Anda ambil, mongoDB atau MySQL, jika Anda punya pilihan dan mengapa Anda mengambilnya?


12
Tidak yakin mengapa ini ditandai sebagai berbasis opini padahal sebenarnya tidak. Ada jawaban benar atau salah yang jelas di sini.
Spencer

Jawaban:


659

Dalam NoSQL: Jika Hanya Itu yang Mudah , penulis menulis tentang MongoDB:

MongoDB bukan toko kunci / nilai, ini sedikit lebih. Ini jelas bukan RDBMS juga. Saya belum pernah menggunakan MongoDB dalam produksi, tetapi saya telah menggunakannya sedikit membangun aplikasi tes dan itu adalah bagian yang sangat keren dari kit. Tampaknya sangat berkinerja dan baik memiliki, atau akan segera, toleransi kesalahan dan sharding (alias itu akan skala). Saya pikir Mongo mungkin merupakan hal terdekat dengan pengganti RDBMS yang telah saya lihat sejauh ini. Ini tidak akan berfungsi untuk semua set data dan pola akses, tetapi itu dibuat untuk barang-barang CRUD khas Anda. Menyimpan apa yang pada dasarnya hash besar, dan bisa memilih salah satu dari kunci-kunci itu, adalah tujuan utama kebanyakan orang menggunakan database relasional.Jika DB Anda adalah 3NF dan Anda tidak melakukan penggabungan (Anda hanya memilih banyak tabel dan menyatukan semua objek, AKA apa yang dilakukan kebanyakan orang di aplikasi web), MongoDB mungkin akan menendang Anda.

Kemudian, dalam kesimpulan:

Hal yang nyata untuk ditunjukkan adalah bahwa jika Anda ditahan untuk membuat sesuatu yang sangat luar biasa karena Anda tidak dapat memilih database, Anda salah melakukannya. Jika Anda tahu mysql, gunakan saja. Optimalkan ketika Anda benar-benar perlu. Gunakan seperti ak / v store, gunakan seperti rdbms, tetapi demi Tuhan, buat aplikasi pembunuh Anda! Tak satu pun dari ini akan menjadi masalah bagi sebagian besar aplikasi. Facebook masih menggunakan MySQL, banyak. Wikipedia banyak menggunakan MySQL. FriendFeed banyak menggunakan MySQL. NoSQL adalah alat yang hebat, tetapi tentu saja ini tidak akan menjadi daya saing Anda, itu tidak akan membuat aplikasi Anda panas, dan yang paling utama, pengguna Anda tidak akan peduli tentang semua ini.

Di mana saya akan membangun aplikasi berikutnya? Mungkin Postgres. Apakah saya akan menggunakan NoSQL? Mungkin. Saya mungkin juga menggunakan Hadoop dan Hive. Saya mungkin menyimpan semuanya dalam file datar. Mungkin saya akan mulai meretas Maglev. Saya akan menggunakan apa pun yang terbaik untuk pekerjaan itu. Jika saya perlu melaporkan, saya tidak akan menggunakan NoSQL. Jika saya perlu caching, saya mungkin akan menggunakan Tokyo Tyrant. Jika saya membutuhkan ACIDity, saya tidak akan menggunakan NoSQL. Jika saya membutuhkan banyak penghitung, saya akan menggunakan Redis. Jika saya perlu transaksi, saya akan menggunakan Postgres. Jika saya memiliki satu ton satu jenis dokumen, saya mungkin akan menggunakan Mongo. Jika saya perlu menulis 1 miliar objek sehari, saya mungkin akan menggunakan Voldemort. Jika saya perlu pencarian teks lengkap, saya mungkin akan menggunakan Solr. Jika saya perlu pencarian teks lengkap dari data volatil, saya mungkin akan menggunakan Sphinx.

Saya suka artikel ini, saya merasa sangat informatif, memberikan gambaran yang bagus tentang lanskap dan hype NoSQL. Tetapi, dan itulah bagian terpenting, sangat membantu untuk bertanya pada diri sendiri pertanyaan yang tepat ketika memilih antara RDBMS dan NoSQL. Layak dibaca IMHO.

Tautan alternatif ke artikel


4
terima kasih, ini memang artikel yang sangat menarik.
aurora


48
@iddqd ROFL! Sobat, ini lucu sekali. "Jika Anda cukup bodoh untuk benar-benar mengabaikan keandalan hanya untuk mendapatkan benchmark, saya sarankan Anda mengirim data Anda ke /dev/null, itu akan sangat cepat" : D
Pascal Thivent

3
Terima kasih atas jawaban sadar hype.
deamon

2
Semoga BJ Clark tidak akan memilih untuk menggunakan semua teknologi itu dalam proyek yang sama. Itu akan menjadi sedikit kurva pembelajaran.
Adam Monsen

186

Setelah dua tahun menggunakan MongoDb untuk aplikasi sosial, saya telah menyaksikan apa artinya hidup tanpa SQL RDBMS.

  1. Anda akhirnya menulis pekerjaan untuk melakukan hal-hal seperti menggabungkan data dari berbagai tabel / koleksi, sesuatu yang akan dilakukan RDBMS untuk Anda secara otomatis.
  2. Kemampuan kueri Anda dengan NoSQL lumpuh secara drastis. MongoDb mungkin merupakan hal yang paling dekat dengan SQL tetapi masih sangat jauh di belakang. Percayalah kepadaku. Query SQL sangat intuitif, fleksibel dan kuat. Kueri MongoDb tidak.
  3. Kueri MongoDb dapat mengambil data hanya dari satu koleksi dan memanfaatkan hanya satu indeks. Dan MongoDb mungkin adalah salah satu dari database NoSQL yang paling fleksibel. Dalam banyak skenario, ini berarti lebih bolak-balik ke server untuk menemukan catatan terkait. Dan kemudian Anda mulai de-normalisasi data - yang berarti pekerjaan latar belakang.
  4. Fakta bahwa itu bukan database relasional berarti bahwa Anda tidak akan memiliki (kunci oleh beberapa orang berkinerja buruk) kendala kunci asing untuk memastikan bahwa data Anda konsisten. Saya yakinkan Anda bahwa ini pada akhirnya akan menciptakan inkonsistensi data dalam database Anda. Dipersiapkan. Kemungkinan besar Anda akan mulai menulis proses atau memeriksa agar database Anda konsisten, yang mungkin tidak akan berkinerja lebih baik daripada membiarkan RDBMS melakukannya untuk Anda.
  5. Lupakan kerangka kerja yang matang seperti hibernate.

Saya percaya bahwa 98% dari semua proyek mungkin jauh lebih baik dengan RDBMS SQL khas daripada dengan NoSQL.


10
pengalaman menarik ...
luigi7up

3
Di sisi lain, kemampuan permintaan dan gabungan yang Anda gambarkan seharusnya tidak menjadi masalah: jika Anda menggunakan MongoDB maka Anda masih harus melakukan beberapa pekerjaan untuk merancang koleksi Anda dan data apa yang akan Anda masukkan ke dalam sehingga Anda tidak perlu rumit BERGABUNG dan sebagainya. Anyways DB bukan hambatan dan ada solusi seperti Memcache untuk beberapa kasus penggunaan. Jika mulai dari awal, Anda mungkin menemukan bahwa merancang dan menggunakan MongoDB lebih sederhana dan lebih cepat (sebagai pengembang yang bekerja dengan kode objek, saya tidak memerlukan ORM). Tentu Anda harus menulis beberapa skrip, tetapi sebenarnya itu tidak terlalu sulit dan Anda menggunakan kembali kode
Aki

1
Kebanyakan orang tidak akan menggunakan database NoSQL untuk case-use khusus yang mereka buat, menciptakan kembali begitu banyak roda sesudahnya. The NoSQL vs SQL debat menunjukkan bahwa banyak orang mengalami menggunakan NoSQL seolah-olah mereka akan kembali 20-30 tahun dalam waktu, untuk pra-Codd, pra-relasional, pra-SQL kali . Atau, sebagaimana dikatakan Michael Stonebraker: "What Goes Around Comes Around"
Lukas Eder

1
Apakah item # 3, "dan manfaatkan hanya satu indeks" masih berlaku hari ini? Saya baru saja masuk ke MongoDB sekarang dan tampaknya dari apa yang telah saya baca / lihat sejauh ini dapat mendukung banyak indeks?
Jeach

1
@Jeach: Tidak, # 3 tidak lagi benar. MongoDB 2.6 memperkenalkan persimpangan indeks .
Rob Garrison

26

untuk menyimpan data tidak terstruktur ini

Seperti yang Anda katakan, MongoDB paling cocok untuk menyimpan data yang tidak terstruktur. Dan ini dapat mengatur data Anda ke dalam format dokumen. ALtenative RDBMS ini disebut penyimpanan data NoSQL ( MongoDB , CouchDB , Voldemort ) sangat berguna untuk aplikasi yang berskala besar dan membutuhkan akses data yang lebih cepat dari toko data besar ini.

Dan implementasi dari basis data ini lebih sederhana daripada RDBMS biasa. Karena ini adalah objek biner yang diberi nilai kunci atau gaya dokumen langsung diserialisasi ke disk. Menyimpan data ini tidak menegakkan properti ACID , dan skema apa pun . Ini tidak memberikan kemampuan transaksi apa pun . Jadi ini dapat berskala besar dan kita dapat mencapai akses yang lebih cepat (baik membaca dan menulis).

Namun sebaliknya, RDBM memberlakukan ACID dan skema pada data. Jika Anda ingin bekerja dengan data terstruktur, Anda dapat melanjutkan dengan RDBM.

Saya akan memilih MySQL untuk membuat forum untuk hal semacam ini. Karena ini tidak akan berskala besar. Dan ini adalah aplikasi (umum) yang sangat sederhana yang memiliki hubungan terstruktur di antara data.


10
"Saya akan memilih mysql untuk membuat semacam forum." Betulkah? Saya pikir hal-hal seperti forum akan jauh lebih mudah untuk ditulis menggunakan database berorientasi dokumen daripada relasional (jika Anda menulisnya dari awal). Jika Anda tidak secara khusus membutuhkan fitur-fitur RDBMS, saya akan mengatakan pergi dengan MongoDB atau database serupa untuk kemudahan penggunaan dan penskalaan.
Sasha Chedygov

2
CouchDB memiliki dukungan ACID. couchdb.apache.org/docs/overview.html
Sonia

2018: MongoDB juga memiliki dukungan ACID
Nepoxx

10

Perhatikan bahwa Mongo pada dasarnya menyimpan JSON. Jika aplikasi Anda berurusan dengan banyak JS Objects (dengan nesting) dan Anda ingin tetap menggunakan objek ini, maka ada argumen yang sangat kuat untuk menggunakan Mongo. Itu membuat lapisan DAL dan MVC Anda sangat tipis, karena mereka tidak mengemas semua properti objek JS dan mencoba untuk memasangnya secara paksa ke dalam struktur (skema) yang tidak sesuai dengan mereka secara alami.

Kami memiliki sistem yang memiliki beberapa objek JS yang kompleks, dan kami mencintai Mongo karena kami dapat bertahan dengan sangat, sangat mudah. Objek kami juga agak amorf dan tidak terstruktur, dan Mongo menyerap kerumitan itu tanpa berkedip. Kami memiliki lapisan pelaporan khusus yang menguraikan data amorf untuk konsumsi manusia, dan itu tidak sulit untuk dikembangkan.


7

Saya akan mengatakan menggunakan RDBMS jika Anda membutuhkan transaksi yang kompleks. Kalau tidak, saya akan pergi dengan MongoDB - lebih fleksibel untuk bekerja dengan dan Anda tahu itu bisa skala ketika Anda perlu. (Saya bias meskipun - saya bekerja pada proyek MongoDB)


7
Transaksi kompleks tidak bekerja di MongoDB, tetapi mereka bekerja di database NoSQL lainnya, seperti MarkLogic (Saya juga bias karena saya menjalankan komunitas pengembang untuk MarkLogic).
Eric Bloch

Terima kasih atas petunjuk untuk MarkLogic - saya tidak mengetahuinya.
aurora

Saya ingin mendengar dari mdirolf tentang itu. Mengapa MongoDB memilih untuk tidak mengimplementasikan transaksi?
Aki

7

Siapa yang butuh forum yang terdistribusi dan terlindung? Mungkin Facebook, tetapi kecuali Anda membuat pesaing Facebook, cukup gunakan Mysql, Postgres atau apa pun yang paling nyaman bagi Anda. Jika Anda ingin mencoba MongoDB, ok, tapi jangan berharap itu melakukan sihir untuk Anda. Ini akan memiliki keanehan dan kekotoran umum, seperti yang lainnya, karena saya yakin Anda sudah menemukan jika Anda benar-benar telah mengusahakannya.

Tentu, MongoDB mungkin hyped dan tampaknya mudah di permukaan, tetapi Anda akan mengalami masalah yang lebih banyak produk dewasa telah diatasi. Jangan terpikat dengan mudah, tetapi lebih baik menunggu sampai "nosql" matang, atau mati.

Secara pribadi, saya pikir "nosql" akan layu dan mati karena fragmentasi, karena tidak ada standar yang ditetapkan (hampir secara definisi). Jadi saya tidak akan secara pribadi bertaruh untuk proyek jangka panjang.

Satu-satunya hal yang dapat menyimpan "nosql" di buku saya, adalah jika itu dapat diintegrasikan ke dalam Ruby atau bahasa serupa dengan mulus, dan membuat bahasa "persisten", hampir tanpa overhead dalam pengkodean dan desain. Itu mungkin terjadi, tetapi saya akan menunggu sampai saat itu, tidak sekarang, DAN itu harus lebih matang tentu saja.

Btw, mengapa Anda membuat forum dari awal? Ada banyak sekali forum open source yang dapat disesuaikan dengan sebagian besar persyaratan, kecuali Anda benar-benar menciptakan Forum Generasi Selanjutnya (yang saya ragu).


5
Terima kasih atas jawaban anda. mengintegrasikan forum adalah hal yang berantakan - kami telah melakukan ini dan memutuskan untuk tidak melakukannya lagi: kami tidak memerlukan ribuan fitur tetapi integrasi penuh dalam perangkat lunak kami.
aurora

4

Saya telah melihat banyak perusahaan menggunakan MongoDB untuk analisis waktu nyata dari log aplikasi. Skema-freeness-nya sangat cocok untuk log aplikasi, di mana skema catatan cenderung berubah dari waktu ke waktu. Selain itu, fitur Capped Collection -nya berguna karena secara otomatis membersihkan data lama agar data tetap masuk ke dalam memori.

Itu adalah salah satu area yang menurut saya cocok untuk MongoDB, tetapi MySQL / PostgreSQL lebih direkomendasikan secara umum. Ada banyak dokumentasi dan sumber daya pengembang di web, serta fungsionalitas dan kekokohannya.


4

2 alasan utama mengapa Anda mungkin ingin memilih Mongo adalah

  • Fleksibilitas dalam desain skema (toko dokumen jenis JSON).
  • Skalabilitas - Cukup tambahkan node dan dapat menskala secara horizontal dengan cukup baik.

Sangat cocok untuk aplikasi big data. RDBMS tidak baik untuk data besar.


3

Anda tahu, semua hal ini tentang gabungan dan 'transaksi kompleks' - tetapi Monty sendiri yang, bertahun-tahun lalu, menjelaskan "kebutuhan" untuk COMMIT / ROLLBACK, dengan mengatakan bahwa 'semua yang dilakukan dalam kelas logika (dan bukan database) '- jadi itu adalah hal yang sama lagi. Apa yang dibutuhkan adalah mesin penyimpanan / pengambilan data yang bodoh namun sangat rapi dan cepat, untuk 99% dari apa yang dilakukan aplikasi web.


Terima kasih, Anda meningkatkan poin yang menarik di sini. Saya benar-benar akan tertarik pada penjelasan Monty, karena saya tidak yakin bagaimana kembalinya kompleks pembaruan di beberapa tabel masuk ke logika aplikasi murni - saya tidak yakin, apakah ini benar-benar mungkin?
aurora

Saya juga tidak yakin cara 'terbaik'. Kami selalu melacak semua yang dilakukan pada DB, dan kemudian mengizinkan atau membatalkannya pada level aplikasi, dalam kode. Kami tidak pernah mengandalkan transaksi, di mana pun, selama ini. Mongo docs menyarankan menggunakan metadata untuk melacak bagian mana dari transaksi yang dapat dikembalikan yang telah terjadi, apa status transaksi itu, jika itu rusak dan perlu digulirkan kembali. Lucunya, kami sudah melakukan itu bersama dengan MySQL dan lainnya. Ini bukan pekerjaan yang lebih banyak dan itu tetap fokus pada apa yang terjadi, kapan, di mana dan mengapa, bukannya tinju hitam itu.
FYA

Ada catatan tentang ini di situs web 10gen di suatu tempat ... menyebutkan bagaimana bidang 'interlock', atau 'ratchet' digunakan secara manual untuk menunjukkan status proses multi-langkah. Tampak bagi saya bahwa jika Anda memperbesar ke mesin MySQL itu sendiri, "transaksi blok" masih meluas ke serangkaian langkah, apa pun yang terjadi; hanya saja interlock atau ratchet dilakukan dengan cara yang jauh lebih kecil, lebih cepat daripada melakukan pelacakan secara manual di bidang basis data.
FYA

Kami belum menemukan cara yang baik untuk membatasi daemon MongoDB - ia melahap hampir semua RAM yang tersedia untuk indeksnya dan penyimpanan data dalam memori, meskipun ia menghasilkan memori dengan cepat ketika prok lain membutuhkannya. Namun, akan lebih baik jika memiliki 'use_max_memory' atau batasan lain yang mudah ditentukan untuk memastikan MongoDB tidak melarikan diri dan mengirim server ke swap swap (kami telah melihat ini beberapa kali, bahkan pada versi paling baru). Setidaknya MySQL menerima semua jenis batasan yang dapat ditentukan dan petunjuk pengoperasian.
FYA

Tidak terkait langsung, tetapi jenis: Kami menggunakan memcached tetapi menyerah karena Memcache / Memcached PHP driver gagal. Kami menggunakan MongoDB sebagai kunci sementara yang cepat: val store (yang berfungsi sangat baik!) Hingga menemukan seberapa cepat dan mudahnya apc_store (). Jika kami menemukan bahwa APC diisi dengan crud sementara (vs PHP yang tersimpan sebelumnya) yang kami gunakan untuk mem-cache, kami akan kembali ke MongoDB untuk kunci: penyimpanan val.
FYA

1

Seperti yang dikatakan sebelumnya, Anda dapat memilih di antara banyak pilihan, lihat semua pilihan itu: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Apa yang saya sarankan adalah mencari kombinasi terbaik Anda: MySQL + Memcache benar-benar hebat jika Anda memerlukan ACID dan Anda ingin bergabung dengan beberapa tabel MongoDB + Redis sempurna untuk toko dokumen Neo4J sempurna untuk basis data grafik

Apa yang saya lakukan: Saya mulai dengan MySQl + Memcache karena saya terbiasa, kemudian saya mulai menggunakan kerangka kerja basis data orang lain. Dalam satu proyek, Anda dapat menggabungkan MySQL dan MongoDB misalnya!


MySQL + memcached akan memberi Anda Konsistensi Akhirnya. Yang saya tidak menganggap ACID dalam konteks RDMB.
R. van Twisk
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.