Kapan saya harus menggunakan database NoSQL alih-alih database relasional? Apakah boleh menggunakan keduanya di situs yang sama?

141

Apa keuntungan menggunakan database NoSQL? Saya sudah membaca banyak tentang mereka belakangan ini, tetapi saya masih tidak yakin mengapa saya ingin menerapkannya, dan dalam keadaan apa saya ingin menggunakannya.

smfoote
sumber

Jawaban:

84

Database relasional memberlakukan ACID . Jadi, Anda akan memiliki penyimpanan data berorientasi transaksi berbasis skema. Ini terbukti dan cocok untuk 99% aplikasi dunia nyata. Anda bisa melakukan apa saja dengan database relasional.

Namun, ada batasan pada kecepatan dan penskalaan dalam hal penyimpanan data dengan ketersediaan besar. Misalnya, Google dan Amazon memiliki terabyte data yang disimpan di pusat data besar. Permintaan dan penyisipan tidak tampil dalam skenario ini karena sifat pemblokiran / skema / transaksi dari RDBM. Itulah alasan mereka menerapkan basis data mereka sendiri (sebenarnya, toko-toko kunci) untuk peningkatan kinerja dan skalabilitas yang besar.

Database NoSQL telah ada sejak lama - hanya istilahnya yang baru. Beberapa contoh adalah grafik, objek, kolom, XML, dan basis data dokumen.

Untuk pertanyaan kedua: Apakah boleh menggunakan keduanya di situs yang sama?

Kenapa tidak? Keduanya melayani tujuan yang berbeda bukan?

RameshVel
sumber
1
Saya tidak berpikir ACID eksklusif untuk database relasional. Anda dapat memiliki jaminan daya tahan, transaksi, melihat konsistensi dalam database non-relasional.
Thilo
@RamshVel dapatkah Anda memberikan contoh basis data jenis toko kunci-nilai? Terima kasih.
Rachael
1
@Rachael, beberapa contoh redis, leveldb, dan riak .. ada banyak sekali, Anda bisa google
RameshVel
76

Solusi NoSQL biasanya dimaksudkan untuk menyelesaikan masalah yang tidak cocok untuk database relasional, terlalu mahal untuk digunakan (seperti Oracle) atau mengharuskan Anda untuk mengimplementasikan sesuatu yang merusak sifat relasional db Anda.

Keuntungan biasanya spesifik untuk penggunaan Anda, tetapi kecuali jika Anda memiliki semacam masalah pemodelan data Anda dalam RDBMS saya tidak melihat alasan mengapa Anda akan memilih NoSQL.

Saya sendiri menggunakan MongoDB dan Riak untuk masalah khusus di mana RDBMS bukan solusi yang layak, untuk semua hal lain saya menggunakan MySQL (atau SQLite untuk pengujian).

Jika Anda memerlukan dB NoSQL yang biasanya Anda ketahui, kemungkinan alasannya adalah:

  • klien menginginkan 99,999% ketersediaan di situs dengan lalu lintas tinggi.
  • data Anda tidak masuk akal dalam SQL, Anda menemukan diri Anda melakukan beberapa pertanyaan GABUNG untuk mengakses beberapa informasi.
  • Anda melanggar model relasional, Anda memiliki CLOB yang menyimpan data yang didenormalisasi dan Anda menghasilkan indeks eksternal untuk mencari data itu.

Jika Anda tidak memerlukan solusi NoSQL, ingatlah bahwa solusi ini tidak dimaksudkan sebagai pengganti RDBMS melainkan sebagai alternatif di mana yang sebelumnya gagal dan yang lebih penting bahwa mereka relatif baru karena mereka masih memiliki banyak bug dan fitur yang hilang.

Oh, dan mengenai pertanyaan kedua, tidak apa-apa untuk menggunakan teknologi apa pun dalam hubungannya dengan yang lain, jadi untuk melengkapi dari pengalaman saya, MongoDB dan MySQL bekerja dengan baik selama mereka tidak menggunakan mesin yang sama

