Nota: Questo post è obsoleto. Puoi trovare la versione più aggiornata qui.
Questo post è obsoleto. Si prega di trovare la versione aggiornata qui. Sto lasciando intenzionalmente questo articolo qui in modo da non interrompere altri siti che collegano di nuovo a me.
Diversi anni fa, la creazione di prestazioni in un sistema software era semplice: aumentavi le risorse hardware (scalabilità) o modificavi l’applicazione per eseguire in modo più efficiente (ottimizzazione delle prestazioni). Oggi, c’è una terza opzione: scala orizzontale (scala fuori).
Il ridimensionamento orizzontale dei sistemi software si è reso necessario negli ultimi anni, a causa della natura globale dell’informatica e delle crescenti richieste di prestazioni delle applicazioni. In molti casi, non è più accettabile eseguire un singolo server con un singolo database in un singolo data center adiacente alla sede centrale dell’azienda. Abbiamo bisogno di ambienti veramente distribuiti per affrontare le sfide aziendali di oggi.
Sfortunatamente, i vantaggi in termini di prestazioni offerti dal ridimensionamento orizzontale hanno una complessità di costo. I sistemi distribuiti introducono molti più fattori nell’equazione delle prestazioni rispetto a prima. I record di dati variano tra client / nodi in posizioni diverse. I singoli punti di guasto distruggono il tempo di operatività del sistema e i problemi di rete intermittenti si insinuano nel momento peggiore possibile.
Queste preoccupazioni di coerenza (C), disponibilità (A) e tolleranza della partizione (P) tra sistemi distribuiti costituiscono ciò che ~~Eric Brewer~~ ha coniato come Teorema CAP. In poche parole, il teorema CAP dimostra che qualsiasi sistema distribuito non può garantire C, A e P contemporaneamente, piuttosto, i compromessi devono essere fatti in un momento per raggiungere il livello di prestazioni e disponibilità richiesto per un compito specifico.
Coerenza: tutti i nodi vedono gli stessi dati contemporaneamente.
In poche parole, l’esecuzione di un’operazione di lettura restituirà il valore dell’operazione di scrittura più recente facendo sì che tutti i nodi restituiscano gli stessi dati. Un sistema ha coerenza se una transazione inizia con il sistema in uno stato coerente e termina con il sistema in uno stato coerente. In questo modello, un sistema può (e lo fa) spostarsi in uno stato incoerente durante una transazione, ma l’intera transazione viene ripristinata se si verifica un errore durante una fase del processo.
I database relazionali tipici sono coerenti: SQL Server, MySQL e PostgreSQL.
Disponibilità-Ogni richiesta riceve una risposta in caso di successo/fallimento.
Per ottenere la disponibilità in un sistema distribuito è necessario che il sistema rimanga operativo il 100% delle volte. Ogni client riceve una risposta, indipendentemente dallo stato di qualsiasi singolo nodo nel sistema. Questa metrica è banale da misurare: puoi inviare comandi di lettura/scrittura o non puoi.
Sono disponibili anche database relazionali tipici: SQL Server, MySQL e PostgreSQL. Ciò significa che i database relazionali esistono nello spazio CA-coerenza e disponibilità. Tuttavia, CA non è riservato solo ai database relazionali: alcuni strumenti orientati ai documenti come ElasticSearch rientrano anche nell’ombrello CA.
Tolleranza partizione – Il sistema continua a funzionare nonostante la perdita di messaggi o un errore parziale.
La maggior parte delle persone pensa al proprio archivio dati come a un singolo nodo nella rete. “Questa è la nostra istanza SQL Server di produzione”. Chiunque abbia eseguito un’istanza di produzione per più di quattro minuti, si rende conto rapidamente che questo crea un singolo punto di errore. Un sistema che è partition-tolerant può sostenere qualsiasi quantità di errore di rete che non provoca un guasto dell’intera rete. I record di dati sono sufficientemente replicati tra combinazioni di nodi e reti per mantenere il sistema attivo attraverso interruzioni intermittenti.
Sistemi di storage che rientrano nella tolleranza alle partizioni con coerenza (CP): MongoDB, Redis, AppFabric Caching e MemcacheDB. I sistemi CP creano cache distribuite eccellenti poiché ogni client riceve gli stessi dati e il sistema viene partizionato attraverso i confini della rete.
I sistemi di storage che rientrano nella tolleranza delle partizioni con disponibilità (AP) includono DynamoDB, CouchDB e Cassandra.
Conclusione
I sistemi distribuiti ci consentono di raggiungere un livello di potenza di calcolo e disponibilità che semplicemente non erano disponibili negli anni passati. I nostri sistemi hanno prestazioni più elevate, latenza inferiore e up-time vicino al 100% nei data center che coprono l’intero globo. Meglio di tutti, i sistemi di oggi sono eseguiti su hardware commodity che è facilmente ottenibile e configurabile con costi che si avvicinano a 0 0.
Tutta questa potenza di calcolo e beneficio ha un prezzo, tuttavia. I sistemi distribuiti sono più complessi delle loro controparti a rete singola. Ci sono molti più strumenti e competenze che devono essere acquisite al fine di creare un sistema veramente scalabile, ad alte prestazioni. Comprendere la complessità insita nei sistemi distribuiti, fare i compromessi appropriati per il compito a portata di mano (CAP) e selezionare lo strumento giusto per il lavoro sono tutte competenze critiche in un mondo in cui i sistemi informatici si stanno muovendo fuori, non su.
