mengapa database noSQL lebih skalabel dari SQL?


100

Baru-baru ini saya banyak membaca tentang DBMS noSQL. Saya mengerti teorema CAP , aturan ACID , aturan BASE dan teori dasar. Tetapi tidak menemukan sumber daya tentang mengapa noSQL scalable lebih mudah daripada RDBMS (misalnya dalam kasus sistem yang membutuhkan banyak server DB)?

Saya kira menjaga batasan dan kunci sumber daya asing biaya dan ketika DBMS didistribusikan, itu jauh lebih rumit. Tapi saya berharap ada lebih dari ini.

Bisakah seseorang tolong jelaskan bagaimana noSQL / SQL mempengaruhi skalabilitas?


7
"Saya kira menjaga batasan dan kunci asing menghabiskan sumber daya dan ketika DBMS didistribusikan, itu jauh lebih rumit. Tapi saya berharap ada lebih banyak dari ini." - Sebenarnya itu saja. Lebih akurat, itulah satu karakteristik umum yang membuat sebagian besar solusi NoSQL lebih scalable daripada sepupu SQL mereka (untuk model data tertentu). Tetapi NoSQL adalah istilah yang sangat kabur, keluarga yang berbeda dari basis data NoSQL memiliki karakteristik berbeda yang membuatnya lebih terukur.
yannis

8
Tentu saja skala basis data SQL dengan sangat baik menjadi triliunan catatan, mereka hanya perlu keahlian untuk merancang dan mengaturnya yang tidak dimiliki pengembang aplikasi. Dan umumnya satu set perangkat keras dan lisensi yang cukup mahal.
HLGEM


6
Menurut pendapat saya, pertanyaan ini bukan duplikat dari keduanya. Pertanyaan mongodb adalah (selain judul yang buruk membuatnya tampak lebih spesifik) menanyakan hal lain yang sebenarnya lebih umum. Memilih untuk membuka kembali.
Joeri Sebrechts

Jawaban:


79

database noSQL memberikan sejumlah besar fungsi yang diberikan oleh database SQL pada dasarnya.

Hal-hal seperti penegakan otomatis integritas referensial, transaksi, dll. Ini semua adalah hal yang sangat berguna untuk beberapa masalah, dan yang memerlukan beberapa teknik menarik untuk mengukur di luar server tunggal (pikirkan apa yang terjadi jika Anda perlu mengunci dua tabel untuk transaksi atom, dan mereka berada di server yang berbeda!).

database noSQL tidak memiliki semua itu. Jika Anda membutuhkan barang-barang itu, Anda harus melakukannya sendiri, tetapi jika Anda TIDAK membutuhkannya (dan ada banyak aplikasi yang tidak), maka bagaimana mungkin Anda beruntung? DB tidak harus melakukan semua operasi rumit ini dan mengunci banyak dataset, sehingga sangat mudah untuk mempartisi hal tersebut di banyak server / disk / apa pun dan membuatnya bekerja sangat cepat.


2
Tidak tahu itu sesederhana itu
Abdul

7
jawaban yang diterima ini sama sekali gagal menyebutkan kemampuan sharding NoSQL yang hilang dari SQL. Sharding adalah apa yang membuat NoSQL terukur secara horizontal.
hyankov

8
@HristoYankov Dan ini berfungsi karena sistem NoSQL tidak melakukan semua hal yang tidak bisa dimainkan dengan baik dengan sharding.
user253751

1
@HristoYankov: Database SQL dapat sharded horizontal, dan tidak semua database NoSQL dapat secara horizontal sharded dengan mudah. Sharding sebenarnya bukan alasan mengapa Anda ingin menggunakan NoSQL.
Lie Ryan

@HristoYankov Jawaban yang diterima berjalan satu tingkat lebih dalam dari catatan Anda "benar-benar gagal untuk menyebutkan kemampuan sharding NoSQL yang hilang dari SQL". Jawaban yang diterima, memang, berbicara tentang MENGAPA sharding horisontal lebih sulit dengan database SQL. Bahkan, saya menghabiskan 20 menit mencari jawaban untuk ini dan hampir semua orang hanya meluncurkan "ohh NoSQL beling lebih baik", tanpa menyebutkan alasan apa pun. Respon yang sama sekali tidak berguna. Respons yang diterima di sini menjawab pertanyaan dengan sempurna - meskipun sangat singkat. Akan menyenangkan untuk memiliki lebih banyak alasan terdaftar juga.
Phoeniyx

176

Ini bukan tentang NoSQL vs SQL, ini tentang BASE vs ACID.

Scalable harus dipecah menjadi konstituennya:

  • Pembacaan skala = menangani volume operasi baca yang lebih tinggi
  • Penskalaan penulisan = menangani volume operasi penulisan yang lebih tinggi

Basis data ACID-compliant (seperti RDBMS tradisional) dapat membaca skala. Mereka tidak secara inheren kurang efisien daripada database NoSQL karena (kemungkinan) bottleneck kinerja diperkenalkan oleh hal-hal yang tidak dimiliki NoSQL (kadang-kadang) kurang (seperti bergabung dan di mana batasan) yang Anda dapat memilih untuk tidak menggunakan. Clustered SQL RDBMS's dapat membaca skala dengan memperkenalkan node tambahan di cluster. Ada kendala sejauh mana operasi baca dapat ditingkatkan, tetapi ini dipaksakan oleh kesulitan meningkatkan penulisan saat Anda memperkenalkan lebih banyak node ke dalam cluster.

Menulis kerak adalah tempat segala hal menjadi berbulu. Ada berbagai kendala yang diberlakukan oleh prinsip ACID yang tidak Anda lihat dalam arsitektur yang akhirnya konsisten (BASE):

  • Atomicity berarti bahwa transaksi harus lengkap atau gagal secara keseluruhan, sehingga banyak pembukuan harus dilakukan di belakang layar untuk menjamin hal ini.
  • Batasan konsistensi berarti bahwa semua node dalam cluster harus identik. Jika Anda menulis ke satu simpul, penulisan ini harus disalin ke semua simpul lain sebelum mengembalikan respons ke klien. Ini membuat gugus RDBMS tradisional sulit untuk diukur.
  • Batasan daya tahan berarti bahwa agar tidak pernah kehilangan penulisan, Anda harus memastikan bahwa sebelum respons dikembalikan ke klien, penulisan telah dibilas ke disk.

Untuk meningkatkan operasi penulisan atau jumlah node dalam sebuah cluster di luar titik tertentu Anda harus dapat melonggarkan beberapa persyaratan ACID:

  • Menjatuhkan Atomicity memungkinkan Anda mempersingkat durasi tabel (set data) yang dikunci. Contoh: MongoDB, CouchDB.
  • Menjatuhkan Konsistensi memungkinkan Anda meningkatkan penulisan di seluruh node cluster. Contoh: riak, cassandra.
  • Dropping Durability memungkinkan Anda merespons perintah penulisan tanpa perlu membilas ke disk. Contoh: memcache, redis.

Database NoSQL biasanya mengikuti model BASE dan bukan model ACID. Mereka melepaskan persyaratan A, C dan / atau D, dan sebagai imbalannya mereka meningkatkan skalabilitas. Beberapa, seperti Cassandra, membiarkan Anda ikut serta dalam jaminan ACID saat Anda membutuhkannya. Namun, tidak semua database NoSQL lebih terukur sepanjang waktu.

SQL API tidak memiliki mekanisme untuk menjelaskan kueri di mana persyaratan ACID dilonggarkan. Inilah sebabnya mengapa basis data BASE semuanya NoSQL.

Catatan pribadi: satu poin terakhir yang ingin saya sampaikan adalah bahwa sebagian besar kasus di mana NoSQL saat ini sedang digunakan untuk meningkatkan kinerja, solusi akan dimungkinkan pada RDBMS yang tepat dengan menggunakan skema yang dinormalisasi dengan benar dengan indeks yang tepat. Sebagaimana dibuktikan oleh situs ini (diberdayakan oleh MS SQL Server) RDBMS dapat mengubah ke beban kerja yang tinggi, jika Anda menggunakannya dengan tepat. Orang yang tidak mengerti cara mengoptimalkan RDBMS harus menjauh dari NoSQL, karena mereka tidak mengerti risiko apa yang mereka ambil dengan data mereka.

Pembaruan (2019-09-17):

Lansekap basis data telah berkembang sejak memposting jawaban ini. Meskipun masih ada dikotomi antara dunia RDBMS ACID dan dunia BASE NoSQL, garis telah menjadi lebih fuzzier. Database NoSQL telah menambahkan fitur dari dunia RDBMS seperti SQL API dan dukungan transaksi. Sekarang bahkan ada database yang menjanjikan SQL, ACID dan penulisan skala, seperti Google Cloud Spanner, YugabyteDB atau CockroachDB. Biasanya iblis ada dalam perinciannya, tetapi untuk sebagian besar tujuan ini "cukup ASAM". Untuk menyelam lebih dalam ke teknologi basis data dan bagaimana perkembangannya, Anda bisa melihat slide ini (catatan slide memiliki penjelasan yang menyertainya).


Meskipun saya setuju bahwa beberapa toko NoSQL menggantikan ACID dengan BASE, itu masih bukan fitur yang umum untuk semua toko yang termasuk dalam "kategori" NoSQL, yang merupakan definisi buruk di tempat pertama. Setelah beberapa saat, penafsiran istilah tersebut beralih dari "No SQL" ke "Not Only SQL", tetapi karena banyak database seperti itu masih BERGABUNG atau sudah mulai menerapkan dialek SQLesque, Mark Madsen telah menciptakan kembali istilah tersebut untuk mengartikan sesuatu yang lain dalam nya sejarah database tidak-tasi : "Tidak, SQL" ;-)
Lukas Eder

2
Untuk menghindari bergabung, kami akan memiliki data yang dinormalisasi di NoSQL yang mengarah ke pengulangan dan lebih banyak penyimpanan. Tetapi hal yang sama dapat dicapai dalam RDBMS jika kita OK dengan de-normalisasi. Jadi "Bergabung" atau "tidak Bergabung" tergantung pada DBA, dan bukan pada tipe basis data. Benar ?
Kaushik Lele

2
@dinamik Situs-situs itu baik menggunakan caching berat, atau mereka beling. Desain tersebut menempatkan kompleksitas penskalaan data di luar db. Anda mungkin juga menggunakan nosql dalam kasus seperti itu, karena itulah persisnya trade-off nosql.
Joeri Sebrechts

1
"SQL API tidak memiliki mekanisme untuk menggambarkan permintaan di mana persyaratan ACID dilonggarkan". Secara teknis benar, tetapi SQL server telah mengambil langkah pemalu ke arah itu. SQL 2014 memperkenalkan Delayed Durability, membuat D dalam ACID, sebagai ganti untuk mengurangi tekanan log.
EBarr

3
Ini harus menjadi jawaban yang diterima imo. Sangat jelas dengan contoh-contoh tetapi berhasil tetap ringkas.
Olshansk

4

Memang benar bahwa basis data NoSQL (MongoDB, Redis, Riak, Memcached, dll.) Tidak mempertahankan batasan kunci asing, dan operasi atom harus lebih eksplisit ditentukan. Juga benar bahwa basis data SQL (SQL Server, Oracle, PostgreSQL, dll.) Dapat ditingkatkan untuk menangani persyaratan kinerja yang sangat besar dengan DBA berpengalaman.

Database NoSQL memungkinkan pemrogram berpengalaman, yang sangat mengetahui kondisi ras dan operasi atom, untuk melepaskan sejumlah besar pemrosesan hanya diperlukan dalam persentase kecil dari kode aplikasi web saat ini. Database NoSQL tentu memiliki operasi atom dan sebagian besar semua persyaratan transaksional hadir dalam database SQL juga dapat diperoleh database NoSQL. Perbedaannya adalah tingkat abstraksi. Basis data NoSQL menghapus tingkat abstraksi yang lebih tinggi dan memberikan kemampuan kepada pemrogram aplikasi, sehingga menghasilkan kode yang lebih cepat secara keseluruhan dengan meningkatnya kemungkinan korupsi data oleh pemrogram yang tidak menggunakan musim.

Akibatnya, kita jauh lebih mungkin melihat basis data NoSQL yang semakin banyak digunakan di ruang aplikasi web, di mana waktu dan kinerja pengembangan sangat penting. Perangkat lunak finansial dan korporat cenderung mempertahankan warisan SQL-nya karena kinerja perangkat keras relatif murah, mereka telah berpengalaman menangani DBA, dan peningkatan risiko yang disebabkan oleh pemrogram yang tidak musiman tidak cocok.


2
Saya tidak yakin saya setuju dengan bagian tentang transaksi atom, dalam arti ACID (meskipun sulit untuk mengomentari "NoSQL", karena itu untuk diperdebatkan apa sebenarnya yang kami maksud). Sebagian besar keuntungan kinerja dalam DB "NoSQL" khas "dicapai melalui melonggarnya jaminan konsistensi (lihat: konsistensi akhirnya , ACID vs BASE). Jika konsistensi akhirnya cukup baik untuk suatu aplikasi (dan seringkali demikian), maka ini memungkinkan penskalaan horizontal yang jauh lebih efisien.
Daniel B

4

Dari IBM developerWorks: Menyediakan skalabilitas data tingkat cloud dengan basis data NoSQL

Skalabilitas adalah sistem yang harus dapat mendukung database yang sangat besar dengan tingkat permintaan yang sangat tinggi pada latensi yang sangat rendah.

Sistem NoSQL memiliki sejumlah fitur desain yang sama:

  • Kemampuan untuk secara horizontal memperkecil throughput pada banyak server.
  • Antarmuka atau protokol tingkat panggilan sederhana (berbeda dengan pengikatan SQL).
  • Dukungan untuk model konsistensi yang lebih lemah daripada transaksi ACID di sebagian besar RDBMS tradisional.
  • Penggunaan indeks dan RAM yang didistribusikan secara efisien untuk penyimpanan data.
  • Kemampuan untuk secara dinamis mendefinisikan atribut atau skema data baru.

Mengapa basis data relasional mungkin tidak optimal untuk Penskalaan

Secara umum, sistem manajemen basis data relasional telah dianggap sebagai "solusi satu ukuran untuk semua untuk persistensi dan pengambilan data" selama beberapa dekade. Mereka telah matang setelah upaya penelitian dan pengembangan yang luas dan sangat berhasil menciptakan pasar dan solusi besar dalam domain bisnis yang berbeda.

Kebutuhan yang semakin meningkat untuk skalabilitas dan persyaratan aplikasi baru telah menciptakan tantangan baru untuk RDBMS tradisional, termasuk beberapa ketidakpuasan dengan pendekatan satu ukuran untuk semua dalam beberapa aplikasi skala web. Jawaban untuk ini adalah generasi baru dari perangkat lunak database berkinerja tinggi dan berkinerja tinggi yang dirancang untuk menantang dominasi sistem manajemen basis data relasional. Alasan utama untuk pergerakan NoSQL adalah bahwa implementasi yang berbeda dari aplikasi web, perusahaan, dan cloud computing memiliki persyaratan yang berbeda dari basis datanya - tidak setiap aplikasi memerlukan konsistensi data yang kaku, misalnya.

Contoh lain: Untuk situs web bervolume tinggi seperti eBay, Amazon, Twitter, atau Facebook, skalabilitas dan ketersediaan tinggi adalah persyaratan penting yang tidak dapat dikompromikan. Untuk aplikasi ini, bahkan pemadaman sekecil apa pun dapat memiliki konsekuensi keuangan yang signifikan dan berdampak pada kepercayaan pelanggan.

Lebih dari pada DBA.SE: Apa arti penskalaan horizontal?

Penskalaan Horizontal pada dasarnya adalah membangun bukan ke atas. Anda tidak pergi dan membeli server yang lebih besar dan memindahkan semua beban Anda ke server itu, sebaliknya Anda membeli 1+ server tambahan dan mendistribusikan beban Anda ke mereka.

Penskalaan horizontal digunakan ketika Anda memiliki kemampuan untuk menjalankan beberapa instance pada server secara bersamaan. Biasanya jauh lebih sulit untuk beralih dari 1 server ke 2 server maka dari 2 menjadi 5, 10, 50, dll.

Setelah Anda mengatasi masalah menjalankan mesin virtual paralel, Anda dapat mengambil keuntungan besar dari lingkungan seperti Amazon EC2, Layanan Cloud Rackspace, GoGrid, dll karena Anda dapat membuat mesin virtual naik dan turun berdasarkan permintaan, mengurangi kebutuhan untuk membayar daya server Anda tidak menggunakan hanya untuk menutupi beban puncak itu.

Database relasional adalah salah satu item yang lebih sulit untuk menjalankan baca / tulis penuh secara paralel.

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.