1.1 Sådan fungerer en NoSQL-database

NoSQL-databaser bruger en række forskellige datamodeller til at få adgang til og manipulere data. Disse typer databaser er optimeret til dataintensive applikationer, der kræver lav latenstid og fleksible datamodeller. Alt dette opnås ved at mildne de strenge datakonsistenskrav, som er typiske for andre typer databaser.

Overvej et eksempel på skemamodellering for en simpel database med bøger.

  • I en relationsdatabase er en bogpost ofte opdelt i flere dele (eller "normaliseret") og gemt i separate tabeller, hvis relationer er defineret af primære og fremmede nøglebegrænsninger. I dette eksempel har tabellen Bøger kolonnerne ISBN , Bogtitel og .ISBN""og"Forfatter"Forfatter-ISBN-, ogForfatternavnogForfatter-idkolonnerneForfattertabellenUdgavenummer. Den relationelle model er designet til at opretholde referentiel integritet mellem tabeller i en database. Dataene er normaliseret for at reducere redundans og er generelt optimeret til lagring.

  • I en NoSQL-database gemmes en bogpost typisk som et JSON-dokument. For hver bog eller element gemmes værdierne for ISBN , bogtitel , udgavenummer , forfatternavn og forfatter-id som attributter i et enkelt dokument. I denne model er dataene optimeret til intuitiv udvikling og horisontal skalerbarhed.

1.2 Hvad kan NoSQL-databaser bruges til?

NoSQL-databaser er velegnede til mange moderne applikationer, såsom mobil, gaming, webapplikationer, der kræver fleksible, skalerbare databaser med høj ydeevne og rig funktionalitet, der kan give maksimal brugervenlighed.

  • Fleksibilitet . Typisk tilbyder NoSQL-databaser fleksible skemaer, der muliggør hurtigere udvikling og muliggør inkrementel implementering. Grundet brugen af ​​fleksible datamodeller er NoSQL-databaser velegnede til semistrukturerede og ustrukturerede data.

  • Skalerbarhed . NoSQL-databaser er designet til at skalere ved hjælp af distribuerede hardwareklynger, ikke ved at tilføje dyre, pålidelige servere. Nogle cloud-tjenesteudbydere kører disse operationer i baggrunden og leverer en fuldt administreret tjeneste.

  • Høj ydeevne . NoSQL-databaser er optimeret til specifikke datamodeller og adgangsmønstre for at opnå højere ydeevne end relationelle databaser.

  • Bred funktionalitet . NoSQL-databaser giver rige API'er og datatyper, der er specifikt designet til deres respektive datamodeller.

Java university

1.3 Typer af NoSQL-databaser

NoSQL-databaser bruges, hvor det ikke er særlig praktisk at gemme data i form af tabeller. Derfor er de gemt i meget forskellige formater. Normalt er der 6 hoveddatatyper af NoSQL-databaser.

DB baseret på nøgle-værdi-par

Databaser, der anvender nøgle-værdi-par, understøtter høj separerbarhed og giver hidtil uset horisontal skalering, der ikke kan opnås med andre typer databaser. Gode ​​use cases for nøgleværdidatabaser er spil-, reklame- og IoT-applikationer.

For eksempel sikrer Amazon DynamoDB stabil databasedrift med en forsinkelse på højst et par millisekunder i enhver skala. Denne robuste ydeevne var hovedårsagen til at migrere Snapchat Stories til DynamoDB, da denne Snapchat-funktion er forbundet med den største lagerbelastning.

Dokument

I applikationskode er data ofte repræsenteret som et objekt eller dokument i et JSON-lignende format, fordi det er en effektiv og intuitiv datamodel for udviklere. Dokumentdatabaser giver udviklere mulighed for at gemme og forespørge data i en database ved hjælp af den samme dokumentmodel, som de bruger i deres applikationskode. Den fleksible, semi-strukturerede, hierarkiske karakter af dokumenter og dokumentdatabaser gør det muligt for dem at udvikle sig med applikationsbehov.

Dokumentmodellen fungerer godt i kataloger, brugerprofiler og indholdsstyringssystemer, hvor hvert dokument er unikt og ændrer sig over tid. Amazon DocumentDB (kompatibel med MongoDB) og MongoDB er almindelige dokumentdatabaser, der giver funktionelle og intuitive API'er til agil udvikling.

Graf databaser

Grafdatabaser gør det nemmere at udvikle og køre applikationer, der arbejder med sæt af komplekse data. Typiske eksempler på brug af grafdatabaser er sociale netværk, anbefalingstjenester, svindeldetektionssystemer og vidensgrafer. Amazon Neptune er en fuldt administreret grafdatabasetjeneste. Neptune understøtter Property Graph and Resource Description Framework (RDF), som giver to graf-API'er at vælge imellem: TinkerPop og RDF/SPARQL. Almindelige grafdatabaser inkluderer Neo4j og Giraph.

DB i hukommelsen

Ofte bruger spil- og reklameapplikationer leaderboards, sessionslagring og realtidsanalyse. Sådanne muligheder kræver et svar inden for få mikrosekunder, mens en kraftig stigning i trafikken er mulig til enhver tid.

Amazon MemoryDB til Redis er en Redis-kompatibel, pålidelig databasetjeneste i hukommelsen, der reducerer læseforsinkelsen til millisekunder og giver holdbarhed på tværs af flere tilgængelighedszoner. MemoryDB er specialbygget til ultrahøj ydeevne og pålidelighed, så den kan bruges som den primære database for moderne mikroservice-baserede applikationer.

Amazon ElastiCache er en fuldt administreret Redis- og Memcached-kompatibel cachingtjeneste i hukommelsen til at betjene arbejdsbelastninger med lav latens og høj gennemløb. Klienter som Tinder, der har brug for, at deres apps reagerer i realtid, bruger in-memory i stedet for disklagringssystemer. Et andet eksempel på et specialbygget datavarehus er Amazon DynamoDB Accelerator (DAX). DAX giver DynamoDB mulighed for at læse data flere gange hurtigere.

Søg i databaser

Mange applikationer genererer logfiler for at gøre det nemmere for udviklere at fejlfinde og løse problemer. Amazon OpenSearch er en specialbygget tjeneste til næsten realtidsvisualisering og analyse af automatisk genererede datastrømme ved at indeksere, aggregere og søge i semistrukturerede logfiler og metrics.

Derudover er Amazon OpenSearch en kraftfuld, højtydende fuldtekstsøgetjeneste. Expedia udnytter over 150 Amazon OpenSearch-tjenestedomæner, 30 TB data og 30 milliarder dokumenter til en række missionskritiske brugssager, fra driftsovervågning og fejlfinding til distribueret applikationsstacksporing og omkostningsoptimering.

1.4 Sammenligning af SQL (relationel) og NoSQL (ikke-relationel) databaser

NoSQL har mange fordele, så du bør i hvert fald i teorien vide, at det værktøj, du skal bruge, allerede eksisterer, før du selv skriver det. Nedenfor vil jeg give en sammenligning af NoSQL og SQL databaser:

Passende arbejdsbelastninger

Relationelle databaser er designet til transaktionelle og meget konsistente OLTP-applikationer (real-time transaktionsbehandling) og er velegnede til real-time analytisk behandling (OLAP).

NoSQL-databaser er designet til at arbejde med en række dataadgangsmønstre, herunder applikationer med lav latenstid. NoSQL-søgedatabaser er designet til analyse af semistrukturerede data.

Data model

Den relationelle model normaliserer data og transformerer dem til tabeller med rækker og kolonner. Et skema definerer strengt tabeller, rækker, kolonner, indekser, relationer mellem tabeller og andre databaseelementer. En sådan database sikrer integriteten af ​​referencedata i relationer mellem tabeller.

NoSQL-databaser giver en række forskellige datamodeller såsom nøgleværdi-par, dokumenter og grafer, der er optimeret til høj ydeevne og skalerbarhed.

SYRE egenskaber

Relationelle databaser giver et sæt ACID-egenskaber: atomicitet, konsistens, isolation, pålidelighed.

  • Atomicitet kræver, at en transaktion udføres i sin helhed eller slet ikke.
  • Konsistens betyder, at så snart en transaktion er gennemført, skal dataene være i overensstemmelse med databaseskemaet.
  • Isolation kræver, at parallelle transaktioner kører adskilt fra hinanden.
  • Pålidelighed refererer til evnen til at gendanne til den sidst gemte tilstand efter et uventet systemfejl eller strømafbrydelse.

NoSQL-databaser tilbyder ofte et kompromis, idet de slækker på de stive krav til ACID-egenskaber til fordel for en mere fleksibel datamodel, der giver mulighed for horisontal skalering. Dette gør NoSQL til et godt valg til brugssager med høj båndbredde og lav latens, der kræver horisontal skalering ud over en enkelt instans.

Ydeevne

Ydeevne afhænger hovedsageligt af diskens undersystem. Optimering af forespørgsler, indekser og tabelstruktur er ofte påkrævet for maksimal ydeevne.

Ydeevne afhænger typisk af størrelsen af ​​den underliggende hardwareklynge, netværksforsinkelse og den kaldende applikation.

Skalering

Relationelle databaser skaleres typisk ved at øge hardwarens computerkraft eller ved at tilføje separate kopier til læsearbejdsbelastninger.

NoSQL-databaser understøtter typisk høj adskillelighed gennem skalerbare adgangsmønstre baseret på en distribueret arkitektur. Dette forbedrer gennemløbet og leverer ensartet ydeevne i næsten ubegrænset skala.

API

Anmodninger om at skrive og hente data skrives i SQL. Disse forespørgsler analyseres og udføres af en relationsdatabase.

Objektorienterede API'er giver applikationsudviklere mulighed for nemt at skrive og hente datastrukturer. Ved hjælp af partitionsnøgler kan applikationer søge i nøgleværdipar, kolonnesæt eller semistrukturerede dokumenter, der indeholder serielle objekter og applikationsattributter.