In het verleden, toen we eenmaal meer data wilden opslaan of onze rekenkracht wilden vergroten, was de gebruikelijke optie om verticaal te schalen (krachtigere machines te krijgen) of de heersende codebasis verder te optimaliseren. Echter, met de vooruitgang in multiprocessing en gedistribueerde systemen is het gebruikelijker om horizontaal uit te breiden, of meer machines te hebben om te proberen een gelijkwaardige taak parallel uit te voeren. We zullen al een heleboel kennismanipulatie tools zien binnen het Apache project zoals Spark, Hadoop, Kafka, Zookeeper en Storm. Echter, om effectief de tool van keuze te kunnen kiezen, is een basisidee van CAP Theorem belangrijk. CAP stelling kan een concept zijn dat een gedistribueerd database systeem slechts 2 van de 3 kan hebben: Consistentie, Beschikbaarheid en Partition Tolerantie.

https://miro.medium.com/max/400/1*WPnv_6sG9k4oG3S1A09MDA.jpeg

De CAP stelling is uiterst belangrijk binnen de Big Data wereld, zeker als we eenmaal de afweging hebben gemaakt tussen de drie, ondersteunde onze unieke use case. Op deze blog kan ik proberen elk van deze concepten en dus de redenen voor de trade off uit te leggen. Ik zal in staat zijn om het gebruik van specifieke voorbeelden te vermijden, aangezien DBMS snel evolueert.

Verdelingstolerantie

https://miro.medium.com/max/731/1*qVoJNWH1osbrnOizRivF1A.png

Deze voorwaarde houdt in dat het systeem blijft draaien, ondanks de hoeveelheid berichten die door het netwerk tussen de knooppunten worden vertraagd. Een systeem dat partitietolerant is, kan elke hoeveelheid netwerkstoring aanhouden die niet eindigt in een storing van het hele netwerk. Datarecords worden voldoende gerepliceerd over combinaties van knooppunten en netwerken om het systeem overeind te houden door intermitterende uitval. Bij het omgaan met moderne gedistribueerde systemen is Partition Tolerantie geen optie. Het is een noodzaak. Daarom moeten we handelen tussen Consistentie en Beschikbaarheid.

Hoge Consistentie

https://miro.medium.com/max/864/1*UnG2G7_h0kqI9IHtnUk3qg.png

Deze voorwaarde houdt in dat elk van de knooppunten op een gelijkwaardig tijdstip een gelijkwaardig gegeven te zien krijgt. Simpel gezegd, het uitvoeren van een leesoperatie zal de waarde van de meest recente schrijfoperatie teruggeven, waardoor alle knooppunten een gelijkwaardige data zullen teruggeven. Een systeem heeft consistentie als een transactie begint met het systeem in een consistente toestand en eindigt met het systeem in een consistente toestand. Tijdens dit model kan een systeem tijdens een transactie naar een inconsistente toestand verschuiven (en doet dat ook), maar de hele transactie wordt teruggerold als er een fout wordt gemaakt tijdens een willekeurige fase in het proces. Binnen het beeld hebben we 2 verschillende records (“Bulbasaurus” en “Pikachu”) op verschillende tijdstempels. De uitgang op de derde partitie is “Pikachu”, de nieuwste invoer. De knooppunten hebben echter tijd nodig om te updaten en kunnen niet zo vaak op het netwerk beschikbaar zijn.

Hoge beschikbaarheid

https://miro.medium.com/max/841/1*ABrjUrZAY6V1hEkFPYvC7A.png

Deze voorwaarde houdt in dat elk verzoek een antwoord krijgt op succes/faillissement. Het bereiken van beschikbaarheid tijdens een gedistribueerd systeem vereist dat het systeem 100% van de tijd operationeel blijft. Elke klant krijgt een antwoord, ongeacht de status van een persoonsknooppunt binnen het systeem. Deze metriek is triviaal om te meten: ofwel dien je lees/schrijf-commando’s in, anders kan je dat niet. De databases zijn dus tijdonafhankelijk omdat de nodes in de minste gevallen online beschikbaar moeten zijn. Dit suggereert dat, in tegenstelling tot het vorige voorbeeld, we niet weten of “Pikachu” of “Bulbasaurus” als eerste is toegevoegd. De uitvoer zou een van beide kunnen zijn. Daarom is een hoge beschikbaarheid niet haalbaar bij het analyseren van streaming data met hoge frequentie.

Conclusie

Gedistribueerde systemen stellen ons in staat om een niveau van rekenkracht en beschikbaarheid te realiseren dat in het verleden eenvoudigweg niet beschikbaar was. Onze systemen hebben hogere prestaties, lagere latency en bijna 100% up-time in datacenters die zich over de hele wereld uitstrekken. Beter nog, de systemen van vandaag de dag draaien op commodity-hardware die gemakkelijk te verkrijgen en te configureren is tegen betaalbare kosten. Er is echter een prijs. Gedistribueerde systemen zijn complexer dan hun tegenhangers in een enkel netwerk. Inzicht in de complexiteit van gedistribueerde systemen, het maken van aanvaardbare compromissen voor de taak in kwestie (CAP) en het selecteren van het juiste gereedschap voor het werk is belangrijk bij horizontale schaling.