Notă: Această postare este depășită. Puteți găsi cea mai actualizată versiune aici.
această postare este depășită. Vă rugăm să găsiți versiunea actualizată aici. Sunt lăsând în mod intenționat acest articol aici, așa că nu perturba alte site-uri care leagă înapoi la mine.
cu câțiva ani în urmă, construirea performanței într – un sistem software a fost simplă-fie ați crescut resursele hardware (scalați), fie ați modificat aplicația pentru a rula mai eficient (reglarea performanței). Astăzi, există o a treia opțiune: scalarea orizontală (scalare).
scalarea orizontală a sistemelor software a devenit necesară în ultimii ani, datorită naturii globale a calculului și a cerințelor de performanță din ce în ce mai mari pentru aplicații. În multe cazuri, nu mai este acceptabil să rulați un singur server cu o singură bază de date într-un singur centru de date adiacent sediului companiei dvs. Avem nevoie de medii cu adevărat distribuite pentru a face față provocărilor de afaceri de astăzi.
din păcate, beneficiile de performanță pe care le oferă scalarea orizontală vin la o complexitate a costurilor. Sistemele distribuite introduc mult mai mulți factori în ecuația de performanță decât existau înainte. Înregistrările de date variază între clienți/noduri în locații diferite. Punctele unice de eșec distrug timpul de funcționare al sistemului, iar problemele de rețea intermitente se strecoară în cel mai rău moment posibil.
aceste preocupări de consistență (C), disponibilitate (a) și toleranță de partiție (P) între sistemele distribuite alcătuiesc ceea ce ~~Eric Brewer~~ inventat ca teorema CAP. Pur și simplu, teorema PAC demonstrează că orice sistem distribuit nu poate garanta C, A și P simultan, mai degrabă, compromisurile trebuie făcute la un moment dat pentru a atinge nivelul de performanță și disponibilitate necesar pentru o anumită sarcină.
consistență – toate nodurile văd aceleași date în același timp.
pur și simplu, efectuarea unei operații de citire va returna valoarea celei mai recente operații de scriere, determinând toate nodurile să returneze aceleași date. Un sistem are consistență dacă o tranzacție începe cu sistemul într-o stare consecventă și se termină cu sistemul într-o stare consecventă. În acest model, un sistem poate (și nu) trece într-o stare inconsistentă în timpul unei tranzacții, dar întreaga tranzacție devine derulată înapoi dacă există o eroare în orice etapă a procesului.
bazele de date relaționale tipice sunt consistente: SQL Server, MySQL și PostgreSQL.
disponibilitate-fiecare cerere primește un răspuns la succes / eșec.
realizarea disponibilității într-un sistem distribuit necesită ca sistemul să rămână operațional 100% din timp. Fiecare client primește un răspuns, indiferent de starea oricărui nod individual din sistem. Această valoare este banală de măsurat: fie puteți trimite comenzi de citire/scriere, fie nu puteți.
sunt disponibile și baze de date relaționale tipice: SQL Server, MySQL și PostgreSQL. Aceasta înseamnă că există baze de date relaționale în spațiul CA – consistență și disponibilitate. Cu toate acestea, CA nu este rezervat doar bazelor de date relaționale – unele instrumente orientate spre documente, cum ar fi ElasticSearch, se încadrează și sub umbrela CA.
toleranța partiției – sistemul continuă să funcționeze în ciuda pierderii mesajului sau a eșecului parțial.
majoritatea oamenilor se gândesc la stocarea lor de date ca la un singur nod din rețea. „Aceasta este instanța noastră de producție SQL Server”. Oricine a condus o instanță de producție mai mult de patru minute, își dă seama rapid că acest lucru creează un singur punct de eșec. Un sistem care este tolerant la partiție poate susține orice cantitate de eșec de rețea care nu duce la o defecțiune a întregii rețele. Înregistrările de date sunt suficient de reproduse în combinații de noduri și rețele pentru a menține sistemul în sus prin întreruperi intermitente.
sisteme de stocare care se încadrează în toleranța partiției cu consistență (CP): MongoDB, Redis, cache-ul AppFabric și MemcacheDB. Sistemele CP fac cache-uri distribuite excelente, deoarece fiecare client primește aceleași date, iar sistemul este partiționat peste granițele rețelei.
sistemele de stocare care se încadrează în toleranța partiției cu disponibilitate (AP) includ DynamoDB, CouchDB și Cassandra.
concluzie
sistemele distribuite ne permit să atingem un nivel de putere și disponibilitate de calcul care pur și simplu nu erau disponibile în anii anteriori. Sistemele noastre au performanțe mai mari, latență mai mică și aproape 100% up-time în centrele de date care se întind pe întregul glob. Cel mai bun dintre toate, sistemele de astăzi sunt rulate pe hardware-ul de mărfuri care este ușor de obținut și configurabil, cu costuri care se apropie de 0 USD.
toată această putere de calcul și beneficii vine la un preț, cu toate acestea. Sistemele distribuite sunt mai complexe decât omologii lor cu o singură rețea. Există mult mai multe instrumente și abilități care trebuie dobândite pentru a crea un sistem cu adevărat scalabil, de înaltă performanță. Înțelegerea complexității suportate în sistemele distribuite, realizarea compromisurilor adecvate pentru sarcina la îndemână (PAC) și selectarea instrumentului potrivit pentru job sunt toate abilități critice într-o lume în care sistemele de calcul se deplasează, nu în sus.
