Diferența între scalarea pe orizontală și pe verticală pentru baze de date

Scalare orizontală înseamnă că sunteți de scară prin adăugarea de mai multe mașini în piscina de resurse întrucât scalare Verticală înseamnă că scala prin adăugarea de mai multă putere (CPU, RAM) pentru o mașină existente.

O modalitate ușoară de a amintiți-vă acest lucru este să se gândească la o mașină pe un server rack, vom adăuga mai multe mașini peste orizontală direcția și a adăuga mai multe resurse la o mașină în verticale direcție.

Într-o bază de date mondială orizontală-scalare este de multe ori pe baza de partiționare a datelor, adică fiecare nod conține doar o parte din date, în verticală-scalarea de date se află pe un singur nod și scalarea se face prin intermediul multi-core și anume răspândirea de încărcare între CPU și RAM resurse de acea mașină.

Cu orizontală-scalare este adesea mai ușor de a scala în mod dinamic prin adăugarea de mai multe mașini în piscină existente - Vertical-scalare este adesea limitată la capacitatea de o singură mașină, scalare dincolo de această capacitate implică de multe ori de nefuncționare și vine cu o limită superioară.

Exemple bune de scalare orizontală sunt Cassandra, MongoDB, Google Cloud Cheie .. și un bun exemplu de scalare verticală este MySQL - Amazon RDS (nor versiune de MySQL). Acesta oferă o modalitate ușoară de a scară vertical prin trecerea de la mic la mare de mașini. Acest proces implică de multe ori de nefuncționare.

În Memorie Rețelele de Date, cum ar fi GigaSpaces XAP, Coerența etc.. sunt de multe ori optimizat pentru ambele orizontale și verticale scalare pur și simplu pentru că ei're nu este legat de disc. Orizontală-scalare prin partiționare și verticale-extinderea prin suport multi-core.

Puteți citi mai multe pe acest subiect în mesajele anterioare: Scale-out vs Scară-up și Principiile Comune Spatele NOSQL Alternative

În cuvinte simple:

Scalarea pe orizontală ===> Mii de slujitorii va face munca pentru tine.

Scalarea verticală ===> O mare hulk va face toata munca pentru tine.

Las's începe cu nevoia de scalare, care este în creștere de resurse, astfel încât sistemul dvs. se pot ocupa acum mai multe cereri decât mai devreme ar putea.

Când realizezi că sistemul dumneavoastră este obtinerea lent și nu este în măsură să se ocupe de numărul actual de cereri, aveți nevoie pentru a scara de sistem.

Acest lucru vă oferă două opțiuni. Fie să crească resurse din server-ul pe care îl utilizați în prezent, nu.e, crește cantitatea de memorie RAM, CPU, GPU și alte resurse. Acest lucru este cunoscut sub numele de scalare verticală.

Scalare verticală este de obicei costisitoare. Nu face sistemul vina tolerant, nu.dacă sunteți de scalare aplicație care rulează cu un singur server, în cazul în care serverul se duce în jos, sistemul dvs. va merge în jos. De asemenea, cantitatea de fire rămâne același în scalare verticală. Scalare verticală poate solicita sistemul dvs. pentru a merge în jos pentru o clipă, atunci când procesul are loc. Creșterea resurselor pe un server necesită un restart si pune sistemul dvs. în jos.

O altă soluție la această problemă este creșterea cantității de serverele prezente în sistem. Această soluție este foarte utilizat în industria tech. Acest lucru va reduce cererea de pe a doua pe fiecare server. Dacă aveți nevoie pentru a scara de sistem, trebuie doar să adăugați un alt server, și ați terminat. Nu ar fi necesar să reporniți sistemul. Numărul de fire în fiecare sistem scade, ceea ce duce la debit mare. Pentru a separa cereri, în mod egal pentru fiecare server de aplicație, aveți nevoie pentru a adăuga echilibrare care ar putea acționa ca reverse proxy pentru servere web. Acest sistem poate fi numit ca un singur cluster. Sistemul dvs. poate conține un număr mare de cereri care ar necesita mai mult cantitatea de grupuri, cum ar fi acest lucru.

Sperăm că veți obține întregul concept de introducerea de scalare a sistemului.

Există o suplimentare de arhitectură care a fost't menționat - SQL pe baza de date de servicii care permit scalare orizontală fără complexitatea manual sharding. Aceste servicii fac sharding în fundal, astfel încât acestea vă permit să rulați un tradiționale de baze de date SQL și scară ca tine ar fi cu NoSQL motoare ca MongoDB sau CouchDB. Două servicii sunt familiarizați cu sunt EnterpriseDB pentru PostgreSQL și Xeround pentru MySQL. Am văzut-o în profunzime post de Xeround ceea ce explică de ce scară-out pe baze de date SQL este dificil și cum se face în mod diferit de - a trata acest lucru cu un bob de sare, deoarece este un furnizor de post. De asemenea, a verifica afară de Wikipedia's Nor de Date de intrare, există o explicație de SQL vs NoSQL și servicii raport de auto-a găzduit, o listă de furnizori și opțiunile de standardizare pentru fiecare combinație. ;)

Da scalarea pe orizontală înseamnă adăugarea de mai multe masini, dar, de asemenea, implică faptul că mașinile sunt egale în cluster. MySQL poate scala orizontal în termeni de Citire a datelor, prin utilizarea de replici, dar odată ce ajunge la o capacitate de server mem/disc, trebuie să înceapă sharding date de pe servere. Acest lucru devine din ce în ce mai complexe. De multe ori păstrarea de date coerente în replici este o problemă la fel de replicare prețurile sunt de multe ori prea lent pentru a ține pasul cu schimbare de date ratele.

Couchbase este, de asemenea, un fantastic NoSQL Scalare Orizontală baza de date, folosit în multe comerciale de înaltă disponibilitate aplicații și jocuri și, fără îndoială, cel mai mare interpret în categoria. Se partiții de date în mod automat peste bord, adăugarea de noduri este simplu, și puteți utiliza hardware de mărfuri, mai ieftin vm cazuri (folosind de Mare în loc de Mare Mem, Disc masini de la AWS, de exemplu). Acesta este construit pe Membase (Memcached) dar adaugă persistența. De asemenea, în caz de Couchbase, fiecare nod poate face citește și scrie, și sunt egali în cluster, cu doar failover replicare (nu întregul set de date de replicare pe toate serverele ca în mySQL).

Performanță, puteți vedea un excelent Cisco de referință: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Aici este o mare post pe blog despre Couchbase Arhitectura: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

Tradiționale de baze de date relaționale au fost concepute ca client/server sisteme de baze de date. Ele pot fi scalate pe orizontală, dar procesul de a face astfel încât tinde să fie complex și predispus la erori. NewSQL bazele de date ca NuoDB sunt de memorie-centrice distribuite sisteme de baze de date conceput pentru a scala orizontal menținând în același timp SQL/ACID proprietăți tradiționale RDBMS.

Pentru mai multe informații despre NuoDB, citit tehnice albă de hârtie.

SQL baze de date cum ar fi Oracle, db2, de asemenea, sprijin scalare Orizontală prin disc Partajat de bord. De exemplu, Oracle, IBM DB2 purescale sau Sybase ASE Cluster ediție. Noul nod poate fi adăugat la Oracle RAC sistemul sau DB2 purescale sistem pentru a realiza o scalare orizontală.

Dar modul de abordare este diferit de baze de date noSQL (ca mongodb, CouchDB sau IBM Cloudant) este că datele sharding nu este parte de scalare Orizontală. În baze de date noSQL date este shraded timpul scalare orizontală.

Ai o firmă și nu este doar 1 muncitor dar ai 1 proiect nou la acea vreme, mașină nou candidat ... asta este scalare orizontală. în cazul în care noul candidat este de mașini noi și de proiect este nouă trafic/apeluri api's.

În cazul în care 1 proiect cu o IIT/NIT tip de manipulare toate cererea dumneavoastră api/trafic. Dacă în orice moment mai multe cereri api's apoi trage-l și înlocuindu-l cu un IQ ridicat NIT/IIT tip-aceasta este scalare verticală.

Adăugarea de o mulțime de echilibrat de încărcare creează extra aeriene și latență și care este dezavantajul pentru scalarea pe orizontală în baze de date nosql. Este ca și cum întrebarea de ce oamenii spun că RPC nu este recomandată deoarece nu este robust.

Cred că într-un sistem real ar trebui să utilizați atât sql și baze de date nosql pentru a utiliza ambele multicore și capacitățile de cloud computing de azi's sisteme.

Pe de altă parte, complex tranzacționale interogări are de înaltă performanță dacă sql baze de date cum ar fi oracle a fi folosit. NoSql ar putea fi utilizate pentru bigdata și scalabilitate orizontală de sharding.

Acceptat răspunsul este la fața locului pe bază definiția orizontală vs scalare verticală. Dar, spre deosebire de convingerea comună că scalare orizontală de baze de date este posibilă doar cu Cassandra, MongoDB, etc, aș dori să adaug că scalare orizontală este, de asemenea, foarte mult posibil cu orice tradiționale RDMS; că prea fără a utiliza orice soluții terțe părți.

Știu că de multe companii, în special SaaS pe bază de companii care fac acest lucru. Acest lucru se face folosind aplicație simplă logică. Practic iei un set de utilizatori și să le repartizeze pe mai multe servere DB. Deci, de exemplu, au de obicei o "meta" baza de date/tabel care va stoca clienti, server DB/conexiune siruri de caractere, etc și un tabel care stochează client/server de cartografiere.

Apoi, pur și simplu, cereri directe de la fiecare client pentru serverul de DB sunt mapate.

Acum unii ar putea spune acest lucru este asemănător cu partiționare orizontală și nu "adevărat" scalare orizontală și ei vor fi bine în unele moduri. Dar rezultatul final este că trebuie scalate DB dvs. pe mai multe servere Db.

Singura diferență între cele două metode de scalare orizontală este că o abordare (MongoDB, etc) scalarea se face de către DB software-ul în sine. În acest sens sunt "cumpara" de scalare. În alte abordări (pentru RDBMS scalare orizontală), scalarea este construit prin aplicarea codului/logica.