Planificarea capacității pentru baze de date

Notă: această postare este inspirată de postarea recentă a lui Julia Evans despre planificarea capacității.

RDBMS

În primul rând, să stabilim câteva reguli de bază. Da... această postare este destinată celor dintre noi care folosesc MySQL cu un singur scriitor la un moment dat și 2 sau mai multe replici citite. Multe dintre cele despre care voi vorbi aici se aplică diferit, sau deloc, pentru depozitele de date grupate cu mai multe scrieri, deși acestea vin și cu propriul set de compromisuri și avertismente. Deci... kilometrajul dvs. va varia cu siguranță.

Cu toate acestea, această postare de blog SE va aplica indiferent dacă utilizați gazde fizice auto-găzduite sau vă aflați în AWS, unde puteți utiliza instanțe rezervate asemănătoare magice și furnizarea aproape instantanee. A fi în „cloud” nu te va împiedica să cunoști abilitățile și limitele infrastructurii tale și nu te va scuti de această responsabilitate față de echipa și clienții tăi.

Sharding

Am acoperit deja linii mari ale acestui lucru într-una dintre postările mele anterioare, m-am concentrat în mare parte pe beneficiile fragmentării funcționale sau orizontale. Da, aceasta este o condiție prealabilă absolută, deoarece ceea ce utilizați pentru a accesa stratul bazei de date VA decide cât de multă flexibilitate aveți pentru a scala.

Dacă sunteți o companie nou-nouță, s-ar putea să nu aveți nevoie de fragmentare funcțională în ziua 1, dar, dacă sperați (și bănuiesc că aveți) să creșteți, nu vă încadrați cu un ORM open source care să nu vă permită să vă divizați datele dvs. pe o bază funcțională în continuare. Puncte bonus dacă, de asemenea, nu începi compania cu toate datele relaționale într-o singură schemă.

Abilitatea de a împărți citirile și scrierile

Acesta este un lucru pe care va trebui să îl puteți face, dar nu neapărat să îl aplicați ca o regulă de piatră. Vor exista cazuri de utilizare în care o scriere trebuie citită foarte curând și în care toleranța pentru lucruri precum lag/coerența eventuală este scăzută. Acestea sunt ok să aveți, dar în aceleași aplicații, veți avea și scenarii pentru citiri care pot tolera un interval de timp mai lung de eventuală consistență. Când astfel de lecturi sunt în volum mare, chiar vrei ca acel volum să fie trimis singurului tău scriitor, dacă nu este necesar? Fă-ți o favoare și asigură-te în curând, în zilele tale de creștere, că poți controla utilizarea unui IP de citire sau scriere în codul tău.

Acum, trecem la procesul de gândire al planificării efective a capacității... Un cluster de baze de date nu ține pasul, ce fac?

Determinați blocajul sistemului

• Sunteți blocat la scrieri sau citiri?
• Problema arată la fel de mare CPU?
• Se prezintă ca capacitate IO?
• Întârzierea în creștere a replicilor fără un vinovat de interogare clară de citire?
• Este încuietori?
• De unde știu chiar care este?

Fiecare dintre acestea poate fi o postare în sine. Ideea pe care încerc să o subliniez este că trebuie să fiți familiarizați cu sistemul dumneavoastră și cu valorile specifice DB pentru a putea afla ce piesa este blocajul.

Ai nevoie de o linie de bază

Asigurați-vă întotdeauna că aveți disponibile valori de bază ale sistemului pentru a le vizualiza cu cel puțin câteva săptămâni în urmă. Multe instrumente oferă acest lucru (Cacti, Munin, Graphite... etc). Odată ce știți la ce metrică de sistem sunteți obligat în mare parte, trebuie să stabiliți valorile de referință și de vârf. În caz contrar, determinarea dacă problema dvs. actuală este o eroare provenită din noua aplicație în comparație cu creșterea reală va fi mult mai predispusă la erori decât ați dori.

Cu toate acestea, valorile de bază ale serverului pot merge doar atât de departe – la un moment dat veți descoperi că aveți nevoie și de valori bazate pe context. Performanța interogărilor și performanța percepută din partea aplicației vă vor spune ceea ce aplicația vede ca timp de răspuns la interogări. Există multe instrumente pentru a face acest context greu de urmărire. Unele sunt open source, cum ar fi Anemometer și instrumente comerciale precum Vivid Cortex (le folosim la SendGrid. Vezi-ne vorbind despre asta aici.) Chiar și doar urmărirea acestor valori din perspectiva aplicației și aruncarea lor ca valori statistice va fi un prim pas bun. Dar, devreme, trebuie să te obișnuiești cu faptul că ceea ce percepe aplicația ta este ceea ce percep clienții tăi. Și mai întâi trebuie să găsești o modalitate de a ști.

Aflați modelele de trafic ale companiei dvs

Sunteți o companie care este susceptibilă la vârfuri extreme în anumite zile ale săptămânii (de exemplu, marketing)? Aveți lansări regulate care vă triplează sau cvadruplă traficul, precum jocurile? Aceste tipuri de întrebări vor determina cât de mult spațiu rezervat ar trebui să păstrați sau dacă trebuie să investiți în creștere elastică.

Determinați raportul dintre numerele brute de trafic în raport cu capacitatea în uz

Acesta este pur și simplu răspunsul la „Dacă nu am făcut nicio optimizare a codului, câte e-mailuri/vânzări/utilizatori online/oricare” putem servi cu instanțe de bază de date pe care le avem acum?

În mod ideal, aceasta este o valoare specifică care face ca matematica pentru planificarea creșterii unui an o simplă ecuație matematică. Dar viața nu este niciodată ideală și această valoare va varia în funcție de sezon sau de factori complet externi fericiți, cum ar fi înscrierea unui nou client major. La începuturile startup-urilor, acest număr este o țintă care se mișcă mai rapid, dar ar trebui să se stabilizeze pe măsură ce compania trece de la primele zile la afaceri mai stabilite, cu modele de creștere a afacerii mai previzibile.

Chiar trebuie să cumpăr mai multe mașini?

Trebuie să găsiți o modalitate de a determina dacă aceasta este cu adevărat capacitate - trebuie să împart scrierile pentru a suporta o încărcare de scriere mai concurentă sau să adaug mai multe replică de citire - vs. blocaj de performanță bazat pe cod (această interogare nouă dintr-o implementare recentă poate avea cu adevărat rezultatele stocate în cache în ceva mai ieftin și să nu bată baza de date la fel de mult).

Cum faci asta? Trebuie să vă familiarizați cu întrebările dvs. Pasul pentru asta este o combinație de innotop, jurnal lent și pt-query-digest din Percona Toolkit. Puteți automatiza acest lucru prin expedierea jurnalelor DB într-o locație centrală și automatizarea porțiunii de rezumat.

Dar nici asta nu este întreaga imagine, jurnalele lente sunt intense în performanță dacă le coborâți prea mult pragul. Dacă puteți trăi cu eșantionare mai puțin selectivă, va trebui să detectați toate conversațiile dintre aplicație și depozitul de date. În terenul cu sursă deschisă puteți merge la fel de simplu ca tcpdump sau puteți folosi produse găzduite precum Datadog, New Relic sau VividCortex.

Efectua un apel

Planificarea capacității poate fi 90% știință și 10% artă, dar acest procent de 10% nu ar trebui să însemne că nu ar trebui să ne străduim să obținem cât mai mult din imagine. Ca ingineri, uneori, ne putem fixa pe cei 10% lipsă și să nu realizăm că, dacă am lucrat, acei 90% ne pot face să avem o idee mai bună despre starea stack-ului nostru, o utilizare mai eficientă a performanței de optimizare a timpului și capacitatea de planificare. crește cu atenție, ceea ce duce în cele din urmă la o rentabilitate mult mai bună a investiției pentru produsele noastre.