3.1. Sifat ASID yang lemah

Untuk masa yang lama, konsistensi data telah menjadi lembu suci bagi arkitek dan pemaju. Semua pangkalan data hubungan menyediakan beberapa tahap pengasingan, sama ada melalui kunci kemas kini dan bacaan menyekat, atau melalui log asal. Dengan kemunculan sejumlah besar maklumat dan sistem yang diedarkan, menjadi jelas bahawa adalah mustahil untuk memastikan satu set operasi transaksi untuk mereka, di satu pihak, dan untuk mendapatkan ketersediaan yang tinggi dan masa tindak balas yang cepat, di pihak yang lain.

Selain itu, walaupun mengemas kini satu rekod tidak menjamin bahawa mana-mana pengguna lain akan serta-merta melihat perubahan dalam sistem, kerana perubahan itu boleh berlaku, sebagai contoh, dalam nod induk, dan replika disalin secara tidak segerak ke nod hamba, yang dengannya pengguna lain berfungsi. Dalam kes ini, dia akan melihat hasilnya selepas tempoh masa tertentu. Ini dipanggil konsistensi akhirnya dan inilah yang akan dilakukan oleh semua syarikat Internet terbesar di dunia sekarang, termasuk Facebook dan Amazon. Yang terakhir dengan bangganya mengisytiharkan bahawa selang maksimum semasa pengguna boleh melihat data yang tidak konsisten adalah tidak lebih daripada satu saat. Contoh keadaan sedemikian ditunjukkan dalam rajah:

Persoalan logik yang timbul dalam situasi sedemikian ialah apa yang perlu dilakukan dengan sistem yang secara klasik meletakkan tuntutan tinggi terhadap ketekalan atomicity operasi dan pada masa yang sama memerlukan kluster yang diedarkan dengan cepat - kewangan, kedai dalam talian, dll.? Amalan menunjukkan bahawa keperluan ini tidak lagi relevan: inilah yang dikatakan oleh seorang pereka bentuk sistem perbankan kewangan: “Jika kita benar-benar menunggu untuk menyelesaikan setiap transaksi dalam rangkaian global ATM (ATM), urus niaga akan mengambil masa yang lama sehingga pelanggan akan melarikan diri dalam keadaan marah. Apa yang berlaku jika anda dan pasangan anda mengeluarkan wang pada masa yang sama dan melebihi had? “Kamu berdua akan mendapat wang itu, dan kami akan membetulkannya kemudian.”

Contoh lain ialah tempahan hotel yang ditunjukkan dalam gambar. Kedai dalam talian yang dasar datanya menganggap konsisten akhirnya diperlukan untuk menyediakan langkah sekiranya berlaku situasi sedemikian (penyelesaian konflik automatik, rollback operasi, kemas kini dengan data lain). Dalam amalan, hotel sentiasa cuba menyimpan "kolam" bilik percuma sekiranya berlaku kecemasan, dan ini boleh menjadi penyelesaian kepada situasi kontroversi.

Sebenarnya, sifat ACID yang lemah tidak bermakna ia tidak wujud sama sekali. Dalam kebanyakan kes, aplikasi yang berfungsi dengan pangkalan data hubungan menggunakan transaksi untuk menukar objek yang berkaitan secara logik (pesanan - pesanan item), yang diperlukan, kerana ini adalah jadual yang berbeza. Dengan reka bentuk model data yang betul dalam pangkalan data NoSQL (agregat ialah pesanan bersama-sama dengan senarai item pesanan), anda boleh mencapai tahap pengasingan yang sama apabila menukar satu rekod seperti dalam pangkalan data hubungan.

3.2. Sistem teragih, tiada sumber kongsi (kongsi apa-apa)

Sekali lagi, ini tidak terpakai kepada graf pangkalan data, yang strukturnya, mengikut definisi, tidak tersebar dengan baik merentasi nod jauh.

