Apakah ada sesuatu yang inovatif tentang NoSQL? [Tutup]


46

Saya seorang pria Database Relasional yang sangat solid dan mengerti semua jalan ke bentuk normal ke-3, menghargai akar teori set aljabar SQL, dan mungkin bisa menghubungkan patah hati (atau tidak).

Saya belum menemukan struktur basis data relasional UNTUK kencan malam dengan istri saya, tetapi saya TELAH memikirkan proyek basis data relasional PADA kencan malam dengan istri saya ..

Sekarang saya mendengar tentang NoSQL, dan meneliti itu. Memotong mengejar, apakah ada sesuatu tentang NoSQL yang merupakan terobosan, novel matematika, atau "hei Anda bahkan tidak benar-benar perlu mengatur data Anda secara relasional, ini jauh lebih mudah" jenis pendekatan?

Apakah NoSQL seperti shell super untuk struktur data? Dalam pikiran saya, data pada akhirnya harus memiliki struktur untuk diambil dan pengambilan harus didefinisikan dalam semacam bahasa.


2
Jenis database NoSQL apa yang tidak memiliki struktur? Database dokumen dapat bersifat hierarkis, tetapi menyimpan data mereka secara minimal dalam dokumen yang berisi data dalam beberapa format. Database grafik dan penyimpanan nilai-kunci agak jelas. Basis data NoSQL apa yang tidak memiliki bahasa untuk ditanyakan? Beberapa basis data dokumen hanya pencarian teks atau XQuery untuk XML, sebagai dua contoh. SPARQL digunakan untuk toko RDF.
Thomas Owens

2
Pembaruan untuk "SAYA TELAH memikirkan proyek basis data relasional PADA kencan malam dengan istri saya .." :) LOL. Pertanyaan yang bagus juga.
Rocklan

2
Database NoSQL memang memiliki struktur, tetapi struktur tidak selalu mudah dipetakan ke aljabar relasional. NoSQL yang berbeda menggunakan struktur yang berbeda, beberapa di antaranya adalah kode kunci nilai-nilai, hierarki, basis data objek, basis data grafik, atau penyimpanan dokumen adalah jenis-jenis umum NoSQL. Semua yang sebenarnya NoSQL adalah realisasi bahwa SQL bukan obat mujarab, bahwa beberapa domain masalah memetakan dengan buruk ke SQL / aljabar relasional.
Lie Ryan

7
NoSQL adalah nama yang menyesatkan. Ini menyiratkan grup dengan karakteristik sementara satu-satunya karakteristik umum adalah bukan database SQL relasional klasik. Ini set terbuka. Ini seperti menggambarkan setiap makanan yang bukan roti sebagai "keluarga bukan-roti".
Pieter B

2
Oke, apa masalah besar tentang NoSQL? Sangat mudah: kami memiliki generasi orang yang tumbuh dengan database relasional dan itulah satu-satunya alat yang mereka miliki. Karena jika Anda hanya memiliki palu, semuanya menjadi paku. Kemudian Anda mendapatkan hal-hal buruk seperti mencoba meletakkan objek dalam database relasional atau membangun mesin pencari di atasnya. Kesadaran besar adalah bahwa: database SQL baik untuk banyak hal, tetapi tidak semuanya. "bukan segalanya" adalah hal besar.
Pieter B

Jawaban:


24

NoSQL lebih evolusioner daripada revolusioner. Ini pada dasarnya menggabungkan ide-ide yang ada "penyimpanan database eksternal" dengan "menggunakan struktur data yang akrab, bukan tabel relasional."

Ada lebih banyak jenis database daripada relasional, misalnya database hirarkis . Meskipun kuno menurut standar saat ini, ia sangat cocok dengan struktur data datanya (misalnya catatan COBOL ). Intinya adalah, data dalam database dimodelkan erat dengan bagaimana catatan diletakkan dalam bahasa pemrograman yang menggunakannya.