Asaf
sumber
3
Terima kasih atas jawabannya. Contoh kapan Anda menggunakan NoSQL tidak jelas. Saya berharap untuk use case yang lebih spesifik sehingga saya dapat memutuskan apakah ada data saya yang akan lebih baik disimpan dalam database NoSQL.
smfoote
Saya mencoba untuk tidak menjawab pertanyaan yang sama dua kali, lihat jawaban saya sebelumnya untuk pertanyaan yang sangat mirip stackoverflow.com/questions/3621415/...
Asaf
Saya setuju dengan jawaban Asaf yang luar biasa, hanya ada beberapa skenario ketika Anda harus membutuhkan NoSQL di atas RDBMS. Saya melihat NoSQL lebih sebagai cadangan db atau "add-on db" daripada db utama. Saya belum melihat sistem yang bagus, di mana inti db adalah NoSQL.
Jo Smo
38

Martin Fowler memiliki video yang luar biasa yang memberikan penjelasan yang baik tentang basis data NoSQL. Tautan langsung ke alasannya untuk menggunakannya, tetapi seluruh video berisi informasi yang baik.

  1. Anda memiliki sejumlah besar data - terutama jika Anda tidak dapat memasukkan semuanya pada satu server fisik karena NoSQL dirancang untuk menyesuaikan skala dengan baik.

  2. Ketidakcocokan impedansi objek-relasional - Objek domain Anda tidak cocok dengan baik dalam skema basis data relaitional. NoSQL memungkinkan Anda untuk mempertahankan data Anda sebagai dokumen (atau grafik) yang mungkin memetakan lebih dekat dengan model data Anda.

Despertar
sumber
16

NoSQL adalah sistem basis data di mana data disusun ke dalam dokumen (MongoDB), pasangan kunci-nilai (MemCache, Redis), bentuk struktur grafik (Neo4J).

Mungkin di sini ada beberapa pertanyaan dan jawaban untuk "Kapan harus menggunakan NoSQL":

  1. Membutuhkan skema yang fleksibel atau menangani data seperti pohon?
    Secara umum, dalam pengembangan tangkas kami mulai merancang sistem tanpa mengetahui semua persyaratan di muka, di mana nantinya sepanjang pengembangan sistem basis data mungkin perlu mengakomodasi perubahan desain yang sering, menampilkan MVP (produk Minimal yang layak). Atau Anda berurusan dengan skema data yang bersifat dinamis. mis. Log Sistem, contoh yang sangat tepat adalah log AWS cloudwatch.

  2. Kumpulan data sangat luas / besar?
    Ya basis data NoSQL adalah kandidat yang lebih baik untuk aplikasi di mana basis data perlu mengelola jutaan atau bahkan milyaran catatan tanpa mengorbankan kinerja.

  3. Trade off antara penskalaan konsistensi
    Tidak seperti RDMS, basis data NoSQL dapat kehilangan data kecil di sana-sini (Catatan: probabilitas .x%), tetapi mudah untuk diukur dalam hal kinerja. Contoh: Ini mungkin baik untuk menyimpan orang yang sedang online di aplikasi pesan instan, token di db, mencatat statistik lalu lintas situs web.

  4. Melakukan Operasi Geolokasi: MongoDB kaya dukungan untuk melakukan operasi GeoQuerying & Geolokasi. Saya sangat menyukai fitur MongoDB ini.

Singkatnya, MongoDB sangat cocok untuk aplikasi di mana Anda dapat menyimpan data terstruktur dinamis dalam skala besar.

Hrishikesh
sumber
4
"Basis data NoSQL dapat kehilangan data kecil di sana-sini" WTF !? Sekarang siapa yang waras yang ingin mengambil risiko itu? Ini pasti salah.
Jay Q
1
@ JayQ. Ya, itu mungkin salah. Itu sebabnya saya katakan * mungkin. Lalu mengapa kita tidak bisa menggunakan NpSQL DB untuk operasi transaksional?
Hrishikesh
7

