3.1. Sifat ASAM lemah
Untuk waktu yang lama, konsistensi data telah menjadi sapi suci bagi para arsitek dan pengembang. Semua basis data relasional menyediakan beberapa tingkat isolasi, baik melalui kunci pembaruan dan pemblokiran pembacaan, atau melalui undo log. Dengan munculnya informasi dalam jumlah besar dan sistem terdistribusi, menjadi jelas bahwa tidak mungkin untuk memastikan serangkaian operasi transaksional untuk mereka, di satu sisi, dan untuk mendapatkan ketersediaan tinggi dan waktu respons yang cepat, di sisi lain.
Selain itu, bahkan memperbarui satu record tidak menjamin bahwa pengguna lain akan langsung melihat perubahan dalam sistem, karena perubahan dapat terjadi, misalnya, di node master, dan replika disalin secara asinkron ke node slave, yang dengannya pengguna lain bekerja. Dalam hal ini, dia akan melihat hasilnya setelah jangka waktu tertentu. Ini disebut konsistensi akhirnya dan inilah yang akan dilakukan oleh semua perusahaan Internet terbesar di dunia sekarang, termasuk Facebook dan Amazon. Yang terakhir dengan bangga menyatakan bahwa interval maksimum di mana pengguna dapat melihat data yang tidak konsisten tidak lebih dari satu detik. Contoh dari situasi seperti itu ditunjukkan pada gambar:
Pertanyaan logis yang muncul dalam situasi seperti itu adalah apa yang harus dilakukan dengan sistem yang secara klasik menuntut konsistensi atomisitas operasi yang tinggi dan pada saat yang sama membutuhkan cluster yang terdistribusi cepat - keuangan, toko online, dll.? Praktik menunjukkan bahwa persyaratan ini tidak lagi relevan: inilah yang dikatakan oleh salah satu perancang sistem perbankan keuangan: “Jika kita benar-benar menunggu penyelesaian setiap transaksi di jaringan global ATM (ATM), transaksi akan memakan waktu lama sehingga pelanggan akan melarikan diri dengan marah. Apa yang terjadi jika Anda dan pasangan menarik uang pada waktu yang sama dan melebihi batas? "Kalian berdua akan mendapatkan uangnya, dan kita akan memperbaikinya nanti."
Contoh lain adalah pemesanan hotel yang ditunjukkan pada gambar. Toko online yang kebijakan datanya mengasumsikan konsistensi akhir diperlukan untuk memberikan tindakan jika terjadi situasi seperti itu (penyelesaian konflik otomatis, rollback operasi, pembaruan dengan data lain). Dalam praktiknya, hotel selalu berusaha untuk menyimpan "kumpulan" kamar gratis jika terjadi keadaan darurat, dan ini bisa menjadi solusi untuk situasi kontroversial.
Nyatanya, sifat ASAM lemah tidak berarti tidak ada sama sekali. Dalam kebanyakan kasus, aplikasi yang bekerja dengan database relasional menggunakan transaksi untuk mengubah objek yang terkait secara logis (urutan - item pesanan), yang diperlukan, karena ini adalah tabel yang berbeda. Dengan desain model data yang benar dalam database NoSQL (agregat adalah pesanan bersama dengan daftar item pesanan), Anda dapat mencapai tingkat isolasi yang sama saat mengubah satu catatan seperti di database relasional.
3.2. Sistem terdistribusi, tidak ada sumber daya bersama (tidak berbagi apa pun)
Sekali lagi, ini tidak berlaku untuk grafik basis data, yang strukturnya, menurut definisi, tidak menyebar dengan baik ke node jarak jauh.
Ini mungkin motif utama pengembangan database NoSQL. Dengan pertumbuhan longsoran informasi di dunia dan kebutuhan untuk memprosesnya dalam waktu yang wajar, masalah skalabilitas vertikal muncul - pertumbuhan kecepatan prosesor berhenti di 3,5 GHz, kecepatan membaca dari disk juga tumbuh di a kecepatan lambat, ditambah harga server yang kuat selalu lebih dari harga total beberapa server sederhana. Dalam situasi ini, database relasional konvensional, bahkan berkerumun di array disk, tidak mampu memecahkan masalah kecepatan, skalabilitas, dan throughput.
Satu-satunya jalan keluar dari situasi ini adalah penskalaan horizontal, ketika beberapa server independen dihubungkan oleh jaringan cepat dan masing-masing hanya memiliki / memproses sebagian data dan / atau hanya sebagian dari permintaan pembaruan-baca. Dalam arsitektur ini, untuk meningkatkan kapasitas penyimpanan (kapasitas, waktu respons, throughput), Anda hanya perlu menambahkan server baru ke cluster - itu saja. Sharding, replikasi, toleransi kesalahan (hasilnya akan diperoleh bahkan jika satu atau lebih server berhenti merespons), redistribusi data jika terjadi penambahan node ditangani oleh database NoSQL itu sendiri.
Saya akan menyajikan secara singkat properti utama dari database NoSQL terdistribusi:
Replikasi - menyalin data ke node lain saat memperbarui. Memungkinkan keduanya mencapai skalabilitas yang lebih besar dan meningkatkan ketersediaan dan keamanan data. Merupakan kebiasaan untuk membagi menjadi dua jenis:
master-budak :
dan peer-to-peer : 
Tipe pertama mengasumsikan skalabilitas yang baik untuk membaca (dapat terjadi dari node mana pun), tetapi penulisan yang tidak dapat diskalakan (hanya ke node master). Ada juga seluk-beluk dalam memastikan ketersediaan konstan (jika master crash, baik secara manual atau otomatis, salah satu node yang tersisa ditugaskan ke tempatnya). Jenis replikasi kedua mengasumsikan bahwa semua node sama dan dapat melayani permintaan baca dan tulis.
Sharding adalah pembagian data berdasarkan node:
Sharding sering digunakan sebagai "penopang" ke database relasional untuk meningkatkan kecepatan dan throughput: aplikasi pengguna mempartisi data di beberapa database independen dan, ketika pengguna meminta data yang sesuai, mengakses database tertentu. Dalam database NoSQL, sharding, seperti replikasi, dilakukan secara otomatis oleh database itu sendiri dan aplikasi pengguna terpisah dari mekanisme kompleks ini.
3.3. Database NoSQL sebagian besar open source dan dibuat pada abad ke-21
Alasan kedua adalah bahwa Sadalaj dan Fowler tidak mengklasifikasikan database objek sebagai NoSQL (walaupun http://nosql-database.org/ memasukkannya ke dalam daftar umum), karena mereka dibuat pada tahun 90-an dan tidak pernah mendapatkan banyak popularitas . .
Gerakan NoSQL semakin populer dengan kecepatan yang luar biasa. Namun, ini tidak berarti bahwa database relasional menjadi peninggalan atau sesuatu yang kuno. Kemungkinan besar mereka akan digunakan dan digunakan seperti sebelumnya secara aktif, tetapi semakin banyak database NoSQL akan bersimbiosis dengan mereka. Kita memasuki era kegigihan poliglot, era di mana penyimpanan data yang berbeda digunakan untuk kebutuhan yang berbeda. Sekarang tidak ada monopoli database relasional sebagai sumber data yang tidak terbantahkan. Semakin banyak, arsitek memilih penyimpanan berdasarkan sifat data itu sendiri dan bagaimana kita ingin memanipulasinya, volume informasi apa yang diharapkan. Jadi semuanya menjadi lebih menarik.
Di bawah ini kami akan mencoba memahami pengoperasian database terdistribusi menggunakan DBMS NoSQL Cassandra sebagai contoh ...