Mga katangian ng mga database ng NoSQL

2.1 Paglabas ng terminong NoSQL

Kamakailan lamang, ang terminong "NoSQL" ay naging napaka-sunod sa moda at tanyag, lahat ng uri ng mga solusyon sa software ay aktibong binuo at pino-promote sa ilalim ng sign na ito. Ang NoSQL ay naging magkasingkahulugan ng napakaraming data, linear scalability, cluster, fault tolerance, non-relationality. Gayunpaman, kakaunti ang may malinaw na pag-unawa sa kung ano ang storage ng NoSQL, kung paano lumitaw ang termino at kung anong mga karaniwang katangian ang mayroon sila. Subukan nating punan ang puwang na ito.

Ang pinaka-kagiliw-giliw na bagay tungkol sa termino ay na sa kabila ng katotohanan na ito ay unang ginamit noong huling bahagi ng 90s, nakakuha lamang ito ng tunay na kahulugan sa anyo kung saan ito ginagamit ngayon sa kalagitnaan ng 2009. Sa una, ito ang pangalan ng isang bukas -source database na ginawa ni Carlo Strozzi, na nag-imbak ng lahat ng data bilang mga ASCII file at gumamit ng mga script ng shell sa halip na SQL upang ma-access ang data. Wala itong kinalaman sa "NoSQL" sa kasalukuyang anyo nito.

Noong Hunyo 2009, nag-organisa si Johan Oskarsson ng isang pagpupulong sa San Francisco upang talakayin ang mga bagong uso sa IT storage at processing market. Ang pangunahing impetus para sa pulong ay ang mga bagong open source na produkto tulad ng BigTable at Dynamo. Para sa isang maliwanag na senyales para sa isang pagpupulong, kinakailangan upang makahanap ng isang malawak at maigsi na termino na ganap na magkasya sa hashtag ng Twitter. Ang isa sa mga terminong ito ay iminungkahi ni Eric Evans mula sa RackSpace - "NoSQL". Ang termino ay binalak para sa isang pulong lamang at walang malalim na semantic load, ngunit nagkataon na kumalat ito sa buong pandaigdigang network tulad ng isang viral advertisement at naging de facto na pangalan ng isang buong trend sa industriya ng IT. Sa pamamagitan ng paraan, Voldemort (Amazon Dynamo clone), Cassandra, Hbase (analogues ng Google BigTable), Hypertable, CouchDB, MongoDB ay nagsalita sa kumperensya.

Ito ay nagkakahalaga ng pagbibigay-diin muli na ang terminong "NoSQL" ay ganap na kusang-loob sa pinagmulan at walang pangkalahatang tinatanggap na kahulugan o institusyong pang-agham sa likod nito. Ang pangalan na ito sa halip ay nagpapakilala sa vector ng IT development na malayo sa mga relational database. Ito ay kumakatawan sa Not Only SQL, bagama't may mga tagasuporta ng direktang kahulugan ng No SQL. Sinubukan nina Pramod Sadalaj at Martin Fowler na igrupo at i-systematize ang kaalaman tungkol sa mundo ng NoSQL sa kanilang kamakailang aklat na "NoSQL Distilled".

2.2 Mga pangunahing katangian ng mga database ng NoSQL