Maju cepat ke penemuan basis data relasional , di mana akhirnya basis data memisah perhatian dan, ketika dinormalisasi dengan baik, adalah cara yang bagus untuk memvisualisasikan sebagian besar tipe data dan hubungan antar data. Hal ini benar-benar mudah dimengerti dibandingkan dengan jenis lain dari database. Apa yang benar-benar gagal di, bagaimanapun, adalah menyimpan data dengan cara yang mencerminkan objek dan kelas dalam suatu program. Oleh karena itu, penemuan pemetaan objek-relasional . Dengan kata lain, desain database sebenarnya merupakan penghalang untuk desain program yang menggunakannya, itulah sebabnya kita membutuhkan perpustakaan ORM seperti Hibernate. Meski bersih dan konsisten, selalu ada keraguan di benak saya bahwa ada sesuatu yang tidak beres di sana.

Ini memunculkan dua jenis database, database objek dan NoSQL .

Keduanya berusaha untuk memecahkan masalah yang diperkenalkan oleh database relasional sambil tidak memaparkan kita pada kengerian yang mengejutkan dari database hirarkis. Data masih ditata dalam repositori yang secara samar-samar menyerupai tabel, tetapi pada kenyataannya lebih seperti pemrograman struktur data daripada tabel relasional. Sementara database objek mengikuti sebagian besar aturan yang didefinisikan dengan baik, pemahaman saya adalah bahwa NoSQL agak arbitrer. Sebagai contoh, sebuah tabel dapat divisualisasikan sebagai tabel hash atau array. Tidak ada cara yang mudah dan jelas untuk meminta mereka menggunakan alat arbitrer yang analog dengan Oracle SQL Developer atau SQL Server Management Studio .

Idenya adalah bahwa seseorang dapat mendefinisikan struktur data yang mudah dicari dalam kode, daripada menyatukan pertanyaan SQL yang lebih cocok untuk mesin database SQL daripada mengekspresikan permintaan yang diinginkan. Misalnya, pencocokan fuzzy atau parsial lebih sulit dan berkinerja lebih buruk dalam basis data relasional, sementara basis data NoSQL mungkin memiliki struktur yang dioptimalkan untuk pencarian tersebut dan selesai dalam waktu singkat.

Ada bahasa untuk menanyakan NoSQL. Namun, tidak ada bahasa universal seperti apa SQL untuk database relasional.


Edit Terlambat:

Sementara saya cukup akrab dengan database NoSQL, pertanyaan ini adalah dorongan bagi saya untuk membeli buku berkualitas tentang topik tersebut dan untuk mulai membacanya dengan tujuan akhirnya menjadi seorang ahli nyata pada topik tersebut. Komentar yang tersisa didasarkan pada NoSQL Distilled: Panduan Singkat untuk Dunia yang Muncul dari Kegigihan Polyglot oleh Pramod Sadalage dan Martin Fowler .

Para penulis menyatakan bahwa basis data relasional tidak skala baik untuk cluster yang mampu melayani data yang diperlukan untuk situs-situs seperti Amazon dan Google: NoSQL dikembangkan agar sesuai dengan ceruk ini, mengendurkan konkurensi dan daya tahan dalam ACID untuk server sejumlah besar permintaan yang sebagian besar menggunakan data statis (karenanya, transaksi ACID tidak sepenting).

Lebih lanjut, mereka berpendapat bahwa basis data NoSQL beroperasi tanpa skema (halaman 10) yang memungkinkan basis data NoSQL untuk memodifikasi struktur data dengan lebih mudah. Saya tidak yakin bahwa ada atau tidak adanya skema formal penting dalam hal ini, karena database SQL memungkinkan memodifikasi skema juga. Terlepas dari itu, dua penulis terkenal membuat klaim sehingga layak untuk diteliti.

Saya percaya bahwa kedua poin utama ini hanya berfungsi untuk menegakkan poin utama saya bahwa NoSQL adalah evolusioner, bukan revolusioner. Mereka masih menyimpan data, dan melakukan peningkatan bertahap pada skala dan kemampuan modifikasi. Mereka juga membuat poin bahwa NoSQL tidak berusaha untuk merebut basis data relasional sebagai raja penyimpanan data, hanya untuk menyediakan cara alternatif penyimpanan data untuk jenis data yang perlu untuk skala dan berubah dengan cara yang (mereka percaya) relasional database tidak mendukung dengan cukup baik.


