Apa keuntungan menggunakan database bebas skema seperti MongoDB dibandingkan dengan database relasional?

95

Saya terbiasa menggunakan database relasional seperti MySQL atau PostgreSQL, dan dikombinasikan dengan kerangka kerja MVC seperti Symfony, RoR atau Django, dan menurut saya ini berfungsi dengan baik.

Tapi belakangan ini saya banyak mendengar tentang MongoDB yang merupakan database non-relasional, atau, mengutip definisi resminya ,

database yang dapat diskalakan, berkinerja tinggi, open source, bebas skema, dan berorientasi dokumen.

Saya sangat tertarik untuk menjadi gelisah dan ingin mengetahui semua opsi yang akan saya miliki untuk proyek berikutnya dan memilih teknologi terbaik di luar sana.

Dalam kasus mana menggunakan MongoDB (atau database serupa) lebih baik daripada menggunakan database relasional "klasik"? Dan apa saja keunggulan MongoDB vs MySQL secara umum? Atau setidaknya, mengapa ini sangat berbeda?

Jika Anda memiliki petunjuk ke dokumentasi dan / atau contoh, itu akan sangat membantu juga.

mongodb  database 
— Guillaume Flandre
sumber

Jawaban:

57

Berikut beberapa keunggulan MongoDB untuk membangun aplikasi web:

  1. Model data berbasis dokumen. Unit dasar penyimpanan analog dengan JSON, kamus Python, hash Ruby, dll. Ini adalah struktur data yang kaya yang mampu menampung array dan dokumen lain. Ini berarti Anda sering dapat merepresentasikan dalam satu entitas sebuah konstruksi yang membutuhkan beberapa tabel untuk merepresentasikan dengan benar dalam db relasional. Ini sangat berguna jika data Anda tidak dapat diubah.
  2. Kemampuan kueri yang mendalam. MongoDB mendukung kueri dinamis pada dokumen menggunakan bahasa kueri berbasis dokumen yang hampir sekuat SQL.
  3. Tidak ada migrasi skema. Karena MongoDB bebas skema, kode Anda menentukan skema Anda.
  4. Jalur yang jelas menuju skalabilitas horizontal.

Anda perlu membaca lebih lanjut tentang itu dan memainkannya untuk mendapatkan ide yang lebih baik. Berikut demo online:

http://try.mongodb.org/

— Kyle Banker
sumber
3
Saya menerima jawaban ini, tetapi lihat di bawah ini jawaban bagus lainnya. @marcgg menjawab dengan link yang menarik misalnya.
— Guillaume Flandre
Mengatakan "kinerja yang lebih baik" itu menyesatkan; itu tergantung pada apa yang Anda lakukan. MongoDB tidak mendukung join tidak membuatnya lebih cepat, itu hanya berarti lebih baik pada operasi DB sederhana (seharusnya, saya sebenarnya belum melihat benchmark untuk membuktikan ini). Setelah Anda membutuhkan fungsionalitas yang bergabung dengan menyediakan, kinerja Anda dengan Mongo akan menurun drastis. Tetapi jika Anda tidak memerlukan fitur gabungan atau relasional sama sekali, tentu, Mongo mungkin lebih performant / scalable.
— Sasha Chedygov
Terima kasih @SashaChedygov. Saya setuju denganmu. Itu cukup ceroboh bagi saya tahun 2010 :)
— Kyle Banker
@KyleBanker: Jangan khawatir, cukup komen kalau-kalau ada yang melihatnya di 2013 dan salah paham. :) +1 untuk edit.
— Sasha Chedygov
Mongo menawarkan jalur skalabilitas horizontal yang sangat spesifik, yang berguna dalam skenario tertentu ....
— AK_
23

Ada banyak keuntungan.

Misalnya skema database Anda akan lebih skalabel, Anda tidak perlu khawatir tentang migrasi, kode akan lebih menyenangkan untuk ditulis ... Misalnya, berikut salah satu kode model saya:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Menambahkan kunci hanya menambahkan sebaris kode!

Ada juga keuntungan lain yang akan muncul dalam jangka panjang, seperti skalabilitas dan kecepatan yang lebih baik.