Mayroong ilang mga karaniwang katangian para sa lahat ng NoSQL, dahil maraming mga heterogenous na sistema ang nakatago ngayon sa ilalim ng label na NoSQL (marahil ang pinaka kumpletong listahan ay matatagpuan sa http://nosql-database.org/). Maraming mga katangian ang kakaiba lamang sa ilang mga database ng NoSQL, tiyak na babanggitin ko ito kapag naglilista.

1. Walang ginagamit na SQL

Ang ibig kong sabihin ay ANSI SQL DML, dahil maraming mga database ang sumusubok na gumamit ng mga wika ng query na katulad ng kilalang paboritong syntax, ngunit walang sinuman ang nakapagsagawa ng ganap na pagpapatupad nito at malamang na hindi magtagumpay. Bagama't may mga rumored startup na sinusubukang ipatupad ang SQL, halimbawa sa hadup ( http://www.drawntoscalehq.com/ at http://www.hadapt.com/ ).

2. Hindi nakabalangkas (schemaless)

Ang ibig sabihin ay sa mga database ng NoSQL, hindi tulad ng mga relational database, ang istraktura ng data ay hindi kinokontrol (o mahina ang pag-type, kung gumuhit tayo ng mga pagkakatulad sa mga programming language) - maaari kang magdagdag ng isang arbitrary na patlang sa isang hiwalay na linya o dokumento nang hindi muna deklaratibong binabago ang istraktura ng buong mesa. Kaya, kung may pangangailangan na baguhin ang modelo ng data, ang tanging sapat na aksyon ay upang ipakita ang pagbabago sa code ng aplikasyon.

Halimbawa, kapag pinapalitan ang pangalan ng isang field sa 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"

Kung babaguhin natin ang logic ng application, inaasahan din natin ang isang bagong field kapag nagbabasa. Ngunit dahil sa kakulangan ng schema ng data, nawawala ang field ng totalSum mula sa iba pang umiiral nang Order object. Sa sitwasyong ito, mayroong dalawang opsyon para sa karagdagang pagkilos.

Ang una ay i-crawl ang lahat ng mga dokumento at i-update ang field na ito sa lahat ng umiiral na mga dokumento. Dahil sa dami ng data, ang prosesong ito ay nangyayari nang walang anumang mga kandado (maihahambing sa alter table rename column command), kaya sa panahon ng pag-update, ang mayroon nang data ay maaaring basahin ng ibang mga proseso. Samakatuwid, ang pangalawang pagpipilian - pagsuri sa code ng aplikasyon - ay hindi maiiwasan:

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

At kapag nagre-record kami muli, isusulat namin ang field na ito sa database sa isang bagong format.

Ang isang kaaya-ayang resulta ng kawalan ng isang schema ay ang kahusayan ng pagtatrabaho sa kalat-kalat na data. Kung ang isang dokumento ay may date_published na field, at ang pangalawa ay wala, walang laman na date_published na field ang gagawin para sa pangalawa. Ito, sa prinsipyo, ay lohikal, ngunit ang isang hindi gaanong halatang halimbawa ay ang mga database ng column-family NoSQL, na gumagamit ng mga pamilyar na konsepto ng mga talahanayan / column. Gayunpaman, dahil sa kakulangan ng isang schema, ang mga column ay hindi idineklara nang deklaratibo at maaaring baguhin/idagdag sa panahon ng session ng database ng isang user. Nagbibigay-daan ito, sa partikular, ang paggamit ng mga dynamic na column para sa pagpapatupad ng mga listahan.

Ang unstructured schema ay may mga kakulangan nito - bilang karagdagan sa nabanggit na overhead sa application code kapag binabago ang modelo ng data - ang kawalan ng lahat ng uri ng mga paghihigpit mula sa base (hindi null, unique, check constraint, atbp.), plus doon ay karagdagang mga paghihirap sa pag-unawa at pagkontrol sa data ng istraktura kapag nagtatrabaho sa database ng iba't ibang mga proyekto nang magkatulad (walang mga diksyunaryo sa gilid ng database). Gayunpaman, sa isang mabilis na pagbabago ng modernong mundo, ang gayong kakayahang umangkop ay isang kalamangan pa rin. Ang isang halimbawa ay ang Twitter, na limang taon na ang nakalilipas, kasama ang tweet, ay nag-imbak lamang ng kaunting karagdagang impormasyon (oras, Twitter handle at ilang higit pang mga byte ng meta-impormasyon), ngunit ngayon, bilang karagdagan sa mismong mensahe, ilan pa. kilobytes ng metadata ay naka-imbak sa database.

(Pagkatapos nito, pangunahing pinag-uusapan natin ang tungkol sa mga database ng key-value, dokumento at column-family, maaaring walang mga property na ito ang mga graph database)

2.3. Representasyon ng data sa anyo ng mga pinagsama-sama (aggregates)

Hindi tulad ng relational na modelo, na nag-iimbak ng lohikal na entity ng negosyo ng application sa iba't ibang mga pisikal na talahanayan para sa mga layunin ng normalisasyon, ang mga tindahan ng NoSQL ay nagpapatakbo sa mga entity na ito bilang mga holistic na bagay:

Ang halimbawang ito ay nagpapakita ng mga pagsasama-sama para sa isang karaniwang e-commerce na conceptual relational na modelo na "Order - Order Items - Payments - Product". Sa parehong mga kaso, ang pagkakasunud-sunod ay pinagsama sa mga posisyon sa isang lohikal na bagay, habang ang bawat posisyon ay nag-iimbak ng isang link sa produkto at ilan sa mga katangian nito, halimbawa, ang pangalan (ang naturang denormalization ay kinakailangan upang hindi humiling ng isang bagay ng produkto kapag kinukuha isang order - ang pangunahing tuntunin ng mga distributed system ay "pagsasama" sa pagitan ng mga bagay). Sa isang pinagsama-samang, ang mga pagbabayad ay pinagsama sa pagkakasunud-sunod at isang mahalagang bahagi ng bagay, sa kabilang banda ay inilalagay sila sa isang hiwalay na bagay. Ipinapakita nito ang pangunahing panuntunan para sa pagdidisenyo ng istruktura ng data sa mga database ng NoSQL - dapat itong sumunod sa mga kinakailangan ng application at ma-optimize hangga't maaari para sa pinakamadalas na kahilingan.

Marami ang tututol, na binabanggit na ang pagtatrabaho sa malalaking, madalas na denormalize, mga bagay ay puno ng maraming problema kapag sinusubukan ang mga arbitrary na query sa data kapag ang mga query ay hindi umaangkop sa istruktura ng mga pinagsama-samang. Paano kung gumamit kami ng mga order kasama ng mga item sa linya ng order at mga pagbabayad (ganito gumagana ang app), ngunit hinihiling sa amin ng negosyo na bilangin kung ilang unit ng isang partikular na produkto ang naibenta noong nakaraang buwan? Sa kasong ito, sa halip na i-scan ang talahanayan ng OrderItem (sa kaso ng isang relational na modelo), kakailanganin naming kunin ang buong mga order sa storage ng NoSQL, bagama't hindi namin kakailanganin ang marami sa impormasyong ito. Sa kasamaang palad, ito ay isang kompromiso na kailangang gawin sa isang distributed system: hindi namin ma-normalize ang data tulad ng sa isang conventional single-server system,

Sinubukan kong pangkatin ang mga kalamangan at kahinaan ng parehong mga diskarte sa isang talahanayan: