Kapan seseorang menggunakan MongoDB (atau yang serupa) di atas DBMS Relasional?

134

Saya agak bingung tentang seluruh hal NoSQL dan semacamnya. Kapan Anda memilih untuk menggunakan sesuatu seperti MongoDB daripada sesuatu seperti Oracle atau MySQL? Saya tidak benar-benar mengerti "perbedaan" sejauh penggunaan di antara mereka.

Dari pemahaman saya, jenis basis data NoSQL tidak dimaksudkan untuk menggantikan RDBMSes, tetapi apa sebenarnya yang seharusnya mereka lakukan?

database nosql rdms

— Glorfindel
sumber

Apa yang sudah kamu baca? Bisakah Anda memberikan penawaran atau tautan atau latar belakang untuk kami? Kami tidak tahu seberapa banyak Anda tahu - atau tidak tahu.

— S.Lott

3

Sampai / kecuali mereka dipindahkan di sini, ada beberapa pertanyaan yang sangat mirip pada StackOverflow , termasuk Kapan menggunakan MongoDB atau sistem database berorientasi dokumen lainnya?

— Nicole

1

Hal ini web-skala mongodb-is-web-scale.com / s

— Froome

3

Secara sinis: Karena ini adalah kata hype dan banyak orang suka mengikuti hypes.

— Sjoerd

@Pace: Saya pikir akan sulit untuk mengalahkan posting ini .

— Robert Harvey

34

Saya telah menggunakan CouchDB sebelumnya untuk tiga proyek peliharaan.

Sistem blogging mikro.
Untuk menyimpan informasi untuk aplikasi pembuatan catatan kecil yang saya buat.
Aplikasi curah pendapat umum.

Alasan utama mengapa saya memilih ini daripada sesuatu seperti MSSQL atau MySQL adalah fleksibilitas yang Anda peroleh saat menggunakannya. Tidak ada skema yang kaku. Jika tiga bulan ke depan Anda perlu meja tertentu untuk memiliki bidang tambahan, dan ini dan itu, Anda hanya mengubahnya dan beriak keluar dari sana keluar.

Saya menggunakan Beginning CouchDB oleh Apress untuk belajar cara menggunakannya.

Sebagai contoh, CouchDB menggunakan json untuk berkomunikasi ke / dari database. Jika bahasa Anda bisa POST data, maka Anda dapat menggunakannya untuk berkomunikasi dengan DB.

— Komunitas
sumber

31

Dua contoh pertama Anda terdengar seperti domain yang bagus untuk DBMS Relasional tradisional.

— Jonas

4

@yati: Aplikasi seperti itu kedengarannya mirip dengan StackOverflow.com dan saya merasa ini bekerja sangat baik dengan database relasional tradisional.

— Jonas

4

@yatisagade: Saya tidak berbicara tentang situs sosial yang dinamis. Tetapi aplikasi pencatatan kecil dan sistem blogging mikro .

— Jonas

2

Bagaimana tidak memiliki skema yang ditetapkan sebagai nilai tambah? Dengan DB relasional, jika tiga bulan kemudian Anda membutuhkan bidang tambahan, Anda hanya menambahkan bidang. Dengan DB relasional Anda tidak dapat menambahkan bidang secara dinamis tetapi Anda juga tidak dapat mengubah kode aplikasi Anda secara dinamis untuk bekerja dengan bidang yang ditambahkan secara dinamis.

— Rahasia Solomonoff

12

Jawaban ini tampaknya menyarankan skema database relasional tidak dapat diubah. Saya tidak dapat memahami berapa banyak kesalahpahaman yang mungkin membuat seseorang percaya ini. Sangat mudah untuk menambahkan kolom baru dalam database relasional. Biasanya ada UI yang bagus, atau jika Anda lebih suka skrip, itu dapat dilakukan dalam satu pernyataan SQL.

— JacquesB

24

Maaf menambahkan jawaban lain tetapi tidak ada jawaban di sini yang sangat memuaskan. Jawaban ini khusus untuk MongoDB (yang bertentangan dengan beragam pilihan penyimpanan data lain di luar sana yang bukan merupakan basis data relasional).

Pro:

MongoDB memiliki latensi yang lebih rendah per kueri & menghabiskan lebih sedikit waktu CPU per kueri karena ia melakukan jauh lebih sedikit pekerjaan (misalnya tidak ada yang bergabung, transaksi). Akibatnya, ia dapat menangani beban yang lebih tinggi dalam hal kueri per detik dan karenanya sering digunakan jika Anda memiliki # pengguna yang masif.
MongoDB lebih mudah untuk dibuang (digunakan dalam sebuah cluster) karena tidak perlu khawatir tentang transaksi dan konsistensi.
MongoDB memiliki kecepatan tulis lebih cepat karena tidak perlu khawatir tentang transaksi atau kembalikan (dan dengan demikian tidak perlu khawatir tentang penguncian).
MongoDB tidak memiliki skema jika Anda memiliki kasus penggunaan khusus yang dapat memanfaatkannya.

Cons:

MongoDB tidak mendukung transaksi . Inilah cara ia memperoleh sebagian besar manfaatnya.
Secara umum, MongoDB menciptakan lebih banyak pekerjaan (mis. Lebih banyak biaya CPU) untuk server klien . Misalnya, untuk bergabung dengan data, seseorang harus mengeluarkan beberapa kueri dan melakukan penggabungan pada klien.
Bahkan di sini pada tahun 2017 ada dukungan tooling kurang untuk MongoDB daripada ada untuk database relasional hanya karena itu lebih baru. Ada juga lebih sedikit ahli MongoDB daripada rekan relasional mereka.

Poin yang Sering Disalahpahami:

Baik MongoDB dan database relasional mendukung pengindeksan. Kinerja kueri mereka serupa dalam hal mengeksekusi kueri besar .
MongoDB tidak menghapus kebutuhan untuk migrasi atau lebih khusus lagi, memperbarui data yang ada saat skema Anda berkembang. Misalnya: Jika Anda memiliki aplikasi yang bergantung pada tabel pengguna untuk berisi data tertentu, dan Anda memodifikasi tabel itu untuk berisi data yang berbeda (katakanlah Anda menambahkan bidang gambar profil), maka Anda masih harus:
- Menulis aplikasi Anda untuk menangani objek yang properti ini tidak didefinisikan ATAU
- Tulis migrasi satu kali untuk memasukkan nilai default untuk properti ini ATAU
- Tulis kode untuk memberikan nilai default pada waktu permintaan jika bidang ini tidak ada ATAU
- Tangani bidang yang hilang dengan cara lain

— Kecepatan
sumber

2

