2.1 Munculé istilah NoSQL

Bubar, istilah "NoSQL" wis dadi modis lan populer, kabeh jinis solusi piranti lunak aktif dikembangake lan dipromosikan ing tandha iki. NoSQL wis dadi sinonim karo jumlah data sing akeh, skalabilitas linier, kluster, toleransi fault, non-relationality. Nanging, sawetara wong duwe pangerten sing jelas babagan apa panyimpenan NoSQL, kepiye istilah kasebut muncul lan karakteristik umume. Ayo coba ngisi kesenjangan iki.

Wangsulan: Bab ingkang paling menarik babagan istilah iku senadyan kasunyatan sing pisanan digunakake ing pungkasan 90s, iku mung entuk makna nyata ing wangun kang digunakake saiki ing pertengahan 2009. Kaping pisanan, iki jeneng mbukak. -sumber database digawe dening Carlo Strozzi, kang disimpen kabeh data minangka file ASCII lan digunakake skrip cangkang tinimbang SQL kanggo ngakses data. Ora ana hubungane karo "NoSQL" ing wangun saiki.

Ing wulan Juni 2009, Johan Oskarsson nganakake rapat ing San Francisco kanggo ngrembug tren anyar ing pasar panyimpenan lan pangolahan IT. Impetus utama kanggo rapat kasebut yaiku produk open source anyar kaya BigTable lan Dynamo. Kanggo tandha sing padhang kanggo rapat, sampeyan kudu nemokake istilah sing jembar lan ringkes sing cocog karo hashtag Twitter. Salah sawijining istilah kasebut diusulake dening Eric Evans saka RackSpace - "NoSQL". Istilah iki direncanakake mung siji rapat lan ora nduweni beban semantik sing jero, nanging kedadeyan kasebut nyebar ing saindhenging jaringan global kaya iklan virus lan dadi jeneng de facto saka kabeh tren ing industri IT. Miturut cara, Voldemort (klon Amazon Dynamo), Cassandra, Hbase (analog saka Google BigTable), Hypertable, CouchDB, MongoDB ngandika ing konferensi kasebut.

Java university

Perlu ditekanake maneh yen istilah "NoSQL" asline spontan lan ora duwe definisi utawa institusi ilmiah sing ditampa sacara umum. Jeneng iki dadi ciri vektor pangembangan IT adoh saka basis data relasional. Iku stands for Ora Mung SQL, sanajan ana panyengkuyung saka definisi langsung Ora SQL. Pramod Sadalaj lan Martin Fowler nyoba nglumpukake lan sistematis kawruh babagan jagad NoSQL ing buku anyar "NoSQL Distilled".

2.2 Karakteristik dhasar basis data NoSQL