2
Beberapa basis data NoSQL memiliki bahasa permintaan. Saya telah menggunakan XQuery dan SPARQL sebelumnya, jika data disimpan dalam XML atau RDF. Bahasa-bahasa itu cenderung terstruktur dan untuk kueri. Tetapi sekali lagi, itu hanya mencakup basis data NoSQL yang berisi format data yang terdefinisi dengan baik dan tidak berbuat banyak untuk pasangan teks atau nilai kunci.
Thomas Owens

@ThomasOwens saya mengedit jawaban saya untuk lebih spesifik.

1
Ini adalah gambaran umum NoSQL yang menarik tetapi tidak benar-benar menjawab pertanyaan yang sebenarnya. Sejauh yang saya tahu satu-satunya "terobosan" tentang NoSQL adalah bahwa data Anda tidak harus sesuai dengan struktur tertentu sebelum disimpan.
Rocklan

2
In other words, the design of the database is actually a hindrance to the design of the program that uses it, ...Saya merasa ini menempatkan banyak kereta di depan kuda dalam banyak kasus. Untuk bisnis besar dengan set data besar, data ini sangat berharga dan akan ada untuk waktu yang sangat, sangat lama - lebih lama dari bahasa pemrograman terkini, alat, dan paradigma. Mungkin lebih akurat untuk mengatakan bahwa OOP merupakan penghalang untuk desain database, dan mencoba mengubah desain database agar sesuai dengan paradigma pemrograman mungkin bukan ide terbaik.
Doval

2
Saya hanya akan menunjukkan bahwa kita semua menggunakan satu implementasi basis data heirarkis yang masih cukup berat - ini disebut sistem file.
Wyatt Barnett

13

Saya pikir Anda pasti ingin melihat tulisan ini oleh Erik Meijer & Gavin Bierman, berjudul "Bertentangan dengan kepercayaan populer, SQL dan NoSQL benar-benar hanya dua sisi dari koin yang sama" . Singkatnya, ia mengklaim bahwa kedua pendekatan matematis berbasis pada teori yang sama, tetapi dengan beberapa perbedaan.

Beberapa perbedaan yang menarik, menurut pendapat saya, adalah sebagai berikut: arah dependensi cross-type (FK dalam SQL) adalah kebalikan dari SQL dan NoSQL dan tipe koleksi tidak terbatas pada set di NoSQL (dan karenanya beberapa operasi set-teoretis) mungkin tidak berlaku di dunia NoSQL lagi, tetapi beberapa yang lain masih valid). Namun hal lain yang menarik dari artikel ini adalah bahasa permintaan tunggal yang diusulkan untuk menanyakan baik database SQL maupun NoSQL. Ini disebut LINQ, dan jika Anda berpikir Anda mungkin pernah mendengar nama ini sebelumnya, Anda benar: itulah bahasa query Microsoft dari C #.


1
"Namun hal lain yang menarik dari artikel ini adalah bahasa permintaan tunggal yang diusulkan untuk menanyakan baik database SQL maupun NoSQL. Ini disebut LINQ", tidak sepenuhnya benar, 'Linq' tidak dapat dipetakan ke SQL dalam mode 1: 1, jadi terjemahan harus terjadi untuk membuatnya bekerja pada SQL DBs. Yang berarti apa saja dapat diperkenalkan ke permintaan keduanya, selama ada lapisan terjemahan memastikan itu berjalan pada target DB
Frans Bouma

6
Yah, orang bisa berpendapat bahwa SQL juga tidak langsung dieksekusi pada database. Apa yang dieksekusi adalah rencana eksekusi, dan orang juga dapat berargumen bahwa Linq dapat diterjemahkan langsung ke rencana eksekusi. Jadi tidak ada perbedaan besar.
Haspemulator

10

Jawaban Snowman dengan tepat menjelaskan bagaimana SQL dan NoSQL berbeda dalam struktur data mereka dan bagaimana ini diakses. Namun, perbedaan yang mungkin lebih penting adalah domain masalah masing-masing.

NoSQL bukan penerus SQL. Sebaliknya, berbagai cabang NoSQL mengorbankan beberapa kualitas SQL agar menjadi lebih baik pada orang lain . Teorema CAP menyatakan bahwa tidak mungkin bagi sistem database terdistribusi untuk memenuhi semua properti berikut:

  • Konsistensi
  • Ketersediaan
  • Toleransi partisi

