Inleiding

Er is een bekende computer science stelling voorgesteld door Eric Brewer dat zegt voor een database met gedistribueerde gegevens kunt u alleen beloven twee van de volgende drie eigenschappen:

• Samenhang
• Beschikbaarheid
• Partitie tolerantie

Dit is heel abstract en de terminologie is niet precies intuïtieve dus in dit artikel zullen we ons best doen om dit te breken theorie van abstract naar meer echte wereld praten en voorbeelden. Deze stelling kan u doen nadenken over uw database architectuur in termen van wat uw toepassing echt nodig heeft en de offers die het zou kunnen hebben om die te bereiken.

Defining Cap Terminology

laten we een aantal basisdefinities uit de weg halen zodat we op dezelfde pagina kunnen zitten als we verder gaan met praten over deze stelling.

CAP – consistentie, beschikbaarheid, Partitietolerantie

• consistentie – al uw gegevensservers hebben dezelfde gegevens, dus u kunt elke server in het systeem opvragen en exact dezelfde gegevens krijgen.
• beschikbaarheid-elk verzoek aan de dataservers krijgt een antwoord. Als een server bezet is, wordt deze doorgestuurd naar een andere server die kan reageren.
• Partitietolerantie – de mogelijkheid voor het systeem om te blijven werken, zelfs als er netwerkstoringen zijn en sommige servers niet kunnen communiceren.

onderliggende aanname – P is onmogelijk

in een gedistribueerd databasesysteem worden uw gegevens verdeeld over verschillende servers en deze servers praten met elkaar over een netwerk zodat ze dezelfde set gegevens kunnen behouden. Het probleem is dat netwerken breken en dus gaan we ervan uit dat het altijd zal communiceren, dat wil zeggen we kunnen geen perfect netwerk hebben. In termen van deze theorie betekent dat dat je in de echte wereld partitie tolerantie moet opofferen. Als het perfecte, onfeilbare netwerk zou bestaan dan zouden we geen probleem hebben om consistentie en beschikbaarheid te bereiken, maar dit is de echte wereld gebouwd op fysieke draden die falen en dus gaan we ervan uit dat het zal falen.

Als P onmogelijk is, wat zijn onze keuzes?

omdat we Partitietolerantie hebben opgegeven, zegt de stelling dat we nu moeten kiezen tussen consistentie en beschikbaarheid.

U kunt ervoor kiezen om beschikbaarheid te hebben waar uw toepassing aan alle inkomende verzoeken kan voldoen, maar het kan niet garanderen dat de gegevens de meest recente zijn.

wat heeft uw toepassing nodig?

als uw toepassing een social media site is en niet altijd de meest recente gegevens nodig heeft, dan kunt u de beschikbaarheid kiezen. Maakt het uit dat uw gebruikers een bericht ziet na een vertraging van 30 seconden? Zo niet, dan kunt u de voorkeur geven aan beschikbaarheid, omdat u prioriteit geeft aan dat uw gebruikers toegang hebben tot gegevens, zelfs als het niet de meest up-to-date gegevens zijn.

als aan de andere kant uw toepassing vereist dat elke lezing van de database de absolute meest recente gegevens zijn, dan zult u Beschikbaarheid moeten opofferen en consistentie moeten kiezen. Sommige verzoeken zullen moeten fout uit te wijten aan de informatie niet kunnen worden gegarandeerd dat het de absolute meest recente.

de keuzes gemaakt door relationele en NoSQL

databasetechnologie zoals SQL en andere relationele databasesystemen ontworpen met ACID prioriteit consistentie. Aan de andere kant geven de meeste NoSQL databases prioriteit aan beschikbaarheid.

conclusie

wij geloven dat het onderzoeken van deze stelling in termen van uw toepassing een uitstekende oefening is en U helpt om de prioriteiten van uw toepassing te evalueren. Als je een gedistribueerd datasysteem hebt, onderzoek dan je architectuur en begrijp welke opoffering je maakt.

MongoDB, CockroachDB en Postgres zijn vandaag de dag allemaal geweldige databasetechnologie die onze databasearchitecturen extreem robuust maken, maar zoals we besproken hebben zijn ze niet perfect. We hebben geen perfect netwerk en er is altijd “user error”. Als u naar een productieomgeving verhuist en de beste opties voor uw toepassing wilt bespreken, aarzel dan niet om contact met ons op te nemen bij Object Rocket.