Ana sawetara ciri umum kanggo kabeh NoSQL, amarga akeh sistem heterogen saiki didhelikake ing label NoSQL (mbok menawa dhaptar paling lengkap bisa ditemokake ing http://nosql-database.org/). Akeh ciri khas mung kanggo database NoSQL tartamtu, aku mesthi bakal nyebutake iki nalika listing.

1. Ora SQL digunakake

Maksudku ANSI SQL DML, amarga akeh database nyoba nggunakake basa pitakon sing padha karo sintaks favorit sing kondhang, nanging ora ana sing bisa ngetrapake kanthi lengkap lan ora bisa sukses. Senajan ana gosip wiwitan sing nyoba kanggo ngleksanakake SQL, contone ing hadup ( http://www.drawntoscalehq.com/ lan http://www.hadapt.com/ ).

2. Ora terstruktur (tanpa skema)

Tegese yaiku ing basis data NoSQL, ora kaya basis data relasional, struktur data ora diatur (utawa diketik kanthi lemah, yen kita nggambar analogi karo basa pemrograman) - sampeyan bisa nambah lapangan sing sewenang-wenang ing baris utawa dokumen sing kapisah tanpa ngganti struktur kanthi deklaratif. saka kabeh meja. Mangkono, yen ana perlu kanggo ngganti model data, banjur mung tumindak cukup kanggo nggambarake owah-owahan ing kode aplikasi.

Contone, nalika ngganti jeneng lapangan ing 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"

Yen kita ngganti logika aplikasi, kita ngarepake lapangan anyar uga nalika maca. Nanging amarga ora ana skema data, kolom totalSum ilang saka obyek Order liyane sing wis ana. Ing kahanan iki, ana rong opsi kanggo tumindak luwih.

Sing pertama yaiku nyusup kabeh dokumen lan nganyari lapangan iki ing kabeh dokumen sing wis ana. Amarga volume data, proses iki kedadeyan tanpa kunci (dibandhingake karo perintah kolom ganti jeneng tabel), saengga sajrone nganyari, data sing wis ana bisa diwaca dening proses liyane. Mulane, pilihan kapindho - mriksa kode aplikasi - ora bisa 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

Lan wis nalika kita ngrekam maneh, kita bakal nulis lapangan iki kanggo database ing format anyar.

Konsekuensi sing nyenengake saka ora ana skema yaiku efisiensi nggarap data sing jarang. Yen salah sawijining dokumen duwe lapangan date_published, lan sing nomer loro ora, mula ora ana lapangan date_published kosong sing bakal digawe kanggo sing nomer loro. Iki, ing prinsip, logis, nanging conto sing kurang jelas yaiku database NoSQL kulawarga kolom, sing nggunakake konsep tabel / kolom sing akrab. Nanging, amarga ora ana skema, kolom ora diumumake kanthi deklaratif lan bisa diganti/ditambahake sajrone sesi basis data pangguna. Iki ngidini, utamane, nggunakake kolom dinamis kanggo implementasine dhaptar.

Skema sing ora terstruktur duwe kekurangan - saliyane overhead sing kasebut ing ndhuwur ing kode aplikasi nalika ngganti model data - ora ana kabeh jinis watesan saka pangkalan (ora nol, unik, mriksa kendala, lan liya-liyane), ditambah ana. minangka kesulitan tambahan kanggo mangerteni lan ngontrol data struktur nalika nggarap database proyek sing beda-beda kanthi podo karo (ora ana kamus ing sisih database). Nanging, ing donya modern sing ganti kanthi cepet, keluwesan kasebut isih dadi kauntungan. Conto yaiku Twitter, sing limang taun kepungkur, bebarengan karo tweet, mung nyimpen informasi tambahan sing sethithik (wektu, Twitter nangani lan sawetara bait meta-informasi), nanging saiki, saliyane pesen kasebut, sawetara liyane. kilobyte metadata disimpen ing basis data.

(Sabanjure, kita ngomong utamane babagan database nilai kunci, dokumen lan kolom kulawarga, database grafik bisa uga ora duwe properti kasebut)

2.3. Representasi data awujud agregat (agregat)

Ora kaya model relasional, sing nyimpen entitas bisnis logis aplikasi menyang macem-macem tabel fisik kanggo tujuan normalisasi, toko NoSQL ngoperasikake entitas kasebut minangka obyek holistik:

Conto iki nduduhake agregasi kanggo model relasional konseptual e-commerce standar "Pesenan - Barang Pesenan - Pembayaran - Produk". Ing kasus loro kasebut, urutan kasebut digabungake karo posisi dadi siji obyek logis, nalika saben posisi nyimpen link menyang produk lan sawetara atribute, contone, jeneng (denormalisasi kasebut perlu supaya ora njaluk obyek produk nalika njupuk pesenan - aturan utama sistem sing disebarake yaiku "gabungan" antarane obyek). Ing siji agregat, pembayaran digabungake karo urutan lan minangka bagéan integral saka obyek, ing liyane padha diselehake ing obyek kapisah. Iki nduduhake aturan utama kanggo ngrancang struktur data ing basis data NoSQL - kudu nuruti syarat aplikasi lan dioptimalake sabisa kanggo panjalukan sing paling kerep.

Akeh sing bakal mbantah, nyathet yen nggarap obyek gedhe, asring denormalisasi, akeh masalah nalika nyoba pitakon sewenang-wenang ing data nalika pitakon ora cocog karo struktur agregat. Apa yen kita nggunakake pesenan bebarengan karo item baris pesenan lan pembayaran (iki carane app bisa digunakake), nanging bisnis takon kita count carane akeh unit produk tartamtu sing didol sasi pungkasan? Ing kasus iki, tinimbang mindhai tabel OrderItem (ing kasus model relasional), kita kudu njupuk kabeh pesenan ing panyimpenan NoSQL, sanajan kita ora perlu akeh informasi iki. Sayange, iki minangka kompromi sing kudu ditindakake ing sistem sing disebarake: kita ora bisa normalake data kaya ing sistem siji-server konvensional,

Aku nyoba nglumpukake pro lan kontra saka loro pendekatan ing tabel: