introduktion

der er en velkendt Datalogisk sætning foreslået af Eric brygger, der siger for en database med distribuerede data, at du kun kan love to ud af følgende tre kvaliteter:

• konsistens
• tilgængelighed
• Partitionstolerance

Dette er meget abstrakt, og terminologien er ikke ligefrem intuitiv, så i denne artikel vil vi gøre vores bedste for at bryde denne teori ned fra abstrakt til mere virkelige verden snak og eksempler. Denne sætning kan få dig til at tænke over din databasearkitektur med hensyn til, hvad din applikation virkelig har brug for, og de ofre, den måtte have for at opnå dem.

definition af CAP-terminologi

lad os få nogle grundlæggende definitioner ud af vejen, så vi kan være på samme side, når vi bevæger os fremad og taler om denne sætning.

CAP-konsistens, tilgængelighed, Partitionstolerance

• konsistens – alle dine dataservere har de samme data, så du kan forespørge enhver server i systemet og få nøjagtigt de samme data.
• tilgængelighed-hver anmodning til dataserverne får et svar. Hvis en server er optaget, bliver den dirigeret til en anden, der er i stand til at reagere.
• Partitionstolerance-systemets evne til at fortsætte med at arbejde, selvom der er netværksfejl, og nogle af serverne ikke kan kommunikere.

underliggende antagelse – P er umuligt

i et distribueret databasesystem opdeles dine data over forskellige servere, og disse servere taler med hinanden over et netværk, så de kan opretholde det samme sæt data. Problemet er, at netværk går i stykker, og så antager vi, at det altid vil kommunikere, dvs.vi kan ikke have et perfekt netværk. Med hensyn til denne teori betyder det, at du i den virkelige verden er nødt til at ofre Partitionstolerance. Hvis det perfekte aldrig svigtende netværk eksisterede, ville vi ikke have et problem med at opnå konsistens og tilgængelighed, men dette er den virkelige verden bygget på fysiske ledninger, der mislykkes, og derfor antager vi, at det vil mislykkes.

hvis P er umuligt, Hvad er vores valg?

da vi har opgivet Partitionstolerance, siger sætningen, at vi nu skal vælge mellem konsistens og tilgængelighed.

Du kan vælge at have tilgængelighed, hvor din ansøgning kan tilfredsstille alle indgående anmodninger, men det kan ikke garantere, at dataene er de seneste.

hvad har din ansøgning brug for?

Hvis din applikation er et socialt medieside og ikke behøver at have de nyeste data til enhver tid, kan du vælge tilgængelighed. Betyder det noget, at dine brugere ser et indlæg efter en 30 sekunders forsinkelse? Hvis ikke, foretrækker du muligvis tilgængelighed, fordi du prioriterer, at dine brugere kan få adgang til data, selvom det ikke er de mest opdaterede data.

Hvis din ansøgning på den anden side kræver, at hver læsning til databasen er de absolut seneste data, skal du ofre tilgængelighed og vælge konsistens. Nogle anmodninger bliver nødt til at fejle på grund af, at oplysningerne ikke kan garanteres, at det er den absolut seneste.

De valg, der foretages af relationel og Noskl

databaseteknologi som f.eks. På den anden side prioriterer de fleste noskl-databaser tilgængelighed.

konklusion

Vi mener, at det er en fremragende øvelse at undersøge denne sætning med hensyn til din ansøgning og hjælper dig med at evaluere prioriteterne i din ansøgning. Hvis du har et distribueret datasystem, skal du undersøge din arkitektur og forstå, hvilket offer du ofrer. MongoDB, Kakerlakdb og Postgres er alle gode databaseteknologier i dag, der gør vores databasearkitekturer ekstremt robuste, men som vi diskuterede, er de ikke perfekte. Vi har ikke noget perfekt netværk, og der er altid “brugerfejl”. Hvis du flytter til et produktionsmiljø og ønsker at diskutere de bedste muligheder for din ansøgning, så tøv ikke med at kontakte os på Object Rocket.