Grundlæggende om NoSQL-databaser - og hvorfor vi har brug for dem

En begynderguide til NoSQL-verdenen

Organisering af data er en meget vanskelig opgave. Når vi siger organisere, kategoriserer vi faktisk ting afhængigt af dens type og funktion.

En mulighed er, at RDBMS er som et Excel-ark - du kategoriserer data i form af tabeller. Du kan danne relationer mellem tabellerne.

En forespørgsel sætter spørgsmålstegn ved databasen, hvilket giver dig et relevant svar til gengæld. Dette forespørgselssprog er SQL eller Structured Query Language.

For eksempel,

select * from Employee_Data;

vælger alle medarbejderdata fra tabellen Employee_Data.

Relationsdatabaser følger et skema , en detaljeret plan for, hvordan dine tabeller fungerer.

Du bruger Amazon, Facebook og så mange netværksapplikationer. De frigiver opdateringer, tilføjer nye funktioner og endda ekstra moduler. Så hvordan ændrer man skemaet hver gang? Er det ikke tidskrævende for så store virksomheder at bruge deres tid og arbejde på at ændre skemaet?

Det er her, SQL ikke kunne fungere .

Ulemperne ved RDBMS

Relationsdatabaser er ikke så dårlige som folk skildrer i disse dage. De er stadig i brug af mange organisationer. Introduktionen af ​​NoSQL i billedet er at udfylde de rum, hvor RDBMS ikke længere kan bruges.

Jeg vil vise dig eksempler, så du har en klar forståelse.

1. RDBMS kan ikke håndtere 'Data Variety'.

Mængden af ​​ustrukturerede data stiger fortsat årligt, og det er svært at administrere dem. RDBMS kan ikke tvinge alle typer data under et samlet skema med tabeller.

Datasiloer er også et problem for udviklere.

Ifølge Tech Target er en datasilo et lager af data, der forbliver under kontrol af en afdeling. Det er isoleret fra resten af ​​organisationen.

Dette betyder, at når der findes flere siloer til de samme data, vil deres indhold sandsynligvis variere. Det skaber forvirring, hvor lageret repræsenterer den mest opdaterede version.

Forøgelsen af ​​data fra året 2013 til 2020 kan ses på nedenstående billede.

Omkring 44 Zeta-byte data genereres i år 2020.

Håndtering af så forskellige data, som ikke er relateret til hinanden, kan være meget sværere i RDBMS.

Eksempel: Det er svært at gemme detaljerne hos en patient, der har forskellige kropsforhold. Kategorisering af så forskellige data er vanskelig i RDBMS.

2. Vanskeligt at ændre tabeller og relationer.

Ændring af forholdet mellem tabeller eller tilføjelse af en ny tabel kan påvirke de eksisterende relationer. Dette betyder at ændre skemaet.

Ændring af skemaet ville være som at fjerne det eksisterende og udtænke et nyt skema.

Tilføjelse af en ny funktionalitet vil have brug for alle elementerne til at understøtte den nye struktur. Ændring er uundgåelig.

Eksempel: Hver ekstra kolonne har brug for alle de foregående rækker for at have værdier for den pågældende kolonne. Mens du i Cassandra (en NoSQL-database) kan du tilføje en kolonne til specifikke rækkepartitioner.

3. RDBMS følger ACID-egenskaberne i databasen.

ACID-egenskaberne i en database er Atomicitet, Konsistens, Isolering og Holdbarhed. ‌

Atomicitet - En "alt eller intet" tilgang. Hvis en erklæring i transaktionen mislykkes, rulles hele transaktionen tilbage.

Konsistens - Transaktionen skal opfylde alle protokoller, der er defineret af systemet. Ingen halvdelen gennemførte transaktioner.

Isolering - Ingen transaktion har adgang til andre transaktioner, der er i en mellemliggende eller ufærdig tilstand. Hver transaktion er uafhængig.

Holdbarhed - Sikrer, at når en transaktion forpligter sig til databasen, bevares den ved hjælp af sikkerhedskopier og transaktionslogfiler.

ACID-egenskaberne er ikke fleksible.

For eksempel følger RDBMS normalisering eller et enkelt sandhedskoncept . For hver ændring, du foretager, skal du sikre strenge ACID-egenskaber. Reglerne for enhedens integritet og henvisningsintegritet gælder også.

CAP-sætningen

