Karakteristik database NoSQL

2.1 Munculnya istilah NoSQL

Baru-baru ini, istilah "NoSQL" menjadi sangat modis dan populer, semua jenis solusi perangkat lunak dikembangkan dan dipromosikan secara aktif di bawah tanda ini. NoSQL telah menjadi identik dengan sejumlah besar data, skalabilitas linier, cluster, toleransi kesalahan, non-relasionalitas. Namun, hanya sedikit orang yang memiliki pemahaman yang jelas tentang apa itu penyimpanan NoSQL, bagaimana istilah itu muncul, dan karakteristik umum apa yang mereka miliki. Mari kita coba mengisi celah ini.

Hal yang paling menarik tentang istilah ini adalah meskipun pertama kali digunakan pada akhir tahun 90-an, istilah ini baru memperoleh arti yang sebenarnya dalam bentuk yang digunakan sekarang pada pertengahan tahun 2009. Awalnya, ini adalah nama open -sumber database dibuat oleh Carlo Strozzi, yang menyimpan semua data sebagai file ASCII dan menggunakan skrip shell alih-alih SQL untuk mengakses data. Itu tidak ada hubungannya dengan "NoSQL" dalam bentuknya saat ini.

Pada bulan Juni 2009 Johan Oskarsson menyelenggarakan pertemuan di San Francisco untuk membahas tren baru di pasar penyimpanan dan pemrosesan TI. Dorongan utama pertemuan tersebut adalah produk open source baru seperti BigTable dan Dynamo. Untuk pertanda cerah sebuah pertemuan, perlu ditemukan istilah yang luas dan ringkas yang sangat cocok dengan tagar Twitter. Salah satu istilah ini diusulkan oleh Eric Evans dari RackSpace - "NoSQL". Istilah ini direncanakan hanya untuk satu pertemuan dan tidak memiliki beban semantik yang dalam, tetapi kebetulan menyebar ke seluruh jaringan global seperti iklan viral dan menjadi nama de facto dari seluruh tren di industri TI. Omong-omong, Voldemort (klon Amazon Dynamo), Cassandra, Hbase (analog dari Google BigTable), Hypertable, CouchDB, MongoDB berbicara di konferensi.

Perlu ditekankan sekali lagi bahwa istilah "NoSQL" benar-benar spontan dan tidak memiliki definisi atau lembaga ilmiah yang diterima secara umum di belakangnya. Nama ini lebih mencirikan vektor pengembangan TI dari basis data relasional. Itu singkatan dari Not Only SQL, meskipun ada pendukung definisi langsung dari No SQL. Pramod Sadalaj dan Martin Fowler mencoba mengelompokkan dan mensistematisasikan pengetahuan tentang dunia NoSQL dalam buku terbaru mereka "NoSQL Distilled".

2.2 Karakteristik dasar database NoSQL

