Mengapa NoSQL lebih cepat dari SQL?


48

Baru-baru ini saya ditanya:

Mengapa NoSQL lebih cepat dari SQL?

Saya tidak setuju dengan premis dari pertanyaan ... itu hanya omong kosong bagi saya pribadi. Saya tidak bisa melihat peningkatan kinerja dengan menggunakan NoSQL, bukan SQL. Mungkin SQL lebih dari NoSQL, ya tapi tidak dengan cara itu.

Apakah saya kehilangan sesuatu tentang NoSQL?


3
Jika Anda tidak dapat melihat peningkatan kinerja, itulah yang Anda katakan. Faktanya adalah bahwa sebagian besar solusi NoSQL melupakan satu (atau lebih) properti ACID dari basis data relasional, sehingga mereka melakukan lebih sedikit.
Oded

1
Ada beberapa alur kerja (dan struktur data) yang tidak dapat dengan mudah dipetakan ke database relasional ACID-enabled tradisional. Bagi mereka, Anda dapat melihat peningkatan kinerja yang sangat besar dengan menggunakan database NoSQL. Namun, jika Anda hanya mengambil SQL DB yang sudah ada (dirancang dengan baik) dan memasukkannya ke dalam Database NoSQL, maka kinerja Anda pasti akan menderita.
Joachim Sauer

1
Jawabannya adalah: Apakah sudah ditetapkan sebagai lebih cepat? Dan lebih cepat dalam hal apa? Waktu pengembangan? Membaca waktu? Menulis waktu? Jenis tulisan apa? Untuk apa kita membandingkannya? Kueri multi-tabel? Bergabung?
Rolf

Jawaban:


65

Ada banyak solusi NoSQL, masing-masing dengan kekuatan dan kelemahannya sendiri, jadi yang berikut harus diambil dengan sebutir garam.

Tetapi pada dasarnya, apa yang dilakukan oleh banyak basis data NoSQL adalah mengandalkan proses denormalisasi dan mencoba mengoptimalkan untuk kasus yang dinormalisasi. Misalnya, Anda membaca posting blog bersama dengan komentarnya dalam database berorientasi dokumen. Seringkali, komentar akan disimpan bersama dengan pos itu sendiri. Ini berarti bahwa akan lebih cepat untuk mengambil semuanya bersama-sama, karena mereka disimpan di tempat yang sama dan Anda tidak harus melakukan join.

Tentu saja, Anda dapat melakukan hal yang sama dalam SQL, dan denormalisasi adalah praktik yang umum ketika seseorang membutuhkan kinerja. Hanya saja banyak solusi NoSQL yang direkayasa sejak awal untuk selalu digunakan dengan cara ini. Anda kemudian mendapatkan tradeoffs biasa: misalnya, menambahkan komentar pada contoh di atas akan lebih lambat karena Anda harus menyimpan seluruh dokumen dengan itu. Dan begitu Anda telah mendenormalisasi, Anda harus menjaga integritas data dalam aplikasi Anda.

Selain itu, dalam banyak solusi NoSQL, tidak mungkin untuk melakukan penggabungan sewenang-wenang, karena itu permintaan sewenang-wenang. Beberapa database, seperti CouchDB, mengharuskan Anda untuk memikirkan terlebih dahulu pertanyaan yang Anda perlukan dan menyiapkannya di dalam DB.

Semua dalam semua, itu bermuara pada mengharapkan skema denormalized dan mengoptimalkan membaca untuk situasi itu, dan ini bekerja dengan baik untuk data yang tidak sangat relasional dan yang membutuhkan lebih banyak membaca daripada menulis.


4
Ini, dengan cara dapat direalisasikan dengan tampilan terwujud sederhana, atau lapisan cache, sambil tetap mendapat manfaat dari semua kebaikan SQL. Apa pun yang dimodelkan dengan benar adalah relasional, dan duplikasi data logis bukanlah solusi (tampilan mat. Adalah duplikasi tetapi bukan duplikasi logis karena ini hanyalah gambar dari sesuatu yang lain).
Morg.

Seperti yang saya katakan dalam jawabannya, orang dapat melakukan hal yang sama dalam SQL; hanya saja ketika ini menjadi aturan alih-alih pengecualian, database NoSQL biasanya lebih cepat dan lebih alami untuk digunakan. Secara teori, SQL adalah model terbaik yang bisa digunakan, tetapi ketika data tumbuh melebihi ukuran tertentu, SQL tidak dapat mengakomodasi beberapa model, dan duplikasi data menjadi lebih cepat dan lebih mudah untuk dipikirkan.
Andrea

