NoSQL-i andmebaaside põhitõed - ja miks me neid vajame

Algaja juhend NoSQL-i maailmast

Andmete korrastamine on väga keeruline ülesanne. Kui me ütleme korraldama, siis kategoriseerime asjad tegelikult selle tüübi ja funktsiooni järgi.

Üks võimalus on, et RDBMS on nagu Exceli leht - liigitate andmed tabelite kujul. Tabelite vahel saate luua seoseid.

Päringu küsimustele andmebaasi, mis annab teile asjakohane vastus tagasi. See päringukeel on SQL või struktureeritud päringukeel.

Näiteks,

select * from Employee_Data;

valib tabelist Töötaja_andmed kõik töötaja andmed.

Relatsioonandmebaasid järgivad skeemi , mis on teie tabelite töö üksikasjalik plaan.

Kasutate Amazoni, Facebooki ja nii palju võrgurakendusi. Nad väljastavad värskendusi, lisavad uusi funktsioone ja isegi lisamooduleid. Kuidas siis skeemi iga kord muuta? Kas pole nii aeganõudev, et nii suured ettevõtted pühendaksid oma aja ja tööjõu skeemi muutmisele?

Siin ei saanud SQL töötada .

RDBMSi miinused

Relatsioonandmebaasid pole nii halvad, kui inimesed tänapäeval kujutavad. Neid kasutavad endiselt paljud organisatsioonid. NoSQLi lisamine pildile on nende ruumide täitmine, kus RDBMS-i enam kasutada ei saa.

Näitan teile näiteid, et teil oleks selge arusaam.

1. RDBMS ei saa hakkama andmesordiga.

Struktureerimata andmete hulk kasvab igal aastal jätkuvalt ja nende haldamine on keeruline. RDBMS ei saa sundida igat tüüpi andmeid ühtse tabeliskeemi alla.

Andmehoidlad on ka arendajate probleem.

Tech Targeti andmetel on andmekogu andmete hoidla, mis jääb ühe osakonna kontrolli alla. See on ülejäänud organisatsioonist eraldatud.

See tähendab, et kui samade andmete jaoks on olemas rohkem silohoidlaid, on nende sisu tõenäoliselt erinev. See tekitab segadust, milline hoidla esindab kõige ajakohasemat versiooni.

Andmete kasv aastatel 2013–2020 on nähtav alloleval pildil.

2020. aastal luuakse umbes 44 beeta-baiti andmeid.

Selliste mitmekesiste andmete käsitlemine, mis pole omavahel seotud, võib RDBMS-is olla palju raskem.

Näide: Raske on salvestada patsiendi üksikasju, kellel on erinevad kehaolud. Nii mitmekesiste andmete kategoriseerimine on RDBMS-is keeruline.

2. Tabelite ja seoste muutmine on keeruline.

Tabelite vaheliste seoste muutmine või uue tabeli lisamine võib mõjutada olemasolevaid seoseid. See tähendab skeemi muutmist.

Skeemi muutmine oleks nagu olemasoleva kõrvaldamine ja uue skeemi väljatöötamine.

Uue funktsionaalsuse lisamiseks oleks uue struktuuri toetamiseks vaja kõiki elemente. Muutused on vältimatud.

Näide: Igal lisaveerul on vaja kõiki eelnevaid ridu, et sellel veerul oleks väärtused. Arvestades, Cassandra (a NoSQL andmebaas), saate lisada veeru konkreetse rea vaheseinad.

3. RDBMS järgib andmebaasi ACID omadusi.

Andmebaasi ACID omadused on aatom, konsistents, eraldatus ja vastupidavus. ‌

Aatomilisus - lähenemine "kõik või mitte midagi". Kui mõni tehingu lause ebaõnnestub, lükatakse kogu tehing tagasi.

Järjepidevus - tehing peab vastama kõigile süsteemi määratletud protokollidele. Pooleldi lõpetatud tehinguid pole.

Isolatsioon - ühelgi tehingul pole juurdepääsu muudele tehingutele, mis on vahe- või lõpetamata olekus. Iga tehing on sõltumatu.

Vastupidavus - tagab, et kui tehing on andmebaasi sidunud, säilitatakse see varukoopiate ja tehingute logide abil.

ACID omadused pole paindlikud.

Näiteks RDBMS järgmiselt normaliseerimine või üksainus tõde mõiste. Iga teie tehtud muudatuse korral peaksite tagama ranged happe omadused. Samuti kehtivad üksuse terviklikkuse ja viitamise terviklikkuse reeglid.

ÜPP teoreem

Vikipeedia andmetel on CAP-i teoreemis (Breweri teoreem) öeldud, et hajutatud andmesalvestusel on võimatu pakkuda üheaegselt rohkem kui kahte järgmistest kolmest garantiist:

Järjepidevus: nagu C happes.

Kättesaadavus : ‌Ressursid peaksid olema alati saadaval. Vastus peaks olema mitte vea.

Jaotustolerants : rikke pole ühte punkti (või sõlme).

Kõiki kolme tingimust on raske saavutada. Nende kolme vahel tuleb teha kompromisse.

ALUS päästmiseks!

‌NoSQL tugineb pehmemale mudelile, mida nimetatakse BASE mudeliks. ALUS ( B asically A vaable , S of state, E ventual konsistents).

Põhimõtteliselt saadaval: tagab andmete kättesaadavuse. Igale taotlusele vastatakse (võib ka ebaõnnestuda).

Pehme olek : süsteemi olek võib aja jooksul muutuda.

Lõplik järjepidevus: süsteem muutub lõpuks järjekindlaks, kui see lõpetab sisendi saamise.

NoSQL-i andmebaasid loobuvad A-, C- ja / või D-nõuetest ning vastutasuks parandavad need mastaapsust.

NoSQL

See oli siis, kui NoSQL tuli appi. ‌ See on " Mitte ainult SQL" või "Mitte-relatsiooniline" andmebaasid.

NoSQL-i omadused:

  • Skeem tasuta
  • Lõpuks järjepidev (nagu atribuudis BASE)
  • Andmehoidlate kopeerimine, et vältida ühte ebaõnnestumispunkti.
  • Saab hakkama andmete mitmekesisuse ja tohutute andmehulkadega.

NoSQL-i andmebaaside tüübid

NoSQL-i andmebaasid jagunevad nelja põhikategooriasse:

Põhiväärtusega kauplused - Riak, Voldemort ja Redis

Laiad veerupoed - Cassandra ja HBase.

Dokumendi andmebaasid - MongoDB

Graafikute andmebaasid - Neo4J ja HyperGraphDB.

Paremal küljel olevad sõnad on näited NoSQL-i andmebaasitüüpide tüüpidest.

1. Põhiväärtuste kauplused

Võtmeväärtuste pood kasutab räsitabelit , milles on olemas unikaalne võti ja osuti kindlale andmeelemendile.

Kujutage ette, et põhiväärtuste salvestused on nagu telefonikataloog, kus üksikisiku nimed ja nende numbrid on kaardistatud.

Võtmeväärtuse poodidel pole vaikepäringu keelt. Andmete hankimiseks kasutage käske get, put ja delete . See on põhjus, miks sellel on kõrge jõudlus.

Rakendused : kasulik kommentaaride ja seansiteabe salvestamiseks. ‌Pinterest kasutab Redist kasutajate, jälgijate, jälgijate, tahvlite loendite salvestamiseks.

2. Laiad veeruhoidlad

Veergude poe andmebaasis on iga rea ​​veerud selles reas.

Iga veerg pere on konteiner ridade ühes RDBMS tabelis. Võti tuvastab koosnev rida mitu veergu.

Ridadel ei pea olema sama arv veerge. Veerusid saab igal ajal lisada igale reale, ilma et peaksite seda teistele ridadele lisama. See on jaotatud reapood.

Kuidas veeruline andmebaas andmeid salvestab?

Rakendused : Spotify kasutab Cassandrat kasutajaprofiili atribuutide ja metaandmete salvestamiseks.

3. Dokumendi andmebaasid

‌Dokumentide salvestused kasutavad andmete salvestamiseks JSON-, XML- või BSON-dokumente (JSON-i binaarkodeering).

See on nagu võtmeväärtuste andmebaas, kuid dokumendihoidla koosneb poolstruktureeritud andmetest .

Üks dokument on kirjete ja selle andmete salvestamine.

‌See ei toeta suhteid ega liitu.

Kui soovime salvestada kliendi üksikasjad ja nende tellimused, saame selleks kasutada dokumendipoode.

Rakendused: SEGAkasutab MongoDB-d 11 miljoni MongoDB-le loodud mängusisese konto haldamiseks.

4. Graafige andmebaasid

‌Sõlmed ja seosed on graafide andmebaaside olulised koostisosad. Tipule üksuse. Suhe näitab, kui kahe sõlme seostatakse.

RD RDBMS-is toob teise seose lisamine kaasa palju skeemi muudatusi.

Graafikute andmebaas nõuab andmete salvestamist ainult üks kord (sõlmed). Eri tüüpi suhted (servad) määratakse salvestatud andmetele.

Sõlmedevahelised suhted on eelnevalt kindlaks määratud, see tähendab, et seda ei määrata päringu ajal.

Püsivate suhete läbimine on kiirem.

Kahe sõlme vahelist suhet on raske muuta. Selle tulemuseks oleks regressiivsed muudatused andmebaasis.

Näide : See pilt töötab MySQL-is, kus Alice'i jaoks õige tulemuse leidmiseks peab ta tegema palju toiminguid.

Graaf andmebaas , mis eelmääratletud suhteid.

See on osa põhiteavet, mida peate NoSQL-i uurimiseks alustama. Spetsiifiliseks kasutamiseks leiutatakse uusi andmebaase.

Vaadake, mis tüüpi andmeid teie rakendus genereerib, ja siis on õige andmebaasi valimine lihtne.

Kirjutan lugusid elutundidest, kodeerimisest ja tehnoloogiast. Lisateabe saamiseks jälgige mind Twitteris ja Mediumis.