Mga tampok ng mga database ng NoSQL

3.1. Mahina ang mga katangian ng ACID

Sa mahabang panahon, ang pagkakapare-pareho ng data ay naging isang sagradong baka para sa mga arkitekto at developer. Ang lahat ng relational database ay nagbigay ng ilang antas ng paghihiwalay, alinman sa pamamagitan ng pag-update ng mga lock at pagharang sa mga nabasa, o sa pamamagitan ng pag-undo ng mga log. Sa pagdating ng napakaraming impormasyon at mga sistemang ipinamahagi, naging malinaw na imposibleng matiyak ang isang transaksyonal na hanay ng mga operasyon para sa kanila, sa isang banda, at makakuha ng mataas na kakayahang magamit at mabilis na oras ng pagtugon, sa kabilang banda.

Bukod dito, kahit na ang pag-update ng isang tala ay hindi ginagarantiyahan na ang sinumang ibang user ay agad na makakakita ng mga pagbabago sa system, dahil ang pagbabago ay maaaring mangyari, halimbawa, sa master node, at ang replica ay asynchronously na kinopya sa slave node, kung saan ang isa pang user gumagana. Sa kasong ito, makikita niya ang resulta pagkatapos ng isang tiyak na tagal ng panahon. Tinatawag itong eventual consistency at ito ang pupuntahan ngayon ng lahat ng pinakamalaking kumpanya ng Internet sa mundo, kabilang ang Facebook at Amazon. Ipinagmamalaki ng huli na hindi hihigit sa isang segundo ang maximum na agwat kung saan makikita ng user ang hindi tugmang data. Ang isang halimbawa ng ganitong sitwasyon ay ipinapakita sa figure:

Ang lohikal na tanong na lumitaw sa ganoong sitwasyon ay kung ano ang gagawin sa mga sistema na klasikal na naglalagay ng mataas na pangangailangan sa atomicity-consistency ng mga operasyon at sa parehong oras ay nangangailangan ng mabilis na ipinamamahagi na mga kumpol - pinansyal, online na mga tindahan, atbp.? Ipinapakita ng pagsasanay na hindi na nauugnay ang mga kinakailangang ito: narito ang sinabi ng isang taga-disenyo ng sistema ng pagbabangko sa pananalapi: "Kung talagang hihintayin natin ang pagkumpleto ng bawat transaksyon sa pandaigdigang network ng mga ATM (ATM), ang mga transaksyon ay tatagal nang napakatagal na ang mga customer tatakbo palayo sa galit. Ano ang mangyayari kung ikaw at ang iyong partner ay mag-withdraw ng pera nang sabay at lumampas sa limitasyon? "Kayong dalawa ang kukuha ng pera, at aayusin natin ito mamaya."

Ang isa pang halimbawa ay ang hotel booking na ipinapakita sa larawan. Ang mga online na tindahan kung saan ang patakaran ng data ay ipinapalagay na sa wakas ay pare-pareho ay kinakailangan upang magbigay ng mga hakbang sa kaso ng mga ganitong sitwasyon (awtomatikong paglutas ng salungatan, pagbabalik ng operasyon, pag-update sa iba pang data). Sa pagsasagawa, palaging sinusubukan ng mga hotel na panatilihin ang isang "pool" ng mga libreng silid kung sakaling magkaroon ng emergency, at maaari itong maging solusyon sa isang kontrobersyal na sitwasyon.

Sa katunayan, ang mahinang pag-aari ng ACID ay hindi nangangahulugang wala na ang mga ito. Sa karamihan ng mga kaso, ang isang application na nagtatrabaho sa isang relational database ay gumagamit ng isang transaksyon upang baguhin ang lohikal na nauugnay na mga bagay (order - order item), na kinakailangan, dahil ang mga ito ay iba't ibang mga talahanayan. Gamit ang tamang disenyo ng modelo ng data sa isang database ng NoSQL (ang pinagsama-samang ay isang order kasama ang isang listahan ng mga order item), maaari mong makamit ang parehong antas ng paghihiwalay kapag binabago ang isang solong tala tulad ng sa isang relational database.

3.2. Mga distributed system, walang shared resources (share nothing)

Muli, hindi ito nalalapat sa mga graph ng database, na ang istraktura, ayon sa kahulugan, ay hindi kumakalat nang maayos sa mga malalayong node.

Ito marahil ang pangunahing leitmotif ng pagbuo ng mga database ng NoSQL. Sa paglaki ng avalanche ng impormasyon sa mundo at ang pangangailangan na iproseso ito sa isang makatwirang oras, lumitaw ang problema ng vertical scalability - ang paglaki ng bilis ng processor ay tumigil sa 3.5 GHz, ang bilis ng pagbabasa mula sa disk ay lumalaki din sa isang mabagal na bilis, at ang presyo ng isang malakas na server ay palaging higit sa kabuuang presyo ng ilang simpleng server. Sa sitwasyong ito, ang mga conventional relational database, kahit na naka-cluster sa isang array ng mga disk, ay hindi kayang lutasin ang problema ng bilis, scalability at throughput.

Ang tanging paraan sa labas ng sitwasyon ay pahalang na pag-scale, kapag ang ilang mga independiyenteng server ay konektado sa pamamagitan ng isang mabilis na network at bawat isa ay nagmamay-ari / nagpoproseso lamang ng bahagi ng data at / o bahagi lamang ng mga kahilingan sa read-update. Sa ganitong arkitektura, upang madagdagan ang kapasidad ng imbakan (kapasidad, oras ng pagtugon, throughput), kailangan mo lamang magdagdag ng bagong server sa kumpol - at iyon na. Sharding, pagtitiklop, fault tolerance (ang resulta ay makukuha kahit na ang isa o higit pang mga server ay huminto sa pagtugon), ang muling pamamahagi ng data sa kaso ng pagdaragdag ng isang node ay pinangangasiwaan ng NoSQL database mismo.

Ipapakita ko sa madaling sabi ang mga pangunahing katangian ng mga ipinamamahaging database ng NoSQL:

Pagtitiklop - pagkopya ng data sa ibang mga node kapag nag-a-update. Nagbibigay-daan sa kapwa na makamit ang mas malaking scalability at mapataas ang availability at kaligtasan ng data. Karaniwang hatiin sa dalawang uri:

Ipinapalagay ng unang uri ang mahusay na scalability para sa pagbabasa (maaaring mangyari mula sa anumang node), ngunit hindi nasusukat na pagsulat (sa master node lamang). Mayroon ding mga subtleties sa pagtiyak ng patuloy na kakayahang magamit (sa kaganapan ng isang master crash, alinman sa manu-mano o awtomatikong isa sa mga natitirang node ay itinalaga sa lugar nito). Ipinapalagay ng pangalawang uri ng pagtitiklop na ang lahat ng mga node ay pantay at maaaring maghatid ng mga kahilingan sa pagbasa at pagsulat.

Ang Sharding ay ang paghahati ng data ayon sa mga node:

Ang Sharding ay kadalasang ginagamit bilang isang "saklay" sa mga relational na database upang mapataas ang bilis at throughput: ang user application ay naghati ng data sa ilang mga independiyenteng database at, kapag hiniling ng user ang kaukulang data, na-access ang isang partikular na database. Sa mga database ng NoSQL, ang sharding, tulad ng pagtitiklop, ay awtomatikong ginagawa ng database mismo at ang application ng user ay hiwalay sa mga kumplikadong mekanismong ito.

3.3. Ang mga database ng NoSQL ay kadalasang open source at nilikha noong ika-21 siglo

Ito ay sa pangalawang batayan na sina Sadalaj at Fowler ay hindi inuri ang mga database ng object bilang NoSQL (bagaman ang http://nosql-database.org/ ay kasama ang mga ito sa pangkalahatang listahan), dahil nilikha ang mga ito noong 90s at hindi kailanman nakakuha ng maraming katanyagan ..

Ang kilusang NoSQL ay nakakakuha ng katanyagan sa napakalaking bilis. Gayunpaman, hindi ito nangangahulugan na ang mga relational database ay nagiging vestigial o isang bagay na archaic. Malamang na aktibo silang gagamitin at gagamitin tulad ng dati, ngunit parami nang parami ang mga database ng NoSQL na kikilos bilang simbiyos sa kanila. Papasok tayo sa panahon ng polyglot persistence, isang panahon kung saan ginagamit ang iba't ibang data store para sa iba't ibang pangangailangan. Ngayon ay walang monopolyo ng mga relational database bilang isang hindi pinagtatalunang mapagkukunan ng data. Parami nang parami, pinipili ng mga arkitekto ang imbakan batay sa likas na katangian ng data mismo at kung paano namin ito gustong manipulahin, kung anong dami ng impormasyon ang inaasahan. At sa gayon ang lahat ay nagiging mas kawili-wili.

Sa ibaba ay susubukan naming maunawaan ang pagpapatakbo ng isang distributed database gamit ang NoSQL Cassandra DBMS bilang isang halimbawa ...