Fitur database NoSQL

3.1. Sifat asam lemah

Kanggo wektu sing suwe, konsistensi data wis dadi sapi suci kanggo arsitek lan pangembang. Kabeh database relasional nyedhiyakake sawetara tingkat isolasi, liwat kunci nganyari lan pamblokiran maca, utawa liwat log batalaken. Kanthi tekane saka jumlah ageng saka informasi lan sistem mbagekke, dadi cetha yen iku mokal kanggo mesthekake pesawat transactional operasi kanggo wong-wong mau, ing tangan siji, lan diwenehi kasedhiyan dhuwur lan wektu nanggepi cepet, ing sisih liyane.

Kajaba iku, sanajan nganyari siji rekaman ora njamin manawa pangguna liyane bakal langsung ndeleng owah-owahan ing sistem kasebut, amarga owah-owahan bisa kedadeyan, contone, ing simpul master, lan replika disalin menyang simpul budak, karo pangguna liyane. nyambut gawe. Ing kasus iki, dheweke bakal weruh asil sawise wektu tartamtu. Iki diarani konsistensi pungkasan lan iki sing bakal ditindakake kabeh perusahaan Internet paling gedhe ing donya, kalebu Facebook lan Amazon. Sing terakhir kanthi bangga nyatakake yen interval maksimum nalika pangguna bisa ndeleng data sing ora konsisten ora luwih saka sedetik. Conto kahanan kasebut ditampilake ing gambar:

Pitakonan logis sing muncul ing kahanan kasebut yaiku apa sing kudu ditindakake kanthi sistem sing sacara klasik menehi panjaluk dhuwur ing konsistensi atomisitas operasi lan ing wektu sing padha mbutuhake kluster sing disebarake kanthi cepet - finansial, toko online, lan liya-liyane? Praktek nuduhake manawa syarat kasebut ora cocog maneh: ing ngisor iki ujare salah sawijining desainer sistem perbankan finansial: "Yen kita pancen ngenteni rampunge saben transaksi ing jaringan ATM (ATM) global, transaksi bakal suwe nganti pelanggan. bakal mlayu kanthi nesu. Apa sing kedadeyan yen sampeyan lan pasangan mbatalake dhuwit bebarengan lan ngluwihi watesan? "Sampeyan bakal entuk dhuwit, lan mengko bakal kita ndandani."

Conto liyane yaiku pesenan hotel sing ditampilake ing gambar. Toko online sing kabijakan data nganggep konsistensi pungkasane kudu menehi langkah-langkah ing kasus kaya ngono (resolusi konflik otomatis, rollback operasi, nganyari karo data liyane). Ing laku, hotel tansah nyoba kanggo njaga "blumbang" kamar gratis ing kasus darurat, lan iki bisa dadi solusi kanggo kahanan kontrovèrsial.

Nyatane, sifat ACID sing lemah ora ateges ora ana. Umume kasus, aplikasi sing nggarap database relasional nggunakake transaksi kanggo ngganti obyek sing gegandhengan kanthi logis (urutan - pesenan item), sing perlu, amarga iki minangka tabel sing beda. Kanthi desain model data sing bener ing database NoSQL (agregat minangka urutan bebarengan karo dhaptar item pesenan), sampeyan bisa entuk tingkat isolasi sing padha nalika ngganti rekaman siji kaya ing basis data relasional.

3.2. Sistem terdistribusi, ora ana sumber daya sing dienggo bareng (ora nuduhake apa-apa)

Maneh, iki ora ditrapake kanggo grafik database, sing strukture, miturut definisi, ora nyebar kanthi apik ing node remot.

Iki mbok menawa leitmotif utama pangembangan database NoSQL. Kanthi wutah informasi longsor ing donya lan perlu kanggo ngolah ing wektu sing cukup, masalah skalabilitas vertikal muncul - wutah kacepetan prosesor mandheg ing 3,5 GHz, kacepetan maca saka disk uga tuwuh ing a jangkah alon, plus rega server kuat tansah luwih saka rega total sawetara server prasaja. Ing kahanan iki, database relasional conventional, malah clustered ing Uploaded disk, ora bisa kanggo ngatasi masalah kacepetan, skalabilitas lan throughput.

Siji-sijine cara metu saka kahanan kasebut yaiku skala horisontal, nalika sawetara server independen disambungake kanthi jaringan sing cepet lan saben duwe / ngolah mung bagean data lan / utawa mung bagean saka panjalukan maca-update. Ing arsitektur iki, kanggo nambah kapasitas panyimpenan (kapasitas, wektu nanggepi, throughput), sampeyan mung kudu nambah server anyar kanggo kluster - lan sing. Sharding, replikasi, toleransi kesalahan (asil bakal dipikolehi sanajan siji utawa luwih server mandheg nanggapi), redistribusi data yen nambah simpul ditangani dening database NoSQL dhewe.

Aku bakal nampilake properti utama database NoSQL sing disebarake:

Replikasi - nyalin data menyang simpul liyane nalika nganyari. Ngidini loro kanggo entuk skalabilitas sing luwih gedhe lan nambah kasedhiyan lan safety data. Biasane dibagi dadi rong jinis:

Jinis pisanan nganggep skalabilitas sing apik kanggo maca (bisa kedadeyan saka simpul apa wae), nanging tulisan sing ora bisa diukur (mung kanggo simpul master). Ana uga subtleties kanggo mesthekake kasedhiyan pancet (ing kasus kacilakan master, kanthi manual utawa kanthi otomatis siji saka simpul isih diutus kanggo panggonan). Jinis replikasi kapindho nganggep yen kabeh simpul padha lan bisa nglayani panjaluk maca lan nulis.

Sharding minangka divisi data kanthi node:

Sharding asring digunakake minangka "kruk" kanggo database relasional kanggo nambah kacepetan lan throughput: aplikasi pangguna partisi data ing sawetara database independen lan, nalika pangguna njaluk data sing cocog, ngakses database tartamtu. Ing basis data NoSQL, sharding, kaya replikasi, ditindakake kanthi otomatis dening database dhewe lan aplikasi pangguna kapisah saka mekanisme rumit kasebut.

3.3. Database NoSQL biasane mbukak sumber lan digawe ing abad kaping 21

Ing sisih liya, Sadalaj lan Fowler ora nggolongake basis data obyek minangka NoSQL (sanajan http://nosql-database.org/ kalebu ing daftar umum), amarga digawe maneh ing taun 90-an lan ora tau entuk popularitas. ..

Gerakan NoSQL entuk popularitas kanthi cepet. Nanging, iki ora ateges database relasional dadi vestigial utawa kuno. Paling kamungkinan bakal digunakake lan digunakake minangka sadurunge aktif, nanging liyane lan liyane database NoSQL bakal tumindak ing simbiosis karo wong-wong mau. Kita lagi mlebu jaman ketekunan polyglot, jaman ing ngendi panyimpenan data sing beda digunakake kanggo macem-macem kabutuhan. Saiki ora ana monopoli database relasional minangka sumber data sing ora bisa dibantah. Tambah akeh, arsitek milih panyimpenan adhedhasar sifat data kasebut dhewe lan carane kita pengin ngapusi, apa volume informasi sing dikarepake. Lan kabeh dadi luwih menarik.

Ing ngisor iki kita bakal nyoba mangertos operasi database sing disebarake nggunakake NoSQL Cassandra DBMS minangka conto ...