Apakah penggunaan Basis Data NoSQL tidak praktis untuk kumpulan data besar di mana Anda perlu mencari berdasarkan konten?


51

Saya sudah belajar tentang Database NoSQL selama seminggu sekarang.

Saya benar-benar memahami kelebihan dari Database NoSQL dan banyaknya kasus penggunaan yang bagus untuknya.

Tetapi sering orang menulis artikel mereka seolah-olah NoSQL dapat menggantikan Database Relasional. Dan ada satu hal yang tidak bisa saya pahami:

Database NoSQL adalah (sering) toko nilai kunci.

Tentu saja mungkin untuk menyimpan semuanya menjadi penyimpanan nilai kunci (dengan menyandikan data dalam JSON, XML, apa pun), tetapi masalah yang saya lihat adalah Anda perlu mendapatkan sejumlah data yang cocok dengan kriteria tertentu, dalam banyak gunakan kasing. Dalam database NoSQL Anda hanya memiliki satu kriteria yang dapat Anda cari secara efektif - kuncinya. Database Relasional dioptimalkan untuk mencari nilai apa pun di baris data secara efektif.

Jadi Basis Data NoSQL sebenarnya bukan pilihan untuk menyimpan data yang perlu dicari oleh konten mereka. Atau apakah saya salah mengerti sesuatu?

Sebuah contoh:

Anda perlu menyimpan data pengguna untuk toko web.

Dalam basis data relasional, Anda menyimpan setiap pengguna sebagai baris dalam userstabel, dengan ID, nama, negaranya, dll.

Dalam Database NoSQL Anda akan menyimpan setiap pengguna dengan ID-nya sebagai kunci dan semua datanya (dikodekan dalam JSON, dll.) Sebagai nilai.

Jadi, jika Anda perlu mendapatkan semua pengguna dari negara tertentu (untuk beberapa alasan orang pemasaran perlu tahu sesuatu tentang mereka), mudah untuk melakukannya di Database Relasional, tetapi tidak terlalu efektif dalam Database NoSQL, karena Anda harus dapatkan setiap pengguna, uraikan semua data dan filter.

Saya tidak mengatakan itu tidak mungkin , tetapi itu menjadi jauh lebih rumit dan saya kira tidak efektif jika Anda ingin mencari dalam data entri NoSQL.

Anda bisa membuat kunci untuk setiap negara yang menyimpan kunci dari setiap pengguna yang tinggal di negara ini, dan mendapatkan pengguna dari negara tertentu dengan mendapatkan semua kunci yang disimpan di kunci untuk negara ini. Tapi saya pikir teknik ini membuat dataset yang kompleks bahkan lebih kompleks - lebih sulit untuk diterapkan dan tidak seefektif kueri Database SQL. Jadi saya pikir itu bukan cara yang akan Anda gunakan dalam produksi. Atau itu?

Saya tidak begitu yakin apakah saya salah memahami sesuatu atau mengabaikan beberapa konsep atau praktik terbaik untuk menangani kasus penggunaan semacam itu. Mungkin Anda bisa memperbaiki pernyataan saya dan menjawab pertanyaan saya.


16
Ini lebih mirip kata-kata kasar daripada pertanyaan. Anda tampaknya memiliki pemahaman yang baik tentang kelebihan dan kekurangan penyimpanan nilai kunci versus relasional. Jadi apa sebenarnya pertanyaannya?
JacquesB

16
Ini bukan kata-kata kasar sama sekali :) Basis data NoSQL mengagumkan, tapi saya pikir Basis Data Relasional tidak seburuk beberapa negara. Saya hanya ingin mengetahui, jika tesis saya, bahwa Database NoSQL bukan pilihan terbaik jika harus mencari di 'datarows' ... atau jika saya tidak memahami topik dengan benar.
Leo Lindhorst


5
Tapi MongoDB adalah Webscale ! [peringatan: termasuk beberapa bahasa NSFW]
Jerry Coffin

5
@DevWurm: Anda tidak perlu mengonfigurasi toko nilai kunci dengan NoSQL secara umum. Misalnya, googles BigTable dianggap sebagai basis data NoSQL, tetapi Anda masih dapat mencari dan membuat indeks pada banyak bidang. Toko nilai kunci sesuai ketika Anda tahu Anda hanya perlu mencari di satu bidang (kunci).
JacquesB

Jawaban:


40

Sementara saya setuju dengan premis Anda bahwa NoSQL bukan obat mujarab untuk semua kesengsaraan basis data, saya pikir Anda salah paham satu poin kunci.

Dalam database NoSQL Anda hanya memiliki satu kriteria yang dapat Anda cari secara efektif - kuncinya.

Ini jelas tidak benar.

Misalnya MongoDB mendukung indeks. (dari https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Indeks mendukung eksekusi query yang efisien di MongoDB. Tanpa indeks, MongoDB harus melakukan pemindaian koleksi, yaitu memindai setiap dokumen dalam koleksi, untuk memilih dokumen yang cocok dengan pernyataan kueri. Jika ada indeks yang sesuai untuk kueri, MongoDB dapat menggunakan indeks untuk membatasi jumlah dokumen yang harus diperiksa.

Indeks adalah struktur data khusus [1] yang menyimpan sebagian kecil dari kumpulan data yang diatur dalam bentuk yang mudah dilintasi. Indeks menyimpan nilai bidang tertentu atau kumpulan bidang, diurutkan berdasarkan nilai bidang tersebut. Pemesanan entri indeks mendukung kecocokan kesetaraan yang efisien dan operasi kueri berbasis rentang. Selain itu, MongoDB dapat mengembalikan hasil yang diurutkan dengan menggunakan pemesanan dalam indeks.

Seperti halnya couchbase (dari http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Tampilan Couchbase memungkinkan pengindeksan dan pencarian data.

Tampilan membuat indeks pada data sesuai dengan format dan struktur yang ditentukan. Tampilan terdiri dari bidang spesifik dan informasi yang diekstrak dari objek di Couchbase.

Kenyataannya apa pun yang menyebut dirinya sebagai basis data NoSQL daripada penyimpanan nilai kunci harus benar-benar mendukung semacam skema pengindeksan.

Bahkan, seringkali fleksibilitas skema indeks inilah yang membuat NoSQL bersinar. Menurut pendapat saya, bahasa yang digunakan untuk mendefinisikan indeks NoSQL sering lebih ekspresif atau alami daripada SQL, dan karena mereka biasanya hidup di luar tabel, Anda tidak perlu mengubah skema tabel Anda untuk mendukungnya. (Bukan untuk mengatakan Anda tidak dapat melakukan hal-hal serupa di SQL tetapi bagi saya rasanya ada lebih banyak kehebohan yang terlibat).


13
"... karena mereka biasanya tinggal di luar meja, kamu tidak perlu mengubah skema meja kamu untuk mendukung mereka." Itu situasi yang sama antara indeks non-clustered dalam database SQL dan indeks untuk database noSQL, kan?
Jirka Hanika

Jawaban yang cukup solid. Saya akan menambahkan bahwa NoSQL agak didasarkan pada gagasan bahwa jika Anda ingin lebih cepat, Anda harus membuat 90% ++ permintaan dengan kunci utama tanpa bergabung, dan jika Anda ingin melakukan hal lain, Anda berada di dunia pemindaian tabel dan indeks sekunder, yang selalu memiliki batas kinerja dan skala. Setelah Anda mencari indeks, atau Anda telah membuat banyak, Anda tidak berada di area di mana kecepatan dapat dicapai (kecuali untuk kumpulan data kecil dari beberapa juta baris). Jika Anda kode dalam gaya di mana pencarian alternatif jarang terjadi, Anda akan berakhir dengan sistem operasional yang sangat solid.
Brian Bulkowski

40

Secara umum, jika alur kerja Anda sangat cocok untuk permintaan basis data relasional, Anda akan menemukan database relasional menjadi pendekatan yang paling efisien. Jenisnya tautologis, tapi itu benar.

Klaim bahwa banyak pendukung NoSQL akan membuat adalah bahwa banyak alur kerja yang sebenarnya dipijat ke dalam bentuk relasional, dan akan lebih efektif sebelum memijat seperti itu. Validitas klaim ini rumit untuk dipastikan. Jelas ada pekerjaan yang dijelaskan dengan sangat baik oleh query SQL. Saya dapat mengatakan dari pengalaman saya bahwa tugas pemrograman relasional khusus saya dapat dilakukan menggunakan NoSQL dengan tingkat efisiensi yang hampir sama, jika tidak lebih. Namun, itu pernyataan yang sangat subyektif berdasarkan pengalaman yang sempit.

Saya merasa banyak penjualan pendekatan NoSQL berasal dari asumsi database besar. Semakin besar basis data, semakin banyak Anda harus mengatur alur kerja Anda untuk mendukung kumpulan data yang lebih besar. NoSQL tampaknya lebih baik dalam mendukung upaya perawatan itu. Dengan demikian, semakin besar basis data, fitur-fitur NoSQL yang lebih penting dapat berpotensi.

Untuk menggunakan contoh ini, dalam kueri SQL menurut negara sama lambatnya dengan pemindaian NoSQL dari semua pengguna, kecuali jika Anda secara eksplisit meminta SQL untuk mengindeks userstabel berdasarkan negara. NoSQL dapat melakukan hal yang sama, di mana Anda membuat koleksi kunci-nilai yang diurutkan yaitu indeks (seperti SQL di bawah tenda) dan memeliharanya.

Perbedaan? Mesin SQL memiliki konsep pengindeksan tabel bawaan. Ini berarti Anda harus melakukan lebih sedikit pekerjaan (yang harus Anda lakukan adalah menambahkan indeks ke tabel). Namun, itu juga berarti Anda kurang memiliki kendali. Untuk sebagian besar kasus, kehilangan kontrol itu dapat diterima, dengan imbalan mesin SQL melakukan pekerjaan untuk Anda. Namun, dalam kumpulan data besar, Anda mungkin menginginkan model konsistensi yang berbeda dari model SQL ACID yang khas. Anda mungkin ingin menggunakan model BASE yang mendukung konsistensi akhirnya. Itu bisa sangat sulit dalam SQL, karena mesin SQL melakukan pekerjaan untuk Anda sehingga harus dilakukan oleh aturan mesin SQL. Di NoSQL, lapisan-lapisan itu biasanya terbuka, membiarkan Anda meretasnya.


2
Dalam contoh Anda, Anda menyatakan " Permintaan SQL menurut negara sama lambatnya dengan pemindaian NoSQL dari semua pengguna ". Apakah Anda memiliki bukti untuk mendukung ini? NoSQL yang dijelaskan dalam pertanyaan adalah pasangan kunci-nilai, jadi Anda harus memindai nilai untuk mendapatkan lokasi negara, lalu melakukan perbandingan. SQL sudah tahu di mana data itu, sehingga dapat memilihnya langsung dari disk (melewatkan apa yang tidak diperlukan), lalu memeriksa nilainya. Jika negara adalah kunci asing, ini adalah perbandingan bilangan bulat cepat. Tidak ini akan selalu lebih cepat karena Anda menarik lebih sedikit dari disk dan cek lebih cepat.
Dipotong

1
@Trisped Sulit untuk memberikan bukti, karena NoSQL adalah pendekatan, bukan produk (sama untuk SQL). Namun, perlu dicatat bahwa BigTable, implementasi NoSQL, memiliki konsep kolom, seperti halnya tabel SQL. Ini adalah konsep kolom yang memungkinkan Anda melewatkan data dengan mengetahui ke mana harus mencari, yang dapat diterapkan pada implementaiton.
Cort Ammon

16

NoSQL adalah istilah yang agak kabur, karena pada dasarnya mencakup semua sistem basis data yang tidak bersifat relasional.

Apa yang Anda gambarkan adalah penyimpanan nilai-kunci , yang merupakan jenis basis data di mana gumpalan data disimpan di bawah kunci, dan dapat dengan cepat dicari jika Anda mengetahui kuncinya. Database ini sangat cepat jika Anda tahu kunci yang tepat, tetapi seperti yang Anda katakan sendiri, jika Anda perlu mencari atau memfilter beberapa properti pada data, itu akan lambat dan rumit.

Tidak ada orang waras yang akan mengklaim bahwa kunci-nilai toko dapat menggantikan basis data relasional secara umum. Namun mungkin ada kasus penggunaan tertentu di mana penyimpanan kunci-nilai cocok. Toko nilai kunci sering digunakan untuk caching, karena Anda biasanya men-cache item oleh id, tetapi Anda tidak perlu melakukan kueri ad-hoc atas cache. Misalnya situs Stackoverflow sendiri menggunakan Redis (a-key-value db) secara luas , tetapi hanya untuk caching keluaran. Data kanonik yang mendasarinya masih bertahan dalam database relasional.

Jadi jawabannya cukup jelas: Gunakan toko kunci-nilai jika Anda hanya perlu menyimpan dan mencari menggunakan satu kunci. Kalau tidak, gunakan jenis database yang berbeda. Dan jika Anda ragu, gunakan database relasional, karena ini adalah jenis database yang paling fleksibel, sedangkan database NoSQL sering dioptimalkan ke arah kasus penggunaan yang sangat khusus.


2
"NoSQL adalah istilah yang agak kabur, karena pada dasarnya mencakup semua sistem basis data yang tidak bersifat relasional." - Itu tidak benar. Ini mencakup semua sistem basis data yang bukan merupakan basis data SQL. Ada database relasional yang tidak menggunakan SQL, seperti Rel dan Tutorial D (database yang dirancang untuk mengikuti model relasional lebih dekat tanpa "pelunakan" yang dilakukan SQL). Ada database hiperasional. Sungguh, NoSQL berarti "Tidak Hanya SQL", yang berarti "jangan secara otomatis mengasumsikan SQL, pilih model database yang benar yang cocok dengan struktur tanggal Anda ... yang mungkin sangat SQL."
Jörg W Mittag

@ JörgWMittag Menurut definisi Anda, jika saya memilih MySQL karena DB terbaik untuk mencocokkan data saya, itu solusi NoSQL yang valid.

1
@ JörgWMittag: Anda bukan definisi resmi dari istilah NoSQL, tetapi biasanya merujuk ke sistem basis data non-relasional. "Not Only Sql" -backronym adalah retcon yang lebih baru untuk menangkal serangan-hype yang tidak dapat dihindari. Tetapi dalam penggunaan umum, NoSQL digunakan untuk menggambarkan sistem seperti MongoDb, Bigtable dll., Tidak mengatakan tutorial D (yang bahkan bukan database).
JacquesB

2
@ JörgWMittag NoSQL awalnya berarti "non SQL" atau "non relational". "Not Only SQL" akan menjadi NOSQL karena merupakan akronim dan bukan kombinasi dari kata "Tidak" dan akronim "SQL". Itu menjadi populer sebagai lawan dari praktik umum menempatkan segala sesuatu dalam basis data (sebagaimana dinyatakan dalam artikel Wikipedia). Saat Anda berkomentar, bidang ini sedikit lebih kompleks sekarang.
Dipotong

Sangat setuju. Tampaknya pola utama NoSQL adalah penyimpanan dokumen key-value (mis. Redis) (mis. Mongo) dan grafik (mis. Neo4J). Saya berharap orang-orang akan membuang NoSQL dan menggunakan salah satu istilah itu.
paj28 28

10

Pernyataan Anda tentang database relasional semuanya benar, sampai pada titik di mana Anda memiliki begitu banyak data, Anda tidak dapat lagi menyalinnya di satu server. Kemudian Anda mulai mengalami berbagai masalah menarik. Bagaimana Anda membagi tabel Anda sehingga sebagian besar pertanyaan Anda dapat berjalan pada satu server? Berapa banyak salinan data yang Anda buat? Bagaimana Anda menangani ketidakkonsistenan di antara salinan itu? Bagaimana Anda menyimpan data pengguna di pusat data yang relatif dekat dengannya secara geografis?

Tujuan-tujuan ini sering bertentangan satu sama lain. Banyak pengguna twitter mengikuti orang-orang dari seluruh dunia. Haruskah database twitter dioptimalkan secara geografis untuk membaca tweet atau menulis tweet?

Ternyata ketika Anda berurusan dengan skala semacam itu, Anda mulai menciptakan solusi, menambahkan redundansi, dan memaksakan pembatasan yang sangat mirip dengan database NoSQL. Jika Anda dapat memasukkan semua data Anda dalam satu kotak, Anda hanya mendapatkan batasan dan tidak perlu untuk manfaatnya.


Membaca 10TB ke dalam RAM membutuhkan waktu beberapa saat @Daniel ... Beberapa jam akan menjadi hasil yang cukup bagus. Itu akan membuat pemulihan dari bencana relatif menjadi bencana.
Ben

1
Saya akan mengatakan Big Data tentu saja merupakan salah satu area di mana database NoSQL ikut berperan, tetapi itu hanya satu. Ada juga banyak alasan lain mengapa basis data NoSQL mungkin lebih cocok untuk suatu masalah. Jika Anda memiliki grafik data, masuk akal untuk menggunakan basis data grafik, jika Anda memiliki data XML, masuk akal untuk menggunakan basis data XML. Tidak hanya Big Data, tetapi juga model data adalah kriteria penting ketika memilih database yang sesuai (dan tentu saja berkali-kali database SQL adalah pilihan yang tepat, tergantung pada masalahnya)
dirkk

5
Ini salah. Sharding sebagai pendekatan pemrograman telah menjadi standar dalam database skala besar selama bertahun-tahun dan beberapa database mendukung cluster dengan berbagi data secara transparan (Oracle RAC). Bagaimana menurut Anda semua bank bekerja? Dan dengan pengaturan yang tepat, Anda Jarang mengembalikan cadangan - yang dibiarkan sebagai skenario "2 pusat data terbakar" yang sebenarnya. Dan ya, pernah bekerja pada database 30tb sekali - kami tidak punya masalah.
TomTom

Ya, database relasional melakukan sharding dan clustering data yang transparan, tetapi ini adalah abstraksi yang sangat bocor jika Anda ingin mengoptimalkan kinerja.
Karl Bielefeldt

5

Basis data NoSQL sangat sedikit hubungannya dengan " No SQL".

Mereka mengakui bahwa Anda tidak dapat memiliki database pada skala yang selalu konsisten dan mendukung transaksi yang kompleks dan memiliki daya tahan.

Dalam database relasional normal, semua indeks secara otomatis disimpan diperbarui dalam ruang lingkup transaksi, sehingga dapat digunakan untuk permintaan apa pun.

Dalam database NoSQL programmer bertanggung jawab untuk memelihara banyak indeks dan diasumsikan bahwa indeks akan selalu ketinggalan zaman.

Sebagai contoh:

  • Indeks orang berdasarkan nomor pajak mungkin berisi beberapa orang yang tidak pernah menyelesaikan proses pendaftaran pajak.
  • Karena itu kode yang menggunakan indeks harus mampu mengatasi pendaftaran pajak yang tidak lengkap
  • Pilihan lain adalah memiliki waktu ketika seseorang yang terdaftar untuk pajak tidak ada dalam indeks. (Jadi desain Anda harus mengatasi tidak memiliki data yang konsisten dan memutuskan bagaimana data tidak akan konsisten.)

Sebagai contoh nyata, Amazon lebih suka menunjukkan kepada saya deskripsi buku yang sudah ketinggalan zaman daripada menunda tampilan halaman web dengan menunggu 106 komputer untuk mengonfirmasi bahwa kunci yang benar telah dikeluarkan.

Karena itu.....

Jika satu database relasional normal dapat menyimpan semua data Anda dan memproses setiap transaksi dengan cukup cepat sehingga penguncian tidak menghentikan sistem Anda dari melakukan pekerjaan yang bermanfaat, database relasional adalah pilihan terbaik.

Tetapi segera setelah Anda harus mulai berpikir tentang menggunakan lebih dari satu basis data relasional, atau memecah transaksi untuk menghindari kesalahan penguncian, Anda harus berhadapan dengan jenis masalah yang Anda dapatkan saat menggunakan database "NoSQL".

Karena database "NoSQL" tidak menyembunyikan masalah ini, mereka mungkin menjadi pilihan terbaik ketika Anda meningkatkan sistem. Tetapi ingat bahwa Stackoverflow masih menggunakan database relasional untuk menyimpan semua datanya, dengan penggunaan terbatas NoSQL di lapisan caching - jadi Anda harus SANGAT besar sebelum Anda dipaksa untuk menggunakan NoSQL untuk menyimpan data Anda.


Berita gembira terakhir ini sangat menarik - apakah Anda memiliki tautan ke beberapa situs meta SO untuk pembaca yang tertarik untuk mengklik tentang penggunaan SO (non) SO pada NoSQL? Terima kasih!
kcrisman


2

Database Relasional dioptimalkan untuk mencari nilai apa pun di flatow secara efektif.

Jangan bingung kemampuan untuk mencari nilai "apa saja" dalam satu baris dengan nilai "setiap" dalam satu baris. Cara paling efektif untuk melakukan ini memerlukan satu atau lebih indeks. Anda dapat memiliki indeks yang menyertakan semua bidang, tetapi kemudian Anda hanya terhalang kemampuan Anda untuk melakukan perubahan yang memerlukan perubahan indeks (memasukkan, memperbarui, menghapus). Anda (atau DBA Anda) harus memahami data, penggunaan, kemacetan dll.


Contoh yang baik adalah menyimpan obrolan. Mungkin ada kebutuhan untuk menghubungkannya dengan beberapa data lain dan melakukan semua jenis analisis, tetapi selama sesi obrolan itu sendiri, pengguna akan menghargai sesuatu yang lebih cepat yang tidak memiliki semua overhead dari RDBMS seperti transaksi, atau kendala.
JeffO

-1

Sudah banyak jawaban, tetapi saya hanya ingin menambahkan ringkasan saya.

Jelas konsep NoSQL mencakup berbagai pendekatan yang berbeda dalam mengatur data pada disk, dalam memori, dan mengeksposinya melalui bahasa query (beberapa bahkan seperti SQL!). Dalam pandangan saya kekuatan datang dari berbagai sistem ini sehingga Anda dapat memilih alat terbaik untuk pekerjaan itu. Tapi semoga saja Anda dapat memenuhi selusin kebutuhan yang berbeda hanya dengan beberapa solusi berbeda, Anda tidak akan ingin mengelola selusin sistem yang berbeda.

Database relasional dapat membuat Anda sangat jauh dan merupakan teknologi yang terbukti, tetapi sama seperti database Anda mungkin ingin memilih bahasa pemrograman berdasarkan kebutuhan masing-masing proyek (tetapi juga memperhitungkan pengalaman tim).


-2

Saya telah menggunakan couchdb selama dua tahun sekarang. Ini sebagian besar digunakan untuk manajemen dan konfigurasi konten.

Untuk hubungan hierarkis lebih mudah dikelola ketika Anda bisa memvisualisasikannya. Untuk sebagian besar data, lebih mudah mengedit JSON daripada menulis pernyataan UPDATE dalam banyak kasus. Sebenarnya, tidak butuh programmer untuk mengedit JSON. Dan SQL memberi Anda baris dan kolom, yang kemudian harus Anda petakan menjadi semacam struktur objek.

Anda juga mendapatkan peningkatan kinerja karena Anda tidak bergabung dengan 10-20 tabel pada kueri kompleks. Tampilan Couchdb sangat cepat karena javascript yang mereka gunakan tidak dieksekusi pada waktu permintaan.

Sebagian besar programmer memahami Javascript, dan sebagian besar programmer berjuang dengan SQL sesekali.

Dalam Couchdb, pandangan dapat dianggap sebagai abstrak dari dokumen JSON. Bagaimana data tampilan terstruktur terserah Anda (Anda tidak dibatasi oleh hierarki asli).

Saya tidak akan menggunakan Couchdb untuk data yang sangat transaksional, tetapi untuk data semi-statis dengan struktur tipe bagian-ledakan, jauh lebih mudah untuk bekerja daripada SQL.

Namun perlu dicatat, bahwa tidak ada 'normalisasi' yang dapat diterapkan (meskipun menghindari duplikasi data adalah tujuan yang layak), dan pada dasarnya ada strategi pembaruan 'optimis' yang mirip dengan penguncian optimis.

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.