Innledning
Det er en velkjent informatikk teorem foreslått Av Eric Brewer som sier for en database med distribuerte data kan du bare love to av følgende tre kvaliteter:
Konsistens
dette er veldig abstrakt og terminologien er ikke akkurat intuitivt så i denne artikkelen vil vi gjøre vårt beste for å bryte dette.teori NED Fra Abstrakt Til Mer Virkelige verden snakk og eksempler. Denne teoremet kan få deg til å tenke på databasearkitekturen din når det gjelder hva søknaden din virkelig trenger og de ofrene det må gjøre for å oppnå dem.
Definere CAP Terminologi
La oss få noen grunnleggende definisjoner ut av veien slik at vi kan være på samme side som vi går videre og snakker om denne setningen.
CAP – Konsistens, Tilgjengelighet, Partisjonstoleranse
- Konsistens – alle dine dataservere har de samme dataene, slik at du kan spørre hvilken som helst server i systemet og få nøyaktig samme data.
- Tilgjengelighet – hver forespørsel til dataserverne får svar. Hvis en server er opptatt, blir den rutet til en annen som kan svare.Partisjonstoleranse-muligheten for at systemet fortsetter å fungere selv om det er nettverksfeil og noen av serverne ikke kan kommunisere.
Underliggende Antagelse-P Er Umulig
i et distribuert databasesystem deles dataene dine opp over forskjellige servere, og disse serverne snakker med hverandre over et nettverk slik at de kan opprettholde det samme datasettet. Problemet er at nettverk bryter og så antar vi at det alltid vil kommunisere, det vil si at vi ikke kan ha et perfekt nettverk. Når det gjelder denne teorien, betyr det at i den virkelige verden må du ofre Partisjonstoleranse. Hvis det perfekte ufeilbare nettverket eksisterte, ville vi ikke ha et problem å oppnå Konsistens og Tilgjengelighet, men dette er den virkelige verden bygget på fysiske ledninger som feiler, og så antar vi at det vil mislykkes.
Hvis P Er Umulig, Hva Er Våre Valg?
siden vi har gitt Opp Partisjonstoleranse, sier teoremet at vi nå må velge Mellom Konsistens og Tilgjengelighet.
du kan velge Å Ha Tilgjengelighet der søknaden din kan tilfredsstille alle innkommende forespørsler, men det kan ikke garantere at dataene er de nyeste.
hva trenger søknaden din?
hvis søknaden din er et sosialt medieområde og ikke trenger å ha de nyeste dataene til enhver tid, kan Det være Lurt å velge Tilgjengelighet. Betyr det noe at brukerne ser et innlegg etter en 30 sekunders forsinkelse? Hvis ikke, kan Du foretrekke Tilgjengelighet, fordi du prioriterer at brukerne kan få tilgang til data selv om det ikke er de mest oppdaterte dataene.
hvis derimot søknaden din krever at hver lesning til databasen er de absolutt nyeste dataene, må du ofre Tilgjengelighet og velge Konsistens. Noen forespørsler må feil ut på grunn av at informasjonen ikke kan garanteres at den er den absolutt nyeste.
Valgene Gjort Av Relasjonelle Og NoSQL
Databaseteknologi som SQL og andre relasjonsdatabasesystemer designet MED SYRE prioriterer Konsistens. På Den Annen side prioriterer De Fleste nosql-databaser Tilgjengelighet.
Konklusjon
vi tror at å undersøke denne setningen når det gjelder søknaden din, er en utmerket øvelse og hjelper deg med å evaluere prioriteringene i søknaden din. Hvis du har et distribuert datasystem, undersøk arkitekturen din og forstå hvilket offer du gjør. MongoDB, CockroachDB og Postgres er alle gode databaseteknologi i dag som gjør databasearkitekturene våre ekstremt robuste, men som vi diskuterte, er de ikke perfekte. Vi har ingen perfekt nettverk, og det er alltid «brukerfeil». Hvis du flytter til et produksjonsmiljø og ønsker å diskutere de beste alternativene for søknaden din, ikke nøl med å nå ut til Oss På Object Rocket.