Ini mungkin merupakan leitmotif utama pembangunan pangkalan data NoSQL. Dengan pertumbuhan runtuhan salji maklumat di dunia dan keperluan untuk memprosesnya dalam masa yang munasabah, masalah kebolehskalaan menegak timbul - pertumbuhan kelajuan pemproses berhenti pada 3.5 GHz, kelajuan bacaan dari cakera juga berkembang pada kadar yang perlahan, ditambah dengan harga pelayan yang berkuasa sentiasa lebih daripada jumlah harga beberapa pelayan mudah. Dalam keadaan ini, pangkalan data perhubungan konvensional, walaupun berkumpul pada pelbagai cakera, tidak dapat menyelesaikan masalah kelajuan, kebolehskalaan dan daya pemprosesan.

Satu-satunya jalan keluar dari situasi ini ialah penskalaan mendatar, apabila beberapa pelayan bebas disambungkan oleh rangkaian pantas dan masing-masing memiliki / memproses hanya sebahagian daripada data dan / atau hanya sebahagian daripada permintaan kemas kini baca. Dalam seni bina ini, untuk meningkatkan kapasiti storan (kapasiti, masa tindak balas, pemprosesan), anda hanya perlu menambah pelayan baharu pada kluster - dan itu sahaja. Sharding, replikasi, toleransi kesalahan (hasilnya akan diperolehi walaupun satu atau lebih pelayan berhenti bertindak balas), pengagihan semula data sekiranya menambah nod dikendalikan oleh pangkalan data NoSQL itu sendiri.

Saya akan membentangkan secara ringkas sifat utama pangkalan data NoSQL yang diedarkan:

Replikasi - menyalin data ke nod lain semasa mengemas kini. Membolehkan kedua-duanya mencapai kebolehskalaan yang lebih besar dan meningkatkan ketersediaan dan keselamatan data. Ia adalah kebiasaan untuk membahagikan kepada dua jenis:

tuan-hamba : dan peer-to-peer :

Jenis pertama menganggap kebolehskalaan yang baik untuk membaca (boleh berlaku dari mana-mana nod), tetapi penulisan tidak boleh skala (hanya kepada nod induk). Terdapat juga kehalusan dengan memastikan ketersediaan yang berterusan (sekiranya berlaku ranap induk, sama ada secara manual atau automatik salah satu nod yang tinggal ditugaskan ke tempatnya). Jenis replikasi kedua mengandaikan bahawa semua nod adalah sama dan boleh melayani permintaan baca dan tulis.

Sharding ialah pembahagian data mengikut nod:

Sharding sering digunakan sebagai "crutch" kepada pangkalan data hubungan untuk meningkatkan kelajuan dan daya pemprosesan: aplikasi pengguna membahagikan data merentasi beberapa pangkalan data bebas dan, apabila pengguna meminta data yang sepadan, mengakses pangkalan data tertentu. Dalam pangkalan data NoSQL, sharding, seperti replikasi, dilakukan secara automatik oleh pangkalan data itu sendiri dan aplikasi pengguna adalah berasingan daripada mekanisme kompleks ini.

3.3. Pangkalan data NoSQL kebanyakannya adalah sumber terbuka dan dicipta pada abad ke-21

Atas alasan kedua, Sadalaj dan Fowler tidak mengklasifikasikan pangkalan data objek sebagai NoSQL (walaupun http://nosql-database.org/ memasukkannya dalam senarai umum), kerana ia dicipta pada tahun 90-an dan tidak pernah mendapat populariti. .

Pergerakan NoSQL semakin popular pada kadar yang sangat besar. Walau bagaimanapun, ini tidak bermakna bahawa pangkalan data hubungan menjadi kosong atau sesuatu yang kuno. Kemungkinan besar ia akan digunakan dan digunakan seperti sebelum ini secara aktif, tetapi semakin banyak pangkalan data NoSQL akan bertindak dalam simbiosis dengan mereka. Kita sedang memasuki era ketekunan polyglot, era di mana stor data yang berbeza digunakan untuk keperluan yang berbeza. Kini tiada monopoli pangkalan data hubungan sebagai sumber data yang tidak boleh dipertikaikan. Semakin banyak, arkitek memilih storan berdasarkan sifat data itu sendiri dan cara kita mahu memanipulasinya, jumlah maklumat yang diharapkan. Jadi semuanya menjadi lebih menarik.

Di bawah ini kami akan cuba memahami operasi pangkalan data teragih menggunakan NoSQL Cassandra DBMS sebagai contoh ...