Beberapa informasi penting tidak ada untuk menjawab pertanyaan: Kasus penggunaan mana yang harus dapat dicakup oleh database? Apakah analisis yang rumit harus dilakukan dari data yang ada ( OLAP ) atau apakah aplikasi harus dapat memproses banyak transaksi ( OLTP )? Apa struktur datanya? Itu jauh dari akhir waktu pertanyaan.

Dalam pandangan saya, adalah salah untuk membuat keputusan teknologi berdasarkan kata kunci yang berani tanpa tahu persis apa yang ada di baliknya. NoSQL sering dipuji karena skalabilitasnya. Tetapi Anda juga harus tahu bahwa penskalaan horizontal (lebih dari beberapa node) juga memiliki harganya dan tidak gratis. Maka Anda harus berurusan dengan masalah-masalah seperti konsistensi akhirnya dan menentukan cara menyelesaikan konflik data jika mereka tidak dapat diselesaikan di tingkat database. Namun, ini berlaku untuk semua sistem basis data terdistribusi.

Kegembiraan pengembang dengan kata "schema less" di NoSQL pada awalnya juga sangat besar. Kata kunci ini dengan cepat kecewa setelah analisis teknis, karena dengan benar tidak memerlukan skema saat menulis, tetapi mulai berlaku saat membaca. Itu sebabnya harus benar "skema baca". Mungkin tergoda untuk dapat menulis data atas kebijaksanaan sendiri. Tetapi bagaimana saya menangani situasi jika ada data yang ada tetapi versi baru dari aplikasi mengharapkan skema yang berbeda?

Model dokumen (seperti dalam MongoDB, misalnya) tidak cocok untuk model data di mana ada banyak hubungan antara data. Bergabung harus dilakukan pada level aplikasi, yang merupakan upaya tambahan dan mengapa saya harus memprogram hal-hal yang harus dilakukan database.

Jika Anda berpendapat bahwa Google dan Amazon telah mengembangkan basis datanya sendiri karena RDBMS konvensional tidak dapat lagi menangani banjir data, Anda hanya dapat mengatakan: Anda bukan Google dan Amazon. Perusahaan-perusahaan ini adalah ujung tombak, sekitar 0,01% dari skenario di mana database tradisional tidak lagi cocok, tetapi untuk seluruh dunia mereka.

Apa yang tidak signifikan: SQL telah ada selama lebih dari 40 tahun dan jutaan jam pengembangan telah masuk ke sistem besar seperti Oracle atau Microsoft SQL. Ini harus dicapai oleh beberapa database baru. Kadang-kadang juga lebih mudah untuk menemukan admin SQL daripada seseorang untuk MongoDB. Yang membawa kita ke pertanyaan pemeliharaan dan manajemen. Subjek yang tidak benar-benar seksi, tetapi itu adalah bagian dari keputusan teknologi.

Stefan Prugg
sumber
1
tampaknya benar tetapi saya tidak berpikir itu juga benar untuk membandingkan berapa banyak waktu yang dihabiskan jika itu adalah kasus semua orang akan menggunakan bahasa assembly di semua aplikasi mereka, saya lebih suka mengatakan itu selalu turun ke aplikasi Anda dan usecase
Gopherine
3

Saya menemukan pertanyaan ini sambil mencari alasan meyakinkan untuk menyimpang dari desain RDBMS.

Ada posting bagus oleh Julian Brown yang menyoroti kendala dari sistem terdistribusi. Konsep ini disebut Teorema CAP Brewer yang secara ringkas berbunyi:

Tiga persyaratan sistem terdistribusi adalah: Konsistensi, Ketersediaan, dan Toleransi partisi (singkatnya CAP). Tetapi Anda hanya dapat memiliki dua dari mereka sekaligus.

Dan inilah bagaimana saya merangkumnya untuk diri saya sendiri:

Anda lebih baik pergi untuk NoSQL jika Konsistensi adalah apa yang Anda korbankan.

Jermin Bazazian
sumber
0

Saya merancang dan mengimplementasikan solusi dengan database NoSQL dan berikut ini adalah daftar pos pemeriksaan saya untuk membuat keputusan untuk menggunakan SQL atau NoSQL yang berorientasi dokumen .