Ifølge Wikipedia siger CAP-sætningen (Brewer's sætning), at det er umuligt for en distribueret datalager at give mere end to ud af følgende tre garantier samtidigt:

Konsistens: Ligesom C i ACID.

Tilgængelighed : ‌Ressourcer skal altid være tilgængelige. Der skal være et ikke-fejlsvar.

Partitionstolerance : Intet enkelt punkt (eller knudepunkt) for fejl.

Det er vanskeligt at nå alle de tre betingelser. Man skal gå på kompromis mellem de tre.

BASE til undsætning!

ONoSQL er afhængig af en blødere model kendt som BASE-modellen. BASE ( B asically A vailable , S oft state, E ventual consistency).

Grundlæggende tilgængelig: Garanterer tilgængeligheden af ​​dataene. Der vil være et svar på enhver anmodning (kan også mislykkes).

Blød tilstand : Systemets tilstand kan ændre sig over tid.

Eventuel konsistens: Systemet bliver til sidst konsistent, når det stopper med at modtage input.

NoSQL-databaser opgiver kravene til A, C og / eller D, og ​​til gengæld forbedrer de skalerbarheden.

NoSQL

Det var, da NoSQL kom til undsætning. Det er " ikke kun SQL" eller "ikke-relationelle" databaser.

Karakteristik af NoSQL:

  • Skema gratis
  • Til sidst konsekvent (som i BASE-ejendommen)
  • Replikering af datalagre for at undgå enkelt fejlpunkt.
  • Kan håndtere datasortiment og enorme mængder data.

Typer af NoSQL-databaser

NoSQL-databaser falder i fire hovedkategorier:

Nøgleværdibutikker - Riak, Voldemort og Redis

Brede søjleforretninger - Cassandra og HBase.

Dokumentdatabaser - MongoDB

Graph databaser - Neo4J og HyperGraphDB.

Ordene til højre er eksempler på typerne af NoSQL-databasetyper.

1. Nøgleværdibutikker

En nøgleværdilager bruger en hash-tabel , hvor der findes en unik nøgle og en markør til et bestemt dataelement.

Forestil dig, at nøgleværdilagre skal være som et telefonkatalog, hvor personens navne og deres numre kortlægges sammen.

Nøgleværdibutikker har intet standardforespørgselssprog. Du henter data ved hjælp af get, put og slet kommandoer. Dette er grunden til, at det har høj ydeevne.

Anvendelser : Nyttig til opbevaring af kommentarer og sessionoplysninger. ‌Pinterest bruger Redis til at gemme lister over brugere, tilhængere, unfollowers, boards.

2. Brede søjleforretninger

I en kolonnelagerdatabase er kolonnerne i hver række indeholdt i den række.

Hver kolonnefamilie er en beholder med rækker i en RDBMS-tabel. Den centrale identificerer rækken, der består af flere kolonner.

Rækker behøver ikke at have det samme antal kolonner. Kolonner kan når som helst føjes til en række uden at skulle tilføje den til andre rækker. Det er en opdelt rækkeforretning.

Hvordan lagrer en søjledatabase data?

Applikationer : Spotify bruger Cassandra til at gemme brugerprofilattributter og metadata.

3. Dokumentdatabaser

StoresDokumentbutikker bruger JSON-, XML- eller BSON-dokumenter (binær kodning af JSON) til at gemme data.

Det er som en database med nøgleværdier, men et dokumentlager består af semistrukturerede data .

Et enkelt dokument skal gemme poster og dets data.

Det understøtter ikke relationer eller slutter sig.

Hvis vi vil gemme kundeoplysningerne og deres ordrer, kan vi bruge dokumentforretninger til at gøre det.

Applikationer: SEGAbruger MongoDB til håndtering af 11 millioner in-game konti bygget på MongoDB.

4. Grafdatabaser

OdesNoder og relationer er de væsentlige bestanddele i grafdatabaser. En node repræsenterer en enhed. Et forhold repræsenterer, hvordan to noder er knyttet.

‌I RDBMS resulterer tilføjelse af en anden relation i mange skemaændringer.

Grafdatabase kræver kun lagring af data én gang (noder). De forskellige typer forhold (kanter) er specificeret til de lagrede data.

Forholdet mellem noderne er forudbestemt, det vil sige, det bestemmes ikke på forespørgselstidspunktet.

At krydse vedvarende forhold er hurtigere.

Det er vanskeligt at ændre et forhold mellem to noder. Det ville resultere i regressive ændringer i databasen.

Eksempel : Dette billede er, hvordan MySQL fungerer, hvor det skal udføre mange operationer for at finde et korrekt resultat for Alice.

En grafdatabase , som forudbestemmer relationer.

Dette er nogle af de grundlæggende oplysninger, du har brug for for at begynde at udforske NoSQL. Nye databaser opfindes til specifikke anvendelser.

Lær, hvilken type data din applikation genererer, og så er det let at vælge den rigtige database.

Jeg skriver historier om livslektioner, kodning og teknologi. For at læse mere, følg mig på Twitter og Medium.