... Namun perlu diingat bahwa database non-relasional tidak lebih baik dari database relasional . Jika database Anda memiliki banyak relasi dan normalisasi, mungkin tidak masuk akal untuk menggunakan sesuatu seperti MongoDB. Ini semua tentang menemukan alat yang tepat untuk pekerjaan itu.

Untuk lebih banyak hal untuk dibaca, saya akan merekomendasikan untuk melihat " Mengapa saya pikir Mongo adalah untuk Database apa Rails untuk Frameworks " atau posting ini di situs web mongodb. Untuk menjadi bersemangat dan jika Anda berbicara bahasa Prancis, lihat artikel ini yang menjelaskan cara mengatur MongoDB dari awal.

Sunting: Saya hampir lupa memberi tahu Anda tentang siaran kereta api ini oleh Ryan . Ini sangat menarik dan membuat Anda ingin segera memulainya!

— marcgg
sumber
Railscast ini sepertinya sangat menarik; akan melihatnya, semoga saya memiliki pemahaman yang lebih baik tentang cara kerjanya.
— Guillaume Flandre
5

Keuntungan bebas skema adalah Anda dapat membuang apa pun yang dimuat di dalamnya, dan tidak akan ada yang memiliki alasan untuk mengeluh tentangnya, atau mengatakan bahwa itu salah.

Ini juga berarti bahwa apa pun yang Anda masukkan ke dalamnya, tetap kosong sama sekali setelah Anda melakukannya.

Beberapa akan melabeli hal itu sebagai kerugian besar, beberapa lainnya tidak.

Fakta bahwa database relasional memiliki skema yang mapan, adalah konsekuensi dari fakta bahwa ia memiliki kumpulan predikat ekstensional yang mapan, yang memungkinkan kita untuk melampirkan makna pada apa yang dicatat dalam database, dan mana yang juga prasyarat penting bagi kami untuk melakukannya.

Tanpa skema yang mapan, tidak ada predikat ekstensional, dan tanpa precicates ekstensional, tidak ada cara bagi pengguna untuk membuat makna dari apa yang ada di dalamnya.

— Erwin Smout
sumber
1
Ini benar-benar anti-jawaban. Sebagian besar makna, seperti yang dipahami kebanyakan orang, muncul dari lebih dari sekadar konsep relasional. Faktanya, lebih sulit bagi sebagian besar pengembang aplikasi untuk membedakan makna dari skema yang sangat dinormalisasi daripada untuk penyimpanan dokumen.
— pengguna1020853
1
Artinya, seperti yang dimiliki logika, berasal dari proposisi. Proposisi dapat muncul dari predikat dengan tempat kosong jika dan saat tempat kosong tersebut diganti dengan item data aktual. Tetapi item data tersebut harus berasal dari suatu struktur. Dan jika ada struktur maka ada skema. Oleh karena itu, jika tidak ada skema, tidak ada struktur yang dapat berfungsi untuk membangun proposisi yang kemudian menimbulkan makna, kecuali dengan cara mengacungkan jari dan mengarangnya. Itu bukan anti-apapun atau pro-apapun, itu adalah fakta sederhana yang sederhana.
— Erwin Smout
3
Itu hanya satu pandangan tentang makna dan hanya sesuai dengan konteks intelektual yang cukup sempit (dan ini filosofis, bukan logis). Jawaban Anda pada dasarnya berbunyi "jika Anda tidak memiliki skema seperti database relasional, maka Anda tidak memiliki arti." Itu bukanlah jawaban untuk pertanyaan awal tentang "apa keuntungannya?" karena itu saya menyebutnya anti-jawaban. Ini juga tidak benar kecuali kami membatasi "makna" sampai ke konteks sempit ini. Ada banyak ruang untuk "makna" tanpa "skema yang mapan".
— pengguna1020853
1
Jadi bagaimana kalau Anda menunjukkan kepada saya seperti apa pandangan "lebih luas" Anda tentang "makna", dan bagaimana hal itu bisa ada tanpa predikat atau proposisi logika. Perhatikan bahwa komentar saya tidak menyebutkan kata "relasional" sekali. Teknologi data pra-relasional memiliki skema dan oleh karena itu cocok untuk menyimpulkan "makna". Teknologi pra-basis data memiliki skema dan oleh karena itu cocok untuk menyimpulkan "makna". Bebas skema tidak memiliki skema (kecuali bagian "bebas" adalah kebohongan langsung) dan oleh karena itu tidak cocok untuk menyimpulkan "makna". ...
— Erwin Smout
1
... Bebas skema memaksa penggunanya bermain tebak-tebakan. Dan bahkan jika pengguna tersebut dapat melakukannya dengan benar 90 atau 99% dari waktu, itu tetap saja, permainan tebak-tebakan.
— Erwin Smout
3

