introduktion

det finns en välkänd datavetenskapssats som föreslagits av Eric Brewer som säger att för en databas med distribuerad data kan du bara lova två av följande tre egenskaper:

• konsistens
• tillgänglighet
• Partitionstolerans

detta är väldigt abstrakt och terminologin är inte exakt intuitiv, så i den här artikeln gör vi vårt bästa för att bryta detta teori ner från abstrakt till mer verkliga prat och exempel. Denna sats kan få dig att tänka på din databasarkitektur när det gäller vad din ansökan verkligen behöver och de uppoffringar det kan behöva göra för att uppnå dem.

definiera CAP terminologi

Låt oss få några grundläggande definitioner ur vägen så att vi kan vara på samma sida när vi går framåt och pratar om denna sats.

CAP-konsistens, tillgänglighet, Partitionstolerans

• konsistens – alla dina dataservrar har samma data, så du kan fråga vilken server som helst i systemet och få exakt samma data.
• tillgänglighet – varje begäran till dataservrarna får ett svar. Om en server är upptagen, det blir dirigeras till en annan som kan svara.
• Partitionstolerans-möjligheten för systemet att fortsätta fungera även om det finns nätverksfel och några av servrarna inte kan kommunicera.

underliggande antagande-P är omöjligt

i ett distribuerat databassystem delas dina data upp över olika servrar och dessa servrar pratar med varandra över ett nätverk så att de kan behålla samma uppsättning data. Problemet är att nätverk bryts och så antar vi att det alltid kommer att kommunicera, dvs vi kan inte ha ett perfekt nätverk. När det gäller denna teori betyder det att i den verkliga världen måste du offra Partitionstolerans. Om det perfekta osvikliga nätverket existerade skulle vi inte ha problem med att uppnå konsistens och tillgänglighet, men det här är den verkliga världen som bygger på fysiska ledningar som misslyckas och så antar vi att det kommer att misslyckas.

om P är omöjligt, Vad är våra val?

eftersom vi har gett upp Partitionstolerans säger satsen att vi nu måste välja mellan konsistens och tillgänglighet.

Du kan välja att ha tillgänglighet där din ansökan kan tillgodose alla inkommande förfrågningar men det kan inte garantera att uppgifterna är de senaste.

Vad behöver din ansökan?

om din ansökan är en webbplats för sociala medier och inte behöver ha den senaste informationen hela tiden kanske du vill välja tillgänglighet. Spelar det någon roll att dina användare ser ett inlägg efter en 30 sekunders fördröjning? Om inte, kanske du föredrar tillgänglighet, eftersom du prioriterar att dina användare kan komma åt data även om det inte är den mest uppdaterade informationen.

om din ansökan å andra sidan kräver att varje läsning till databasen är den absolut senaste informationen måste du offra tillgängligheten och välja konsistens. Vissa förfrågningar måste fel ut på grund av att informationen inte kan garanteras att det är den absolut senaste.

de val som gjorts av Relations – och NoSQL

Databasteknik som SQL och andra relationsdatabassystem utformade med ACID prioriterar konsistens. Å andra sidan prioriterar de flesta NoSQL-databaser tillgänglighet.

slutsats

Vi tror att det är en utmärkt övning att undersöka denna sats när det gäller din ansökan och hjälper dig att utvärdera prioriteringarna för din ansökan. Om du har ett distribuerat datasystem, undersök din arkitektur och förstå vilket offer du gör. MongoDB, CockroachDB och Postgres är alla bra databasteknik idag som gör våra databasarkitekturer extremt robusta men som vi diskuterade är de inte perfekta. Vi har inget perfekt nätverk och det finns alltid ”användarfel”. Om du flyttar till en produktionsmiljö och vill diskutera de bästa alternativen för din ansökan, tveka inte att kontakta oss på Object Rocket.