Pandhuan kanggo NoSQL kanggo Pangembang

Yen sampeyan wis ngetutake tren ing pangembangan backend lan Big Data, sampeyan bisa uga wis ngelingi buzz ing basis data NoSQL ing taun-taun pungkasan. Sawetara wong diilhami dening pendekatan iki kanggo basis data, dene liyane mikir yen ana sawetara trik sing didhelikake: model data kasebut ora padha karo basis data relasional biasa, antarmuka program aplikasi ora biasa, lan aplikasi asring ora bisa dingerteni. Ing artikel iki aku bakal pitutur marang kowe kok padha digawe ing Panggonan pisanan, iki database NoSQL, masalah apa padha ngatasi lan kok dadi akeh database beda dumadakan needed. Yen sampeyan anyar ing NoSQL, sampeyan bisa uga kasengsem ing bagean pungkasan artikel, sing nampilake jinis basis data NoSQL sing dakanggep kudu ditelusuri dhisik supaya bisa ngerti babagan lapangan kasebut.

Napa kita dumadakan butuh database anyar?

Sampeyan bisa uga bingung takon: apa sing salah karo database relasional? Intine dheweke kerjane kanthi apik nganti pirang-pirang taun, nanging saiki ana masalah sing ora bisa ditindakake maneh. Miturut sawetara ramalan, ing 2018 manungsa bakal ngasilake 50.000 gigabyte data per detik. Iki minangka jumlah data sing akeh banget! Panyimpenan lan penanganan kasebut nyebabake tantangan teknik sing serius. Sing luwih elek yaiku volume iki terus berkembang. Ternyata, database relasional kurang cocog kanggo nggarap volume data sing akeh banget. Padha dirancang kanggo mbukak ing mesin siji, lan yen sampeyan pengin nangani panjalukan liyane, iku mung pilihan kanggo tuku komputer karo luwih RAM lan prosesor luwih kuat. Sayange, jumlah pitakon sing bisa ditangani siji mesin diwatesi, lan kanggo karya sing disebarake ing pirang-pirang mesin, kita butuh teknologi database sing beda. Mesthi, sawetara sing maca bakal ngguyu ing titik iki lan ujar manawa ana rong cara sing nyebar kanggo nggunakake macem-macem mesin ing kasus database hubungan: replikasi lan sharding. Iku bener, nanging cara iki ora cukup kanggo ngatasi tugas kita. Replikasi diwaca minangka teknik sing saben nganyari basis data disebarake menyang mesin liyane sing mung bisa nangani panjaluk maca. Ing kasus iki, kabeh owah-owahan dileksanakake dening siji server, disebut simpul master, nalika server liyane, disebut replika diwaca, mung njaga salinan data. Pangguna bisa maca saka mesin apa wae, nanging ngganti data mung liwat simpul master. Iki minangka cara sing trep lan populer banget, nanging mung ngidini sampeyan ngolah panjaluk maca luwih akeh lan ora ngrampungake masalah ngolah volume data sing dibutuhake. Sharding minangka pendekatan populer liyane sing nggunakake pirang-pirang conto basis data relasional. Saben wong nangani operasi nulis lan maca kanggo bagean data. Yen basis data nyimpen informasi babagan pelanggan, contone, nggunakake sharding, siji mesin bisa nangani kabeh panjalukan kanggo pelanggan sing jenenge diwiwiti karo A, mesin liyane bisa nyimpen kabeh data kanggo pelanggan sing jenenge diwiwiti karo B, lan liya-liyane. Sanajan sharding ngidini sampeyan ngrekam data luwih akeh, ngatur database kasebut minangka ngipi elek nyata: sampeyan kudu nyelarasake data ing mesin lan skala kluster ing loro arah yen perlu. Senajan katon prasaja ing teori, njupuk iku cukup tantangan.

Apa database relasional bisa ditingkatake?