Jadi, beberapa varian NoSQL mengikuti prinsip BASE sebagai gantinya, yang melonggarkan kendala ACID yang selalu penuh , yang merupakan basis untuk database SQL klasik. Dengan kehilangan beberapa jaminan konsistensi, mereka memperoleh kemungkinan menggabungkan ketersediaan tinggi dan toleransi partisi dalam sistem yang didistribusikan secara luas, seperti untuk situs web dengan jumlah data dan permintaan pengguna yang tinggi, tetapi sedikit permintaan untuk konsistensi yang sempurna. Dengan demikian, basis data NoSQL tersebut berada di jantung Google , Facebook , dan Amazon . Jadi, untuk menjawab pertanyaan Anda: Ya, NoSQL merupakan terobosan besar karena memungkinkan layanan web begitu besar.

Ini hanya satu contoh, karena NoSQL adalah bidang yang beragam, dan variannya mencakup hampir semua kemungkinan kombinasi parameter dalam segitiga CAP .


Saya tidak terbiasa dengan ElasticSearch. Sebuah pencarian google cepat tampaknya menunjukkan bahwa sacrificies konsistensi (C), dan karena itu AP, tidak CAP, yang secara teoritis mungkin. Sunting: Ini sebagai tanggapan terhadap komentar yang sekarang hilang yang menunjukkan bahwa ElasticSearch memenuhi semua properti CAP.
Florian von Stosch

3
Oh betapa lucu, mereka pergi dengan DASAR untuk melawan ACID. Apakah ada pendekatan jalan tengah yang disebut REDOX atau SALT?
Patrick M

3

Kasus penggunaan umum NoSQL inovatif dalam keuntungan produktivitas mereka dibandingkan dengan database berbasis SQL yang umum. Ada beberapa faktor dalam hal ini.

Salah satunya adalah tata graha. Sebagian besar NoSQL adalah open source dan dapat diinstal pada workstation atau VM dengan beberapa perintah, dan bekerja dengan default yang wajar di luar kotak. Dalam pengalaman saya, bahkan Postgres dan MySQL tidak seperti itu; konfigurasi biasanya diperlukan untuk memulai bahkan pada workstation untuk tujuan pengembangan.

Yang lain adalah pengembangan yang mudah, seperti jawaban lain telah dijelaskan secara rinci. Kemampuan pengindeksan JSON dari Mongo, atau semantik kunci / nilai redis dan Riak, mungkin semua aplikasi web tertentu harus menyelesaikan pekerjaannya, dan APInya mudah. Beberapa NoSQL menyediakan API tenang sendiri, sedangkan dengan SQL Anda biasanya harus menulis sendiri.

Faktor-faktor ini membuat database NoSQL menarik untuk proyek skala kecil. Waktu penjemputan cenderung rendah. Tentu, ketika Anda pergi ke produksi, Anda harus mengkonfigurasi untuk keamanan dan skala, tetapi kemampuan untuk mulai coding dan berkolaborasi dengan cepat sangat kuat dan, saya berpendapat, terobosan.

Juga, terkait dengan hal di atas, untuk aplikasi skala kecil (seperti layanan internal-perusahaan atau aplikasi-ke-aplikasi), sebuah tim mungkin dapat berdiri di atas basis data NoSQL produksi tanpa melibatkan tim DBA mereka, dan tanpa menderita kinerja atau integritas masalah sebagai hasilnya. DBA profesional mungkin tidak menyukai ini, tetapi pengembang yang melihat DBA sebagai sumber penghalang (benar atau salah) kadang-kadang melihat NoSQL sebagai cara untuk memotong harus berurusan dengan mereka. Saya akui ini - saya pernah mengubah aplikasi skala kecil dari Postgres ke SQLite untuk memotong DBA permusuhan, dan saya telah memilih untuk mengimplementasikan pada Mongo daripada Oracle untuk menghindari proses persetujuan DBA dan pembatasan akses. Tanpa konsekuensi yang merugikan dalam kedua kasus tersebut.

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.