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

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.

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).

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.

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.

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.

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.

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.

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).

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.