Skenario Penggunaan Kasus NoSQL atau KAPAN menggunakan NoSQL


252

Dengan semua hype itu tampaknya sangat sulit untuk menemukan informasi yang dapat dipercaya kapan harus menggunakan ini. Jadi saya mengajukan pertanyaan berikut, dan saya minta maaf jika ini benar-benar pertanyaan bodoh sebelumnya:

  1. Haruskah saya menggunakan NoSQL untuk data pengguna? Misalnya profil, nama pengguna + kata sandi, dll.
  2. Haruskah saya menggunakan NoSQL untuk konten penting? Misalnya artikel, posting blog, inventaris produk, dll.

Saya berasumsi tidak? Dan saya merasa NoSQL hanya untuk hal-hal yang dapat diakses dengan cepat dan tidak masalah untuk kehilangan data. Tetapi saya juga membaca bahwa aplikasi NoSQL memiliki redundansi bawaan sehingga saya tidak kehilangan data?

Juga jika 2 contoh di atas buruk, bisakah Anda memberi saya kasus penggunaan bisnis khusus di mana saya akan menggunakan NoSQL? Saya melihat banyak deskripsi umum tetapi tidak banyak contoh dunia nyata. Satu-satunya hal yang dapat saya pikirkan adalah perpesanan dan analitik antar pengguna.

Terima kasih!

Jawaban:


183

Ini benar-benar merupakan "itu tergantung" pertanyaan agak. Beberapa poin umum :

  • NoSQL biasanya baik untuk data yang tidak terstruktur / "schemaless" - biasanya, Anda tidak perlu secara eksplisit mendefinisikan skema Anda di muka dan hanya bisa memasukkan bidang baru tanpa upacara apa pun
  • NoSQL biasanya mendukung skema yang dinormalisasi karena tidak ada dukungan untuk GABUNGAN per dunia RDBMS. Jadi, Anda biasanya memiliki representasi data Anda yang rata dan terdenormalisasi.
  • Menggunakan NoSQL tidak berarti Anda bisa kehilangan data. DB yang berbeda memiliki strategi yang berbeda pula. misalnya MongoDB - Anda pada dasarnya dapat memilih level apa untuk menukar kinerja vs potensi kehilangan data - kinerja terbaik = ruang lingkup yang lebih besar untuk kehilangan data.
  • Seringkali sangat mudah untuk meningkatkan solusi NoSQL. Menambahkan lebih banyak node untuk mereplikasi data adalah salah satu cara untuk a) menawarkan lebih banyak skalabilitas dan b) menawarkan lebih banyak perlindungan terhadap kehilangan data jika satu node turun. Tetapi sekali lagi, tergantung pada NoSQL DB / konfigurasi. NoSQL tidak selalu berarti "kehilangan data" seperti yang Anda simpulkan.
  • IMHO, pertanyaan / pelaporan kompleks / dinamis paling baik dilayani dari RDBMS. Seringkali fungsi permintaan untuk NoSQL DB terbatas.
  • Itu tidak harus menjadi 1 atau pilihan lain. Pengalaman saya telah menggunakan RDBMS bersama dengan NoSQL untuk kasus penggunaan tertentu.
  • DB NoSQL seringkali tidak memiliki kemampuan untuk melakukan operasi atom di beberapa "tabel".

Anda benar-benar perlu melihat dan memahami berbagai jenis toko NoSQL, dan bagaimana mereka menyediakan skalabilitas / keamanan data, dll. Sulit untuk memberikan jawaban menyeluruh karena semuanya berbeda dan menangani berbagai hal secara berbeda. .

Untuk MongoDb sebagai contoh, lihat Kasus Penggunaan mereka untuk melihat apa yang mereka sarankan sebagai "cocok" dan "kurang cocok" menggunakan MongoDb.


16
Klaim tentang NoSQL tidak mendukung penggabungan adalah menyesatkan. Beberapa database NoSQL sebenarnya jauh lebih baik untuk digabungkan daripada database relasional. Beberapa tidak mendukung sama sekali. Jawaban ini tampaknya lebih tentang MongoDB pada khususnya daripada tentang NoSQL pada umumnya.
Alan Plum

1
Ringkasan yang bagus. @AlanPlum, database NoSQL spesifik apa yang Anda maksud?
Brian

2
@brian Saya adalah kontributor ArangoDB ( arangodb.com ), yang merupakan campuran dari database dokumen (pikirkan MongoDB) dan database grafik (pikirkan Neo4J) dengan tidak hanya bergabung murah tetapi juga transaksi nyata. Yang mengatakan, database NoSQL bukan kelompok homogen dan tidak mungkin untuk menggeneralisasi dari salah satu database NoSQL ke seluruh "kategori".
Alan Plum

Jika Anda menemukan diri Anda mempertimbangkan untuk menggunakan RDB karena "bergabung tidak didukung" di NoSQL, saya sangat menyarankan menonton video ini dari AWS re: Invent. Hancurkan seluruh pendekatan NoSQL! Banyak membantu saya. youtu.be/HaEPXoXVf2k
dillon.harless

9

Saya pikir Nosql "lebih cocok" dalam skenario ini setidaknya (lebih banyak pelengkap dipersilahkan)

  1. Mudah untuk skala secara horizontal dengan hanya menambahkan lebih banyak node.

  2. Permintaan kumpulan data besar

    Bayangkan banyak tweet yang diposting di twitter setiap hari. Di RDMS, mungkin ada tabel dengan jutaan (atau miliaran?) Baris, dan Anda tidak ingin melakukan kueri pada tabel tersebut secara langsung, bahkan tidak menyebutkan, sebagian besar waktu, penggabungan tabel juga diperlukan untuk kueri kompleks.

  3. Bottleneck Disk I / O

    Jika sebuah situs web perlu mengirimkan hasil ke pengguna yang berbeda berdasarkan info waktu nyata pengguna, kami mungkin berbicara tentang puluhan atau ratusan ribu permintaan baca / tulis SQL per detik. Maka disk i / o akan menjadi hambatan serius.


20
Saya tidak mengerti apa yang bisa menjadi masalah dengan RDBMS untuk # 2. Dan NoSQL memiliki lebih sedikit disk I / O sesuai # 3?
avi

5
Seperti @avi katakan, saya pikir tidak ada masalah untuk # 2 selama Anda query tabel di atas indeks. Jutaan baris? Ok, ambil hanya indeks yang ingin saya gunakan
Xtreme Biker

11
# 2 dan 3 keduanya salah. Untuk 2, saya telah melakukan tes kinerja pada mengimpor / mengekspor data dan melihat SQL Server 2014 menghancurkan Mongo pada impor dan ekspor data besar. Untuk 3, data yang sangat diketik dalam SQL biasanya memakan waktu (saya telah melihat lebih dari 50% sebelum kompresi) jauh lebih sedikit ruang daripada database dokumen.
brian

7
Ya, dan bahkan untuk # 1, saya tidak mengerti. Peningkatan adalah bagian dari kontrak pengelompokan yang diusulkan semua rdbms besar
Sebas

2
Ketiganya salah jika Anda memiliki uang tidak terbatas
Chazt3n
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.