3
Itu banteng. Model relasional mencakup semua yang Anda dapat lakukan di NoSQL dan banyak lagi. Satu-satunya keuntungan dari NoSQL adalah bahwa pendekatan penskalaan yang sederhana dan tidak konsisten dibangun dan mudah digunakan. Itu tidak ada hubungannya dengan SQL, dan segala sesuatu yang berkaitan dengan tidak peduli tentang properti ACID. Anda dapat memiliki pekerjaan sinkronisasi antara node SQL independen yang akan memiliki sifat penskalaan dan konsistensi yang persis sama (sangat buruk) yang dimiliki toko NoSQL. Perbedaannya adalah bahwa node SQL juga dapat memiliki konsistensi jika Anda memilih untuk melakukannya.
Morg.

1
Bagaimana jika Anda memiliki 5.000.000 juta baris data dan Anda ingin mendapatkan komentar dari semuanya dengan beberapa syarat. Bukankah lebih cepat jika Anda memiliki indeks pada kolom komentar pada tabel dengan SQL? Pengindeksan Teks Lengkap akan lebih meningkatkan ini.
jwize

@morg - "Model relasional mencakup semua yang Anda dapat lakukan di NoSQL dan banyak lagi." Tidak juga, tidak. Ada banyak contoh jenis data yang sangat tidak sesuai dengan model relasional yang memaksa data ke dalamnya menghasilkan inefisiensi besar-besaran. Contoh: game online memiliki fasilitas untuk menyimpan inventaris pemain. Para pemain memiliki set slot bernomor terbatas, yang masing-masing dapat menyimpan satu atau lebih item dari tipe tertentu. Ada sekitar 50 jenis barang, masing-masing memiliki 4-6 atribut terkait, dengan beberapa tumpang tindih, sehingga ada sekitar 80 kemungkinan atribut ...
Jules

27

Hal yang Anda lewatkan tentang NoSQL adalah bahwa NoSQl tidak dapat dibandingkan dengan SQL dengan cara apa pun. NoSQL adalah nama dari semua teknologi persistensi yang bukan SQL. DB dokumen, DB nilai kunci, DB acara semuanya adalah NoSQL. Mereka semua berbeda di hampir semua aspek, baik itu struktur data yang disimpan, permintaan, kinerja dan alat yang tersedia.

Jadi, jika seseorang mengajukan pertanyaan seperti itu pada Anda saat wawancara, ini harus menjadi jawabannya.


4
Jika ada satu fitur pembunuh dari NoSQL saya akan mengatakan itu ADALAH skalabilitas. Itu sebabnya Facebook dan Google menggunakannya. Karena volume data yang sangat besar. NoSQL: ketika Anda harus berurusan dengan sejumlah besar Data.
Pieter B

16

Basis data 'NoSQL' (atau lebih tepatnya: non-relasional) melepaskan beberapa fitur dari basis data tradisional untuk kecepatan, tetapi yang lebih penting untuk skalabilitas horizontal.

Fitur yang hilang tergantung pada produk beton, secara umum sifat ACID penuh atau bahkan operasi gabungan tidak didukung. Itulah harga untuk peningkatan kinerja.


1
Menjelaskan NoSQL sebagai non-relasional tidak lebih tepat. Ada DB non-relasional lama lainnya yang tidak termasuk dalam kategori NoSQL. NoSQL berarti jauh lebih dari sekadar non-relasional. Baca ini untuk info lebih lanjut: martinfowler.com/bliki/NosqlDefinition.html
eddyP23

8

Anda benar, tidak masuk akal untuk menyatakannya dalam pernyataan selimut. Yang mungkin intinya; alih-alih jawaban tunggal, pewawancara mungkin mengharapkan Anda untuk menjawab dengan pertanyaan untuk membantu Anda mengetahui apa konteks masalahnya (data seperti apa, berapa banyak, di lingkungan operasi apa dll), solusi NoSQL tertentu . Mereka akan mencoba mencari tahu bagaimana Anda menganalisis masalah dan sepanjang jalan mendapatkan ide seberapa banyak Anda tahu tentang berbagai solusi yang ada di luar sana.


Ya, itu adalah pernyataan selimut, dan jika kita menerimanya benar, maka jawabannya adalah: tergantung.
Rolf

5

Database NoSQL biasanya hanya masuk akal jika Anda mendesain data Anda di sekitarnya.

Jika Anda hanya ingin menggunakannya sebagai pengganti RDBMS, maka Anda mungkin mendapatkan kinerja yang lebih sedikit daripada lebih banyak, terutama jika Anda tidak memiliki anggaran yang cukup untuk membayar server dengan jumlah RAM yang tinggi.

Lihatlah artikel ini yang membandingkan penggunaan ruang disk MySQL dengan MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage


3

Basis data NoSQL yang mana? Database SQL yang mana? Jika seseorang memberi tahu Anda bahwa NoSQL lebih cepat dari SQL, maka Anda harus pergi. Atau lebih baik lagi tonton video ini:

http://www.youtube.com/watch?v=b2F-DItXtZs

Saya tidak akan mengatakan setengah hal yang diklaim tentang NoSQL salah, tetapi saya akan mengatakan bahwa ada banyak fanboyisme NoSQL di luar sana dari orang-orang yang benar-benar tidak memahaminya dengan baik.

SQL memiliki batasnya (tentu saja) tetapi juga merupakan teknologi yang sangat matang, yang dipahami dengan baik, dan memiliki banyak pengembang yang memahami cara menggunakannya dengan baik. Saya tidak bisa mengatakan hal yang sama untuk semua bentuk NoSQL.


-2

NoSql didukung oleh database berorientasi kolom di mana RDBMS adalah database berorientasi baris ... Dan katakan misalnya kita memiliki tabel Karyawan dengan Nama, Usia, Salery, Alamat, EmployeeId dll ... kita meletakkan tabel yang sama di MySql (dukungan RDBMS) dan HBase (Dukungan NoSQL). Jika pelanggan / klien menulis kueri untuk mendapatkan rincian Usia atau Salery rata-rata dari catatan karyawan 1Lakh ... apa yang terjadi?

Dalam RDBMS akan mengelilingi setiap baris dan mengumpulkan nilai dan menjumlahkan & membagi untuk hasil. Ketika datang ke database Columnar tidak perlu khawatir tentang semua iterasi baris lakh. Tetapi berurusan dengan hanya satu Baris yang lebih cepat untuk dihitung. Jadi cara ini kadang-kadang NoSQL lebih cepat dari SQL. Kasus ini NoSQL tidak peduli dengan keluhan ACID yang layak!


2
Saya telah memperbaiki sedikit formatnya, meskipun saya tidak yakin apa yang Anda coba dapatkan di antara keduanya. Dan ACID juga tidak selalu didukung oleh RDBMS.

-3

Lupakan teori di sekitar basis data .... intinya setelah Anda memahami pertanyaan Anda, Anda dapat menyimpan data dalam basis data nosql dengan cara yang tepat di mana mereka sebenarnya digunakan dalam aplikasi Anda ....

Misalnya, ambil contoh ini, Anda memiliki model pelanggan dengan banyak pesanan dan banyak item yang terkait dengan setiap pesanan, maka mereka juga memiliki banyak item tersimpan untuk pembelian selanjutnya ... jika Anda adalah toko e-niaga besar dengan katakanlah 10 juta pelanggan dan 50 juta pesanan. Dan pelanggan itu masuk ke dasbor mereka yang menampilkan data yang tepat ini, berapa banyak pekerjaan yang harus dilakukan oleh database sql untuk menemukan pelanggan, bergabung dengan pesanan dan setiap item baris dan item yang disimpan. Dalam database sql, semua data ini mungkin perlu digabungkan dengan beberapa cara ... atau Anda dapat membuat koleksi dalam database Anda yang disebut usercache dan menyimpan data ini persis seperti yang Anda gunakan dalam kehidupan nyata. Jadi ini benar-benar bisa menjadi satu permintaan pada satu bidang [id] untuk mendapatkan semua data ini kembali. Selain itu, database nosql tidak

Jadi bisakah sql db meminta bidang ID tunggal secepat jika tidak lebih cepat dari nosql? Ya tapi bisakah database sql mengembalikan semua data yang Anda butuhkan dengan menanyakan satu tabel dan satu bidang? Tidak, kecuali jika Anda melakukan sesuatu seperti menyimpan data di Json di dalam bidang teks besar. Tetapi sekarang data tersebut tidak dapat digunakan untuk potensi penggunaan di masa depan.

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.