Aku mikir sampeyan wis percaya yen database relasional ora cocog karo volume data sing digawe ing jagad modern. Sanajan, sampeyan isih mikir kenapa durung ana sing nggawe database hubungan "luwih apik" sing bisa mlaku kanthi efisien ing pirang-pirang mesin. Koyone teknologi iki mung durung dikembangake, lan database relasional sing disebarake bakal katon banget. Alas, iki ora bakal kelakon. Iki ora mungkin sacara matematis, lan ora ana sing bisa ditindakake. Kanggo ngerti sebabe kedadeyan kasebut, sampeyan kudu ndeleng teorema CAP (teorema Brewer). Iki dibuktekake ing taun 1999, lan nyatakake yen basis data sing disebarake ing pirang-pirang mesin bisa nduweni telung sifat ing ngisor iki: Konsistensi - operasi maca apa wae ngasilake asil saka operasi nulis sing cocog pungkasan. Yen sistem kasebut konsisten, sawise nulis data anyar, ora bisa maca data lawas sing wis ditindih. Kasedhiyan ( A Availability) - sistem sing disebarake bisa nglayani panjalukan sing mlebu kapan wae lan ngasilake respon sing ora ana kesalahan. Toleransi partisi - basis data terus nanggapi panjaluk maca lan nulis sanajan sawetara server ora bisa komunikasi karo siji liyane. Gagal sementara iki diarani kegagalan konektivitas jaringan lan bisa disebabake dening macem-macem faktor, wiwit saka masalah jaringan fisik amarga server alon nganti karusakan fisik kanggo peralatan jaringan. Kabeh properti kasebut pancen praktis, lan kita pengin database kanggo nggabungake kabeh. Ora ana pangembang sing waras sing pengin nyerah, ujare, aksesibilitas tanpa entuk imbalan. Sayange, teorema CAP uga nyatakake yen kabeh telung sifat ora bisa ditahan bebarengan. Nyadari iki bisa uga ora gampang, nanging bisa uga. Kaping pisanan, yen kita butuh basis data sing disebarake, mesthine kudu "toleransi pedhot." Iki malah ora dibahas. Pedhot kelakon kabeh wektu lan database kita kudu bisa sanajan iki. Saiki ayo ngerti sebabe kita ora bisa nggayuh konsistensi lan kasedhiyan. Mbayangno kita duwe database prasaja mlaku ing loro mesin: A lan B. Sembarang pangguna bisa nulis kanggo salah siji mesin, sawise kang data disalin menyang liyane. Saiki bayangake manawa mesin kasebut ora bisa sesambungan, lan mesin B ora bisa ngirim data utawa nampa data saka mesin A. Yen sajrone wektu iki mesin B nampa panjalukan diwaca saka klien, ana rong pilihan:

1. Entuk data lokal maneh, sanajan dudu sing paling anyar. Ing kasus iki, preferensi diwenehake kanggo kasedhiyan (kanggo ngasilake paling ora sawetara data, malah sing wis lawas).
2. Kesalahan bali. Ing kasus iki, konsistensi luwih disenengi: klien ora bakal nampa data sing wis lawas, nanging ora bakal nampa data apa wae.

Basis data relasional ngupayakake sifat "konsistensi" lan "kasedhiyan" bebarengan, lan mulane ora bisa digunakake ing lingkungan sing disebarake. Nyoba ngleksanakake kabeh kapabilitas database relasional ing sistem sing disebarake bakal dadi ora nyata utawa ora bisa ditindakake . Ing sisih liya, database NoSQL menehi premium kanggo skalabilitas lan kinerja. Biasane ora duwe kemampuan "dhasar" kaya sambungan lan transaksi, lan model data dadi beda banget, bisa uga mbatesi sawetara cara. Kabeh iki ndadekake bisa nyimpen volume data sing luwih gedhe lan ngolah pitakon luwih akeh tinimbang sadurunge.

Kepiye database NoSQL ngimbangi konsistensi lan kasedhiyan?

Sampeyan bisa uga koyone yen sampeyan milih database NoSQL, sampeyan bakal tansah nampa sawetara data outdated utawa kesalahan yen ana Gagal. Ing laku, kasedhiyan lan konsistensi ora mung pilihan sing kasedhiya. Ana sawetara saka sudhut opsi kasedhiya kanggo sampeyan milih saka. Database relasional ora duwe opsi kasebut, nanging NoSQL ngidini sampeyan ngontrol eksekusi pitakon kanthi cara sing padha. Salah siji cara utawa liyane, padha ngijini sampeyan kanggo nyetel loro paramèter nalika nindakake nulis utawa maca operasi ing database NoSQL: W - carane akeh mesin ing kluster kudu konfirmasi nyimpen data nalika nindakake operasi nulis . Sing luwih gedhe nomer mesin ing ngendi sampeyan nulis data, bakal luwih gampang kanggo maca data paling anyar ing operasi maca sabanjuré, nanging uga luwih suwe. R – carane akeh mesin sampeyan pengin maca data saka . Ing sistem sing disebarake, nyebarake data menyang kabeh mesin ing kluster bisa njupuk sawetara wektu, supaya sawetara server bakal duwe data paling anyar nalika liyane bakal lag. Sing luwih nomer mesin saka kang data diwaca, sing luwih dhuwur kemungkinan kanggo maca data saiki. Ayo goleki conto praktis. Yen sampeyan duwe limang komputer ing kluster lan sampeyan mutusake kanggo nulis data mung siji banjur maca data saka siji komputer sing dipilih kanthi acak, banjur ana kemungkinan 80% yen sampeyan bakal maca data basi. Ing tangan liyane, iki bakal nggunakake minimal sumber daya. Dadi yen data warisan apik karo sampeyan, iku dudu pilihan sing ala. Ing kasus iki, paramèter W lan R padha karo 1. Ing sisih liya, yen sampeyan nulis data menyang kabeh limang mesin ing basis data NoSQL, sampeyan bisa maca data saka mesin apa wae lan dijamin entuk data sing paling anyar saben wektu. Nindakake operasi sing padha ing jumlah mesin sing luwih akeh bakal luwih suwe, nanging yen data anyar penting kanggo sampeyan, sampeyan bisa milih pilihan iki. Ing kasus iki, W = R = 5. Apa jumlah minimal maca lan nulis sing dibutuhake kanggo konsistensi database? Punika rumus prasaja: R + W ≥ N + 1 , ngendi N iku nomer mesin ing kluster. Iki tegese karo limang server, sampeyan bisa milih salah siji R = 2 lan W = 4, utawa R = 3 lan W = 3, utawa R = 4 lan W = 2. Ing kasus iki, iku ora Matter kang mesin data. wis ditulis, maca bakal tansah rampung saka ing paling siji mesin karo data up-to-date. Basis data liyane, kayata DynamoDB, duwe watesan sing beda lan mung ngidini nulis sing konsisten. Saben Piece saka data disimpen ing telung server, lan nalika sembarang data ditulis, ditulis kanggo loro saka telung mesin. Nanging nalika maca data, sampeyan bisa milih salah siji saka rong opsi:

1. Strictly konsisten diwaca, kang data diwaca saka rong mesin saka telung lan tansah ngasilake data pungkasan ditulis.
2. Waca sing konsisten, sing siji mesin dipilih kanthi acak kanggo maca data. Nanging, iki bisa sementara mbalekake data sing wis lawas.

Napa database NoSQL akeh banget?

Yen sampeyan ngetutake kabar paling anyar babagan pangembangan piranti lunak, mesthine sampeyan wis krungu babagan macem-macem database NoSQL, kayata MongoDB, DynamoDB, Cassandra, Redis lan liya-liyane. Sampeyan bisa uga mikir: kenapa kita butuh macem-macem database NoSQL? Alesane gampang: database NoSQL sing beda dirancang kanggo ngatasi masalah sing beda. Mulane jumlah database saingan akeh banget. Basis data NoSQL kalebu papat kategori utama:

Database berorientasi dokumen

Basis data iki nyedhiyakake kemampuan kanggo nyimpen dokumen bersarang sing rumit, dene basis data relasional mung ndhukung baris siji dimensi. Fitur iki bisa migunani ing akeh kasus, contone, nalika perlu kanggo nyimpen informasi bab pangguna karo sawetara alamat ing sistem. Nalika nggunakake basis data berorientasi dokumen, ing kasus iki, sampeyan mung bisa nyimpen obyek kompleks sing kalebu macem-macem alamat, dene ing basis data relasional sampeyan kudu nggawe rong tabel: siji kanggo informasi pangguna lan siji kanggo alamat. Database berorientasi dokumen nyepetake jurang antarane model obyek lan model data. Sawetara basis data relasional, kayata PostgreSQL, saiki uga ndhukung panyimpenan berorientasi dokumen, nanging umume database relasional isih kurang kemampuan iki.

Database Kunci/Nilai

Database kunci/nilai biasane ngetrapake model NoSQL sing paling gampang. Ateges, dheweke menehi sampeyan tabel hash sing disebarake , ngidini sampeyan nulis data menyang kunci sing diwenehake lan maca maneh nggunakake. Basis data kunci/nilai bisa diukur lan nduweni latensi sing luwih murah tinimbang database liyane.

Database Grafik

Akeh wilayah subyek, contone, jaringan sosial utawa informasi babagan film lan aktor, bisa dituduhake minangka grafik. Sanajan grafik kasebut bisa diwakili nggunakake basis data relasional, nanging angel lan ora trep. Yen sampeyan butuh data grafik, luwih becik nggunakake database grafik khusus, sing bisa nyimpen informasi babagan grafik ing kluster sing disebarake lan ndadekake bisa ngetrapake algoritma kanthi efisien ing grafik.

Database Columnar

Bentenane utama antarane kolom lan jinis database liyane yaiku cara data disimpen ing disk. Database relasional nggawe file kanggo saben tabel lan nyimpen nilai kanggo kabeh baris kanthi urutan. Database Columnar nggawe file kanggo saben kolom ing tabel sampeyan. Struktur iki ngidini sampeyan nglumpukake data lan nglakokake pitakon tartamtu kanthi luwih efisien, nanging sampeyan kudu mesthekake yen data kasebut cocog karo watesan database kasebut.

Database sing kudu sampeyan pilih?

Milih database biasane masalah frustasi, lan kanthi akeh pilihan sing kasedhiya, bisa uga katon kaya tugas sing akeh banget. Kabar apik yaiku ora perlu milih mung siji. Tinimbang nggawe aplikasi monolitik siji sing ngleksanakake kabeh kemampuan lan nduweni akses menyang kabeh data sistem, sampeyan bisa nggunakake pola modern liyane sing disebut microservices : break aplikasi menyang pesawat saka layanan sawijining. Saben layanan ngatasi masalah sempit dhewe, lan mung nggunakake database dhewe, sing paling cocok kanggo ngatasi masalah iki.

Kepiye carane sampeyan sinau kabeh iki?

Kanthi akeh database , sinau kabeh bisa katon kaya tugas sing ora mungkin. Kabar apik: sampeyan ora kudu nindakake iki. Mung ana sawetara jinis dhasar database NoSQL, lan yen sampeyan ngerti cara kerjane, liyane bakal luwih gampang dingerteni. Uga, sawetara database NoSQL digunakake luwih kerep tinimbang liyane, supaya paling apik kanggo fokus efforts ing solusi paling populer. Ing ngisor iki dhaptar database NoSQL sing paling umum digunakake sing dakanggep sampeyan kudu dideleng:

1. MongoDB . Bisa uga database NoSQL sing paling populer ing pasar. Yen perusahaan ora nggunakake database relasional minangka nyimpen data utami, iku mbokmenawa nggunakake MongoDB. Iki minangka panyimpenan dokumen sing fleksibel kanthi alat sing apik. Ing awal kariré, MongoDB duwe reputasi sing ala amarga ilang data ing sawetara kasus , nanging wiwit iku stabilitas lan linuwih wis saya apik banget. Deleng kursus MongoDB iki yen sampeyan pengin sinau luwih akeh.


2. DynamoDB . Yen sampeyan nggunakake Amazon Web Services (AWS), luwih becik sampeyan sinau babagan DynamoDB. Iki minangka basis data latensi sing bisa dipercaya, skalabel, kurang kanthi set fitur sing sugih lan integrasi karo akeh layanan AWS liyane. Sisih paling apik yaiku sampeyan ora kudu masang dhewe. Nggawe kluster DynamoDB sing bisa diukur sing bisa nangani ewonan pitakon mung sawetara klik. Yen sampeyan kepengin weruh, sampeyan bisa ndeleng kursus iki .


3. Neo4j . Database grafik sing paling umum. Iki minangka solusi sing bisa diukur lan stabil sing cocog kanggo wong sing pengin nggunakake model data grafik. Yen sampeyan pengin sinau luwih lengkap, miwiti kursus iki .


4. Redis . Nalika database liyane sing diterangake ing kene digunakake kanggo nyimpen data aplikasi inti, Redis digunakake utamane kanggo ngleksanakake cache lan nyimpen data tambahan. Ing sawetara kasus, salah siji saka database kasebut ing ndhuwur digunakake bebarengan karo Redis. Kanggo sinau luwih lengkap, priksa kursus iki.

Ing 2018 karo NoSQL

Basis data NoSQL minangka lapangan sing akeh lan berkembang kanthi cepet. Dheweke ngidini sampeyan nyimpen lan ngolah data sing ora bisa dibayangake sadurunge, nanging ana biaya. Basis data iki ora duwe akeh fitur sing sampeyan kenal ing basis data relasional, lan bisa uga angel nyiyapake dhewe kanggo nggunakake. Nanging yen sampeyan ngerti, sampeyan bisa nggawe basis data sing bisa diukur lan disebarake sing bisa nangani panjaluk maca lan nulis sing nggumunake, sing bisa dadi penting banget amarga volume data sing luwih gedhe lan gedhe digawe. Asli: https://simpleprogrammer.com/guide-nosql-software-developers/