Ada beberapa karakteristik umum untuk semua NoSQL, karena banyak sistem heterogen sekarang tersembunyi di bawah label NoSQL (mungkin daftar paling lengkap dapat ditemukan di http://nosql-database.org/). Banyak karakteristik yang hanya dimiliki oleh database NoSQL tertentu, saya pasti akan menyebutkan ini saat mendaftar.

1. Tidak ada SQL yang digunakan

Maksud saya ANSI SQL DML, karena banyak database mencoba menggunakan bahasa kueri yang mirip dengan sintaks favorit yang terkenal, tetapi tidak ada yang berhasil mengimplementasikannya sepenuhnya dan kemungkinan besar tidak akan berhasil. Meskipun dikabarkan ada startup yang mencoba mengimplementasikan SQL, misalnya di hadup ( http://www.drawntoscalehq.com/ dan http://www.hadapt.com/ ).

2. Tidak terstruktur (tanpa skema)

Artinya adalah bahwa dalam database NoSQL, tidak seperti database relasional, struktur data tidak diatur (atau diketik dengan lemah, jika kita menggambar analogi dengan bahasa pemrograman) - Anda dapat menambahkan bidang arbitrer di baris atau dokumen terpisah tanpa terlebih dahulu mengubah struktur secara deklaratif dari seluruh tabel. Jadi, jika ada kebutuhan untuk mengubah model data, maka satu-satunya tindakan yang cukup adalah mencerminkan perubahan kode aplikasi.

Misalnya, saat mengganti nama bidang di MongoDB:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

Jika kami mengubah logika aplikasi, maka kami mengharapkan bidang baru juga saat membaca. Namun karena kurangnya skema data, kolom totalSum hilang dari objek Order lain yang sudah ada. Dalam situasi ini, ada dua opsi untuk tindakan lebih lanjut.

Yang pertama adalah merayapi semua dokumen dan memperbarui bidang ini di semua dokumen yang ada. Karena banyaknya data, proses ini terjadi tanpa kunci (sebanding dengan perintah ubah tabel ganti nama kolom), jadi selama pembaruan, data yang sudah ada dapat dibaca oleh proses lain. Oleh karena itu, opsi kedua - memeriksa kode aplikasi - tidak dapat dihindari:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

Dan saat kami merekam ulang, kami akan menulis bidang ini ke database dalam format baru.

Konsekuensi menyenangkan dari tidak adanya skema adalah efisiensi bekerja dengan data yang jarang. Jika satu dokumen memiliki bidang tanggal_diterbitkan, dan yang kedua tidak, maka tidak ada bidang kosong tanggal_diterbitkan yang akan dibuat untuk yang kedua. Ini, pada prinsipnya, logis, tetapi contoh yang kurang jelas adalah database NoSQL keluarga kolom, yang menggunakan konsep tabel / kolom yang sudah dikenal. Namun, karena kurangnya skema, kolom tidak dideklarasikan secara deklaratif dan dapat diubah/ditambahkan selama sesi database pengguna. Ini memungkinkan, khususnya, penggunaan kolom dinamis untuk penerapan daftar.

Skema tidak terstruktur memiliki kekurangannya - selain overhead yang disebutkan di atas dalam kode aplikasi saat mengubah model data - tidak adanya semua jenis batasan dari basis (bukan nol, unik, periksa batasan, dll.), plus disana adalah kesulitan tambahan dalam memahami dan mengontrol struktur data saat bekerja dengan database dari berbagai proyek secara paralel (tidak ada kamus di sisi database). Namun, di dunia modern yang berubah dengan cepat, fleksibilitas seperti itu masih merupakan keuntungan. Contohnya adalah Twitter, yang lima tahun lalu, bersama dengan tweet, hanya menyimpan sedikit informasi tambahan (waktu, pegangan Twitter, dan beberapa byte informasi meta), tetapi sekarang, selain pesan itu sendiri, beberapa lagi kilobyte metadata disimpan dalam database.

(Selanjutnya, kita berbicara terutama tentang basis data nilai kunci, dokumen dan keluarga kolom, basis data grafik mungkin tidak memiliki properti ini)

2.3. Representasi data dalam bentuk agregat (agregat)

Berbeda dengan model relasional, yang menyimpan entitas bisnis logis aplikasi ke dalam berbagai tabel fisik untuk tujuan normalisasi, penyimpanan NoSQL beroperasi pada entitas ini sebagai objek holistik:

Contoh ini menunjukkan agregasi untuk model relasional konseptual e-niaga standar "Pesanan - Barang Pesanan - Pembayaran - Produk". Dalam kedua kasus, pesanan digabungkan dengan posisi menjadi satu objek logis, sementara setiap posisi menyimpan tautan ke produk dan beberapa atributnya, misalnya, nama (denormalisasi semacam itu diperlukan agar tidak meminta objek produk saat mengambil pesanan - aturan utama sistem terdistribusi adalah "bergabung" antar objek). Di satu agregat, pembayaran digabungkan dengan pesanan dan merupakan bagian integral dari objek, di agregat lain ditempatkan di objek terpisah. Ini menunjukkan aturan utama untuk mendesain struktur data dalam database NoSQL - harus mematuhi persyaratan aplikasi dan dioptimalkan sebanyak mungkin untuk permintaan yang paling sering.

Banyak yang akan keberatan, mencatat bahwa bekerja dengan objek besar, sering didenormalisasi, penuh dengan banyak masalah saat mencoba kueri sewenang-wenang pada data saat kueri tidak sesuai dengan struktur agregat. Bagaimana jika kita menggunakan pesanan bersama dengan item baris pesanan dan pembayaran (beginilah cara kerja aplikasi), tetapi bisnis meminta kita untuk menghitung berapa banyak unit produk tertentu yang terjual bulan lalu? Dalam hal ini, alih-alih memindai tabel OrderItem (dalam kasus model relasional), kita harus mengambil seluruh pesanan dalam penyimpanan NoSQL, meskipun kita tidak memerlukan banyak informasi ini. Sayangnya, ini adalah kompromi yang harus dibuat dalam sistem terdistribusi: kami tidak dapat menormalkan data seperti pada sistem server tunggal konvensional,

Saya mencoba mengelompokkan pro dan kontra dari kedua pendekatan tersebut dalam sebuah tabel: