Opmerking: Deze post is verouderd. Hier vindt u de meest up-to-date versie.
dit bericht is verouderd. Hier vindt u de bijgewerkte versie. Ik ben opzettelijk het verlaten van dit artikel hier, zodat ik niet verstoren andere sites terug te linken naar mij.
enkele jaren geleden was het bouwen van prestaties in een softwaresysteem eenvoudig – u verhoogde uw hardwarebronnen (opschalen) of wijzigde uw applicatie om efficiënter te werken (performance tuning). Vandaag is er een derde optie: horizontaal schalen (schalen uit).
de laatste jaren is horizontale schaalvergroting van softwaresystemen noodzakelijk geworden vanwege het mondiale karakter van computers en de steeds hogere prestatievereisten voor toepassingen. In veel gevallen is het niet langer aanvaardbaar om een enkele server met een enkele database te draaien in een enkel datacenter naast het hoofdkantoor van uw bedrijf. We hebben echt gedistribueerde omgevingen nodig om de zakelijke uitdagingen van vandaag aan te kunnen.
helaas zijn de prestatievoordelen die horizontale schaling biedt een kostencomplexiteit. Gedistribueerde systemen introduceren veel meer factoren in de prestatievergelijking dan voorheen bestond. Gegevensrecords variëren tussen clients / knooppunten op verschillende locaties. Single points of failure vernietigen systeem up-time, en intermitterende netwerk problemen sluipen op de slechtst mogelijke tijd.
deze zorgen over consistentie (C), beschikbaarheid (A) en partitietolerantie (P) tussen gedistribueerde systemen vormen wat ~~Eric Brewer~~ bedacht als de Cap-stelling. Simpel gezegd toont de cap-stelling aan dat elk gedistribueerd systeem C, A en P niet tegelijkertijd kan garanderen, in plaats daarvan moeten afwegingen worden gemaakt op een punt in de tijd om het prestatieniveau en de beschikbaarheid te bereiken die nodig zijn voor een specifieke taak.
consistentie: alle knooppunten zien dezelfde gegevens op hetzelfde moment.
simpel gezegd, het uitvoeren van een leesbewerking zal de waarde van de meest recente schrijfbewerking retourneren, waardoor alle knooppunten dezelfde gegevens retourneren. Een systeem heeft consistentie als een transactie begint met het systeem in een consistente toestand, en eindigt met het systeem in een consistente toestand. In dit model kan een systeem tijdens een transactie in een inconsistente staat verschuiven (en doet dat ook), maar de hele transactie wordt teruggedraaid als er een fout optreedt tijdens een fase in het proces.
typische relationele databases zijn consistent: SQL Server, MySQL en PostgreSQL.
beschikbaarheid-elk verzoek krijgt een antwoord bij succes / mislukking.
beschikbaarheid in een gedistribueerd systeem vereist dat het systeem 100% van de tijd operationeel blijft. Elke client krijgt een antwoord, ongeacht de status van een individueel knooppunt in het systeem. Deze metriek is triviaal om te meten: of je kunt lezen/schrijven commando ‘ s indienen, of je kunt niet.
typische relationele databases zijn ook beschikbaar: SQL Server, MySQL en PostgreSQL. Dit betekent dat relationele databases bestaan in de CA – ruimte-consistentie en beschikbaarheid. Echter, CA is niet alleen gereserveerd voor relationele databases – sommige document-georiënteerde tools zoals ElasticSearch vallen ook onder de CA paraplu.
Partitietolerantie-systeem blijft werken ondanks berichtverlies of gedeeltelijk falen.
de meeste mensen zien hun gegevensopslag als één knooppunt in het netwerk. “Dit is onze productie SQL Server instance”. Iedereen die een productie-instantie meer dan vier minuten heeft laten draaien, realiseert zich al snel dat dit een enkel punt van mislukking creëert. Een systeem dat partitie-tolerant is kan elke hoeveelheid netwerkfalen die niet resulteert in een storing van het hele netwerk te ondersteunen. Gegevensrecords worden voldoende gerepliceerd over combinaties van knooppunten en netwerken om het systeem up te houden door intermitterende uitval.
opslagsystemen die vallen onder Partitietolerantie met consistentie (CP): MongoDB, Redis, AppFabric Caching en MemcacheDB. CP-systemen zorgen voor uitstekende gedistribueerde caches omdat elke client dezelfde gegevens krijgt en het systeem over netwerkgrenzen heen wordt gepartitioneerd.
opslagsystemen die vallen onder Partitietolerantie met beschikbaarheid (Ap) zijn DynamoDB, CouchDB en Cassandra.
conclusie
gedistribueerde systemen stellen ons in staat een niveau van rekenkracht en beschikbaarheid te bereiken dat in vroegere jaren eenvoudigweg niet beschikbaar was. Onze systemen hebben hogere prestaties, lagere latency en bijna 100% up-time in datacenters die de hele wereld bestrijken. Het beste van alles, de systemen van vandaag worden uitgevoerd op commodity hardware die gemakkelijk verkrijgbaar en configureerbaar met de kosten naderen $ 0.
al deze rekenkracht en voordelen hebben echter een prijs. Gedistribueerde systemen zijn complexer dan hun tegenhangers met één netwerk. Er zijn veel meer tools en vaardigheden die moeten worden verworven om een echt schaalbaar, high performance systeem te creëren. Het begrijpen van de complexiteit van gedistribueerde systemen, het maken van de juiste trade-offs voor de taak bij de hand (CAP), en het selecteren van de juiste tool voor de taak zijn allemaal cruciale vaardigheden in een wereld waar computersystemen bewegen uit, niet omhoog.