Pengalaman saya dengan Postgres dan Mongo setelah bekerja dengan kedua database dalam proyek saya.

Postgres (RDBMS)

Postgres direkomendasikan jika aplikasi masa depan Anda memiliki skema rumit yang membutuhkan banyak gabungan atau semua data memiliki relasi atau jika kami memiliki tulisan yang berat. Postgres adalah open source, lebih cepat, kompatibel dengan ACID dan menggunakan lebih sedikit memori pada disk, dan semuanya berkinerja baik untuk penyimpanan JSON juga dan mencakup serialisasi penuh transaksi dengan 3 tingkat isolasi transaksi.

Keuntungan terbesar tetap bersama Postgres adalah kami memiliki yang terbaik dari kedua dunia. Kita dapat menyimpan data ke dalam JSONB dengan batasan, konsistensi dan kecepatan. Di sisi lain, kita dapat menggunakan semua fitur SQL untuk jenis data lainnya. Mesin yang mendasarinya sangat stabil dan dapat menangani berbagai volume data dengan baik. Ini juga berjalan pada perangkat keras dan sistem operasi pilihan Anda. Postgres menyediakan kemampuan NoSQL bersama dengan dukungan transaksi penuh, menyimpan dokumen JSON dengan batasan pada data lapangan.

Batasan Umum untuk Postgres

Scaling Postgres Horizontal secara signifikan lebih sulit, tetapi bisa dilakukan.

Operasi baca cepat tidak dapat sepenuhnya dicapai dengan Postgres.

TIDAK ADA Basis Data SQL

Mongo DB (Macan Kabel)

MongoDB dapat mengalahkan Postgres dalam dimensi "skala horizontal". Menyimpan JSON adalah hal yang dioptimalkan Mongo. Mongo menyimpan datanya dalam format biner yang disebut BSONb yang (secara kasar) hanyalah representasi biner dari superset JSON. MongoDB menyimpan objek persis seperti yang dirancang. Menurut MongoDB, untuk aplikasi intensif tulis, Mongo mengatakan mesin baru (Wired Tiger) memberi pengguna peningkatan kinerja tulis hingga 10x (saya harus mencobanya), dengan pengurangan penggunaan penyimpanan sebesar 80 persen, membantu menurunkan biaya penyimpanan. , mencapai pemanfaatan perangkat keras yang lebih besar.

Batasan Umum MongoDb

Penggunaan mesin penyimpanan tanpa skema menyebabkan masalah skema implisit. Skema ini tidak ditentukan oleh mesin penyimpanan kami, tetapi ditentukan berdasarkan perilaku dan harapan aplikasi.

Teknologi NoSQL yang berdiri sendiri tidak memenuhi standar ACID karena mengorbankan perlindungan data penting demi kinerja throughput yang tinggi untuk aplikasi tidak terstruktur. Tidak sulit untuk menerapkan ACID pada database NoSQL tetapi akan membuat database menjadi lambat dan tidak fleksibel hingga batas tertentu. “Sebagian besar batasan NoSQL dioptimalkan di versi dan rilis yang lebih baru yang telah mengatasi sebagian besar batasan sebelumnya”.

— ProgrammerPanda
sumber
2

Ini semua tentang pertukaran. MongoDB cepat tapi bukan ACID, tidak ada transaksi. Ini lebih baik daripada MySQL dalam beberapa kasus penggunaan dan lebih buruk di kasus lain.