Saya akan menambahkan hal besar, yang entah bagaimana terlewatkan dalam banyak diskusi NoSQL vs RDBMS: Database NoSQL jauh lebih sulit untuk permintaan iklan-hoc (itu adalah "tidak ada bagian SQL". Ini benar apakah Anda seorang pengembang atau tidak. , mereka juga jauh lebih sulit untuk membuat laporan , yang sangat penting untuk bisnis yang serius

— Michael

Heh, saya hampir menyebutnya fitur untuk MongoDB ketika saya mencegah interaksi semacam itu dengan basis data saya. Namun, Mongo memang memiliki bahasa query ad-hoc dan klien grafis ad-hoc (Kompas). Ini tidak kaya fitur seperti SQL jadi saya akan setuju itu adalah potensi kekurangan tetapi bagi saya pribadi, itu tidak akan pernah membuat perbedaan ketika saya memutuskan database mana yang akan digunakan.

— Laju

1

Mengapa Anda tidak ingin menjelajahi data dalam basis data Anda? Jika database ini memiliki informasi yang berguna untuk bisnis, itu harus dapat diakses semaksimal mungkin. Jelas sementara tidak menambahkan beban ke produksi, itulah yang Anda baca untuk replika.

— Michael

Ini mungkin pertanyaan yang menarik dalam dirinya sendiri dan saya membayangkan banyak orang akan memiliki sudut pandang yang berbeda. Secara pribadi saya menghindarinya karena itu menjadi masalah perawatan. Saya membuat aplikasi web dan mengekspos REST API yang saya komit untuk mempertahankan dan mengoptimalkan kinerja. Saya telah berada dalam situasi di mana saya tidak dapat membuat perubahan grosir ke database karena itu akan memecah terlalu banyak skrip permintaan insinyur penjualan dan saya mencoba untuk menghindari skenario itu sekarang. Misalnya saya baru saja bagian db saya dari PostgreSQL ke Cassandra untuk kinerja skala tinggi dan tidak perlu mengubah API saya.

— Laju

Akhirnya Anda akan selalu memiliki pemangku kepentingan yang tertarik untuk melihat data. Baik itu melalui kueri SQL atau semacam skrip notebook ipython, atau via re: dash. Jadi, ketika Anda membuat perubahan basis data, Anda harus selalu memastikan Anda tidak memutus ketergantungan ini. SQL (bukan RDBMS) membuat data lebih mudah diakses, dan untuk itu adalah hal yang baik untuk bisnis.

— Michael

13

Untuk mencuri tanpa malu-malu dari Renesis (sebenarnya saya sedang membuat jawaban ini CW):

Menggunakan RDBMS daripada jenis lainnya:

Baca tentang gagasan "NoSQL" dan tipe DB lainnya:
- NoSQL: Kalau Saja Semudah Itu
- (di atas ditautkan dari) Kapan menggunakan MongoDB atau sistem basis data berorientasi dokumen lainnya? ^{saat ini dihapus pada SO} ( selengkapnya )
- https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
- Kapan menggunakan CouchDB vs RDBMS
RDBMS banyak menggunakan pengindeksan untuk kinerja. Pada basis data yang sangat besar, ini dapat berdampak buruk pada kinerja atau bahkan mengurangi jumlah optimal baris per DB / Shard yang membutuhkan lebih banyak perangkat keras
Tidak ideal jika Anda menyimpan sejumlah besar data tetapi lebih jarang membaca
Jika Anda tidak memiliki banyak hubungan luar negeri, relasional database mungkin tidak ideal (penyimpanan dokumen)

— Matthew Read
sumber

4

"RDBMS banyak menggunakan pengindeksan untuk kinerja" Bukankah pengindeksan digunakan dengan MongoDB juga?

— Rotareti

Kapan menggunakan MongoDB atau sistem basis data berorientasi dokumen lainnya? saat ini dihapus pada SO ... tidak lebih .. telah membuka kembali pertanyaan dan melindunginya Tidak yakin alasan di balik penghapusan.

— Rahul

9

Ketika data Anda tidak bersifat relasional, akan ada manfaat besar untuk menggunakan basis data NoSQL seperti kinerja dan skalabilitas (tentu saja tergantung pada keadaan). Beberapa desain patters seperti CQRS membuatnya jauh lebih mudah untuk memanfaatkan data non relasional di area yang secara konvensional akan menuntut penggunaan eksklusif dari database SQL.

Adalah umum untuk menggunakan database seperti mongo untuk data yang di-cache. Misalnya, jika Anda perlu membuat laporan, Anda bisa melakukan kueri SQL rumit yang menggabungkan dan mengagregasi banyak data dengan cepat, atau Anda bisa mengambil satu dokumen json dari database mongo Anda yang sudah memiliki semua yang Anda butuhkan untuk menghasilkan laporan. Ini membuat membaca data sangat mudah (dan cepat!), Tetapi dapat membuat penulisan data cukup rumit (di sinilah CQRS masuk).

— Graeme Hill
sumber

8

Basis data seperti MongoDB sangat bagus ketika Anda biasanya tahu di mana data Anda (tidak perlu menulis beberapa pertanyaan rumit). Dengan Mongo, "terkait" data bersarang di data induk atau memiliki kunci utama / asing. Ini bagus jika, misalnya, Anda memiliki Posting dan Komentar; umumnya, Anda tidak akan menampilkan komentar di luar konteks kiriman, jadi masuk akal jika komentar terkandung di dalam kiriman (dengan cara itu Anda mendapatkan semua komentar untuk kiriman tanpa perlu kueri tabel terpisah).

MongoDB adalah schemaless. Ini berarti bahwa ia akan mengambil struktur data apa pun yang Anda berikan padanya, untuk sebagian besar.

Di sisi lain, jika Anda perlu menggunakan fungsi agregat dan merasakan kebutuhan untuk meminta data dengan cara yang kompleks yang tidak dapat dicapai melalui embed atau hubungan sederhana di Mongo, saat itulah Anda tahu saatnya menggunakan RDBMS seperti MySQL atau PostgreSQL.

MongoDB tidak dimaksudkan untuk menggantikan SQL. Ini hanya memenuhi kebutuhan yang berbeda, dan MongoDB dan RDBMS dapat digunakan bersamaan. Menurut pendapat saya, MongoDB tidak terlalu penting jika Anda tidak membutuhkan data Anda untuk menjadi fleksibel atau tertanam dalam dokumen induk. Pengembangan dengan MongoDB sangat menyenangkan karena ada langkah-langkah yang jauh lebih sedikit terlibat dalam mendapatkan proyek (katakanlah dalam Rails) dan berjalan. Perlu melakukan perubahan? Tidak masalah. Cukup tambahkan atribut ke model Anda. Selesai.

Saya tidak dapat berbicara untuk banyak basis data NoSQL lainnya, meskipun saya tahu bahwa mereka biasanya dirancang serupa untuk memenuhi kebutuhan spesifik yang tidak dapat dipenuhi oleh RDBMS. Beberapa berada sepenuhnya dalam memori atau dapat dengan mudah di-shard atau diskalakan. Saya cukup yakin bahwa Cassandra dirancang untuk terus beroperasi tanpa kehilangan data jika sebuah simpul turun. Redis pada dasarnya adalah toko nilai kunci yang berada di memori (dengan disk periodik menulis untuk kegigihan), tetapi juga memiliki kemampuan untuk menyimpan tipe data seperti set dan mengurutkannya.

— Ravenstine
sumber

6

Kemenangan utama adalah ketika Anda ingin berbagi data atau memiliki multi master database. Anda dapat membuang data di MySQL tetapi itu berubah menjadi sakit besar. Jika Anda melakukan banyak penulisan, seringkali berguna untuk membagikan data di beberapa server, masalahnya adalah jika Anda ingin memiliki konsistensi referensial yang kuat saat melakukan ini, akan sangat sulit jika tidak mustahil mencari teorema CAP.

Database SQL memiliki konsistensi yang sangat baik tetapi dukungan partisi benar-benar buruk, database NoSQL cenderung sebaliknya. Mudah dipartisi tetapi seringkali disebut konsistensi akhirnya. Jika Anda membangun situs perpesanan yang ok, untuk bank mungkin tidak OK.

Kelebihannya adalah bahwa sekarang ada beberapa model untuk cara menyimpan data sehingga ada pilihan dalam cara Anda mengimplementasikan hal-hal, sementara sebelumnya yang Anda miliki adalah database SQL.

Radio SE memiliki beberapa episode yang baik tentang hal ini.

— Zachary K
sumber

Harus diingat bahwa sharding sangat bergantung pada arsitektur pusat data Anda. Jika Anda memiliki rak server, kinerjanya luar biasa. Pada DC yang didistribusikan, tidak terlalu banyak. Menyetujui apa yang Anda katakan tentang kemudahan umum untuk berpartisi pada NoSql DB - tetapi keandalan adalah perhatian utama.

— Apoorv Khurasia

Jika Anda melakukan banyak penulisan, Anda mungkin hanya memiliki 2 model: indeks baca denronalized stronly AND dan model tulis yang tidak diindeks. Replikasi alami diperlukan yang menambah kompleksitas. Anda harus mengevaluasi apa yang lebih tidak menguntungkan bagi Anda: mengatasi keterbatasan NoSQL yaitu melakukan lebih banyak pemrograman sendiri untuk mencocokkan catatan dalam domain java, atau memiliki teknologi replikasi DB yang ada melakukan pekerjaan atau Anda yang akan dikenakan biaya lebih banyak pada istilah konfigurasi dan perangkat keras.

— Lawrence

1

MongoDB berfungsi dengan baik ketika Anda menulis banyak data, dan ketika kebutuhan kueri Anda tidak terlalu rumit. Oleh karena itu, MongoDB sangat cocok ketika Anda menerapkan CQRS dengan Event Sourcing di sisi Command - yaitu, toko acara Anda adalah database MongoDB.

Di sisi permintaan, kami masih menggunakan SQL Server db dengan tampilan dan Layanan Data WCF di atas, karena fleksibilitasnya. Saya pikir dalam banyak kasus Anda akan benar-benar membutuhkan kekuatan DB relasional untuk query.

— Roy Dictus
sumber

Jika Anda menulis banyak data, bukankah global global lock akan memengaruhi Anda secara negatif?

— Apoorv Khurasia

1

Perhatikan bahwa Mongodb tidak lagi menggunakan kunci tulis global (dan sudah diperbarui untuk tidak memerlukannya ketika komentar di atas diposting).

— Jules

1

Perbedaan langsung dan mendasar antara MongoDB dan RDBMS adalah model data yang mendasarinya. Database relasional menyusun data menjadi tabel dan baris, sementara MongoDB menyusun data menjadi koleksi dokumen JSON. JSON adalah format data yang dapat menggambarkan sendiri dan dapat dibaca manusia. Awalnya dirancang untuk pertukaran ringan antara browser dan server, ini telah diterima secara luas untuk berbagai jenis aplikasi.

Dokumen JSON sangat berguna untuk manajemen data karena beberapa alasan. Dokumen JSON terdiri dari seperangkat bidang yang merupakan pasangan nilai kunci sendiri. Ini berarti setiap dokumen JSON membawa desain skema yang dapat dibaca manusia sendiri ke mana pun ia pergi, memungkinkan dokumen untuk dengan mudah berpindah antara database dan aplikasi klien tanpa kehilangan artinya.

JSON juga merupakan format data alami untuk digunakan di lapisan aplikasi. JSON mendukung struktur data yang lebih kaya dan lebih fleksibel daripada tabel yang terdiri dari kolom dan baris. Selain mendukung tipe bidang seperti angka, string, Boolean, dll., Bidang JSON dapat berupa array atau sub-objek bersarang. Ini berarti kita dapat mewakili satu set hubungan canggih yang merupakan representasi yang lebih dekat dari objek yang bekerja dengan aplikasi kita. Menggunakan dokumen JSON dalam database kami berarti kami tidak memerlukan mapper relasional objek antara database kami dan aplikasi yang dilayaninya. Kami dapat menyimpan data kami dalam bentuk yang benar

— Diwakar upadhyay
sumber

1

Jika data Anda membutuhkan banyak kueri, maka solusi NoSQL tidak bagus dan ketika Anda membutuhkan dukungan transaksional (ACID), maka NoSql bukan yang paling cocok. Saya pikir NoSQL bersinar ketika Anda memiliki banyak bacaan yang harus cepat dan ketika strukturnya agak adhoc, Anda mengambil dengan dokumen atau oleh struktur halaman, sesuatu seperti itu. Tetapi banyak solusi NoSQL meningkat sangat cepat sehingga kekurangan mungkin segera hilang. Pokoknya saya pikir database relasional masih cocok untuk sebagian besar aplikasi.

— marko
sumber