JANGAN

SQL tidak usang dan tetap menjadi alat yang lebih baik dalam beberapa kasus. Sulit untuk membenarkan penggunaan NoSQL yang berorientasi dokumen saat

  • Perlu OLAP / OLTP
  • Ini adalah proyek kecil / struktur DB sederhana
  • Perlu kueri ad hoc
  • Tidak dapat menghindari konsistensi langsung
  • Persyaratan tidak jelas
  • Kurangnya pengembang yang berpengalaman

LAKUKAN

Jika Anda tidak memiliki persyaratan tersebut atau dapat menguranginya, maka berikut adalah 2 alasan di mana Anda dapat memperoleh manfaat dari NoSQL:

  • Perlu dijalankan pada skala
  • Kemudahan pengembangan (integrasi yang lebih baik dengan tumpukan teknologi Anda, tidak perlu dalam ORM, dll.)

Info lebih lanjut

Dalam posting blog saya, saya menjelaskan alasannya lebih terinci:

Catatan: di atas hanya berlaku untuk dokumen berorientasi NoSQL saja. Ada jenis lain dari NoSQL, yang memerlukan pertimbangan lain.

Alex Klaus
sumber
0

Menangani Sejumlah Besar Operasi Baca Tulis

Lihatlah ke database NoSQL saat Anda perlu melakukan skala cepat. Dan kapan Anda biasanya perlu mengukur cepat?

Ketika ada sejumlah besar operasi baca-tulis di situs web Anda & ketika berhadapan dengan sejumlah besar data, basis data NoSQL paling cocok dalam skenario ini. Karena mereka memiliki kemampuan untuk menambahkan node on the fly, mereka dapat menangani lebih banyak lalu lintas bersamaan & sejumlah besar data dengan latensi minimal.

Fleksibilitas Dengan Pemodelan Data

Isyarat kedua adalah selama fase awal pengembangan ketika Anda tidak yakin tentang model data, desain database, hal-hal yang diharapkan berubah dengan cepat. Basis data NoSQL menawarkan kami lebih banyak fleksibilitas.

Konsistensi Akhirnya Lebih Dari Konsistensi Yang Kuat

Lebih baik untuk memilih basis data NoSQL ketika kita boleh menyerah pada konsistensi yang kuat dan ketika kita tidak memerlukan transaksi.

Contoh yang baik dari ini adalah situs web jejaring sosial seperti Twitter. Ketika sebuah tweet dari seorang selebriti meledak dan semua orang menyukai dan men-tweetnya dari seluruh dunia. Apakah masalah jika jumlah suka naik atau turun sedikit untuk sementara waktu?

Selebriti itu pasti tidak akan peduli jika bukannya 5 juta 500 suka yang sebenarnya, sistem menunjukkan jumlah seperti 5 juta 250 untuk sementara waktu.

Ketika aplikasi besar digunakan pada ratusan server yang tersebar di seluruh dunia, node yang terdistribusi secara geografis membutuhkan waktu untuk mencapai konsensus global.

Sampai mereka mencapai konsensus, nilai entitas tidak konsisten. Nilai entitas akhirnya menjadi konsisten setelah beberapa saat. Inilah yang akhirnya Konsistensi.

Padahal inkonsistensi bukan berarti ada semacam kehilangan data. Ini berarti bahwa data memerlukan waktu singkat untuk melakukan perjalanan di seluruh dunia melalui kabel internet di bawah lautan untuk mencapai konsensus global dan menjadi konsisten.

Kami mengalami perilaku ini sepanjang waktu. Terutama di YouTube. Seringkali Anda akan melihat video dengan 10 tampilan dan 15 suka. Bagaimana ini mungkin?

Ini bukan. Tampilan sebenarnya sudah lebih dari suka. Hanya saja jumlah tampilan tidak konsisten dan membutuhkan waktu singkat untuk diperbarui.

Menjalankan Analisis Data

Basis data NoSQL juga cocok untuk kasus penggunaan analitik data, di mana kita harus berurusan dengan masuknya sejumlah besar data.

Sultan yang Cerah
sumber