— AABBCCDD
sumber
Harap tinjau komentar ini sekarang. MongoDb 4.0 sekarang mendukung transaksi asam.
— Anant Simran Singh
1

Garis Bawah Ditulis dalam MongoDB: Panduan Definitif.

Ada beberapa alasan bagus:

  1. Menyimpan berbagai jenis dokumen dalam koleksi yang sama bisa menjadi mimpi buruk bagi pengembang dan admin. Pengembang perlu memastikan bahwa setiap kueri hanya mengembalikan jenis dokumen tertentu atau bahwa kode aplikasi yang menjalankan kueri dapat menangani dokumen dalam bentuk yang berbeda. Jika kita menanyakan posting blog, akan merepotkan untuk menyingkirkan dokumen yang berisi data penulis.
  2. Jauh lebih cepat untuk mendapatkan daftar koleksi daripada mengekstrak daftar jenis dalam koleksi. Misalnya, jika kita memiliki kunci tipe dalam koleksi yang mengatakan apakah setiap dokumen adalah dokumen "skim", "utuh", atau "monyet tebal", akan jauh lebih lambat untuk menemukan ketiga nilai tersebut dalam satu koleksi daripada memiliki tiga koleksi dan kueri terpisah untuk nama mereka
  3. Mengelompokkan dokumen dari jenis yang sama dalam koleksi yang sama memungkinkan lokalitas data. Mendapatkan beberapa posting blog dari koleksi yang hanya berisi posting kemungkinan akan membutuhkan pencarian disk yang lebih sedikit daripada mendapatkan posting yang sama dari koleksi yang berisi posting dan data penulis.
  4. Kami mulai menerapkan beberapa struktur pada dokumen kami saat kami membuat indeks. (Ini terutama berlaku dalam kasus indeks unik.) Indeks ini ditentukan per koleksi. Dengan hanya meletakkan dokumen dari satu jenis ke dalam koleksi yang sama, kita dapat mengindeks koleksi kita dengan lebih efisien
— Nanhe Kumar
sumber
0

Setelah pertanyaan tentang database dengan penyimpanan tekstual), saya melirik MongoDB dan sistem serupa.
Jika saya mengerti dengan benar, mereka seharusnya lebih mudah digunakan dan diatur, dan lebih cepat. Mungkin juga lebih aman karena kurangnya SQL mencegah injeksi SQL ...
Rupanya, MongoDB sebagian besar digunakan untuk aplikasi Web.
Pada dasarnya, dan mereka menyatakan bahwa mereka sendiri, database ini tidak cocok untuk kueri kompleks, penambangan data, dll. Tetapi mereka bersinar dalam mengambil banyak data datar dengan cepat.

— PhiLho
sumber
1
Ada beberapa kesalahpahaman dalam jawaban Anda. Meskipun MongoDB tidak rentan terhadap injeksi SQL, ia rentan terhadap injeksi secara umum. Anda dapat menentukan Javascript sewenang-wenang di $ where klausa kueri. Selain itu, tidak seperti banyak opsi NoSQL lainnya, MongoDB sebenarnya dapat melakukan beberapa kueri yang cukup kompleks.
— Emily
Terima kasih atas ketelitiannya. Perhatikan bahwa, seperti yang saya nyatakan, itu adalah situs MongoDB itu sendiri yang mengeluarkan batasan pada kueri relasional. Kecuali jika saya salah memahami hal lain ...
— PhiLho
Tampaknya sangat mungkin bahwa mereka mengatakan MongoDB tidak cocok untuk kueri relasional yang kompleks, tetapi untuk kueri non-relasional yang kompleks, ini cukup cocok. Lihat mongodb.org/display/DOCS/Advanced+Queries untuk mengetahui beberapa hal keren yang dapat Anda lakukan.
— Emily
0
  1. MongoDB mendukung pencarian berdasarkan bidang, pencarian ekspresi reguler, termasuk fungsi java script yang ditentukan pengguna.
  2. MongoDB dapat digunakan sebagai sistem file, memanfaatkan fitur load balancing dan replikasi data melalui beberapa mesin untuk menyimpan file.
— pengguna2982063
sumber
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.