Performanța bazei de date este o afacere serioasă, dar de ce să nu vă distrați puțin explorând provocările și complexitățile sale? 😉 Iată o poveste destul de fantastică pe care am prezentat-o în Capitolul 1 din . Database Performance at Scale, o carte gratuită cu acces deschis Performanța bazei de date la scară Performanța bazei de date la scară Subiectele tehnice acoperite aici sunt extinse pe tot parcursul cărții.Dar aceasta este singura dată când vorbim despre săracul Patrick.Lăsați luptele sale să vă aducă câteva lecții valoroase, consolare în propriile predicții de performanță ale bazei de date ... și poate și câteva șocuri. *** cu După ce și-a pierdut locul de muncă la o companie FAANG MAANG (MANGA?) , Patrick a decis să se retragă pe cont propriu și a fondat un magazin online de nișă dedicat tranzacționării preferinței sale absolute în rândul capului, fedora verde. După ce a experimentat cu nivelul gratuit al ofertei, Patrick a decis să semneze un contract de un an cu un furnizor major de cloud pentru a obține o reducere semnificativă pe oferta sa de bază de date NoSQL ca serviciu. Cu o capacitate de aprovizionare prevăzută capabilă să servească până la 1.000 de clienți în fiecare secundă, pila de tehnologie era gata și magazinul și-a deschis ușile virtuale pentru clienți. Spre dezamăgirea lui Patrick, mai puțin de zece clienți au vizitat site-ul zilnic. În același timp, clusterul de baze de date strălucitor nou a continuat să funcționeze, alimentat de un aflux constant de bani de pe cardul său de credit și așteptând să fie exploatat potențialul său. Patrick’s Diary of Lessons Learned, Part I Jurnalul lui Patrick despre lecțiile învățate, partea I Cursurile au început imediat: Deși unele baze de date se promovează ca fiind universale, cele mai multe dintre ele funcționează cel mai bine pentru anumite tipuri de sarcini de lucru. Este probabil să existe un flux previzibil și constant de solicitări (de exemplu, actualizările sunt preluate periodic din alte sisteme)? Este varianța mare și dificil de prezis, sistemul fiind inactiv pentru perioade potențial lungi de timp, cu bătăi ocazionale de activitate? Ofertele bazei de date ca serviciu vă permit adesea să alegeți între aprovizionarea prevăzută și achiziționarea la cerere. Deși primul este mai eficient din punct de vedere al costurilor, acesta suportă un anumit cost indiferent de cât de ocupat este de fapt baza de date. Acesta din urmă costă mai mult pe cerere, dar plătiți numai pentru ceea ce utilizați. Acordați-vă timp pentru a vă evalua alegerea și pentru a evita să vă angajați în contracte pe termen lung (chiar dacă sunteți sedus de o reducere) înainte de a vedea că setarea funcționează pentru dvs. într-un mod durabil. Primul spike Ziua de 17 martie părea o zi extrem de norocoasă.Patrick a fost mulțumit să observe o mulțime de comenzi noi începând de dimineața devreme.Dar, pe măsură ce numărul clienților activi a crescut în jurul orei de prânz, starea de spirit a lui Patrick a început să se deterioreze.Acest lucru a fost strict corelat cu rata de apeluri pe care le-a primit de la clienții furioși care au raportat incapacitatea lor de a continua cu comenzile. După o scurtă sesiune de brainstorming cu el însuși și un motor de căutare web, Patrick și-a dat seama, spre dezamăgirea sa, că îi lipseau orice instrumente de observare pe clusterul său de baze de date prețioase (și destul de scumpe). "Provizionate lovituri de debit din nou", Patrick a strigat la sine, în timp ce se deplasează prin mii de mesaje de eroare "excedat de debit" care au început să apară în jurul orei 11 dimineața. Patrick’s Diary of Lessons Learned, Part II Jurnalul lui Patrick despre lecțiile învățate, partea a II-a Iată ce a învățat Patrick: Dacă sarcina dvs. de lucru este susceptibilă la vârfuri, pregătiți-vă pentru aceasta și încercați să vă construiți clusterul pentru a putea supraviețui unei sarcini temporare ridicate. Soluțiile bazei de date ca serviciu au tendința de a permite configurarea în mod dinamic a debitului prevăzut, ceea ce înseamnă că pragul cererilor acceptate poate fi ocazional ridicat temporar la un nivel configurat anterior sau, respectiv, permit reducerea temporară pentru a face soluția puțin mai rentabilă. Chiar dacă sarcina dvs. de lucru este absolut constantă, o defecțiune temporară a hardware-ului sau un atac DDoS surprinzător poate provoca o creștere accentuată a solicitărilor primite. Observabilitatea este cheia în sistemele distribuite. permite dezvoltatorilor să investigheze retrospectiv o defecțiune. Oferă, de asemenea, alerte în timp real atunci când este detectat un scenariu probabil de eșec, permițând oamenilor să reacționeze rapid și fie să prevină o defecțiune mai mare, fie cel puțin să minimizeze impactul negativ asupra clusterului. Prima pierdere Patrick nu a reușit nici măcar să se recupereze de trauma de a-și pierde cea mai mare parte a veniturilor potențiale în singura zi a anului în care Fedora verde a experimentat orice fel de cerere, când a venit scrisoarea. Fără a mai fi deranjat, Patrick a navigat în baza de date. Spre uimirea sa, el nu a găsit nici o urmă a comenzii. Pentru completitudine, Patrick și-a pus în practică gândirea dorită prin navigarea în directorul de imagini instantanee de rezervă. A rămas goală, deoarece una dintre deciziile inițiale ale executivului lui Patrick a fost de a economisi timp și bani prin faptul că nu a programat proceduri periodice de backup. După ce a studiat modelul de coerență al bazei sale de date de alegere, Patrick și-a dat seama că există un consens între garanțiile de coerență, performanță și disponibilitate. Prin configurarea interogărilor, se poate solicita fie linearizabilitateaFootnote7 în detrimentul pierderii de putere, fie reducerea garanțiilor de coerență și creșterea performanței în consecință. Capacitățile de putere mai mare au fost o problemă pentru Patrick acum câteva zile, dar în cele din urmă datele clienților au aterizat pe un singur server fără nici o replică distribuită în sistem. Odată ce acest server a eșuat – ceea ce se întâmplă cu hardware-ul surprinzător de des, mai ales la scară largă – datele au dispărut. Patrick’s Diary of Lessons Learned, Part III Jurnalul lui Patrick despre lecțiile învățate, partea a III-a Alte lecții includ: Backup-urile sunt vitale într-un mediu distribuit și nu există așa ceva ca setarea rutinelor de backup "prea repede". Fiecare sistem de baze de date are un anumit model de coerență și este esențial să luați în considerare acest lucru atunci când proiectați proiectul dvs. Pot exista compromisuri. În unele cazuri de utilizare (gândiți-vă la sistemele financiare), coerența este cheia. Spike atacă din nou Cu backup-uri regulate, un model de coerență reproiectat și o reamintire stabilită în calendarul său pentru 16 martie pentru a scala clusterul pentru a gestiona traficul ridicat, sa simțit moderat în siguranță. Dacă ar fi știut că un videoclip de zece secunde al unei pisici îmbrăcată ca un leprechaun tocmai a devenit viral în Malaezia ... care, luând în considerare fusul orar, sa întâmplat în jurul orei 2 dimineața de Patrick, ruinând eforturile de stabilizare a somnului menționate mai sus. Pe de o parte, suite-ul de observabilitate și-a făcut treaba și a lansat un avertisment devreme, permițând un răspuns rapid. Pe de altă parte, chiar dacă Patrick a reacționat la timp, bazele de date sunt rareori capabile să se măsoare instantaneu, iar sistemul său de alegere nu a fost o excepție în această privință. Spike-ul concurenței a fost foarte ridicat și concentrat, deoarece mii de adolescenți malaysieni s-au grăbit să cumpere pălării verzi în vrac în căutarea tendințelor internetului în continuă schimbare. Cu o formulă frumos concisă, L = λW, legea poate fi simplificată la faptul că concurența este egală cu latența timpului de trecere. Legea lui Little Concurența este doar un număr, latența poate fi măsurată în secunde, în timp ce debitul este de obicei exprimat în 1/s. Apoi, este logic că, pentru ca unitățile să se potrivească, concurența ar trebui obținută prin înmulțirea latenței (secunde) cu debitul (1/s). Tipul : Tipul : Throughput depinde de hardware și, în mod natural, are limitele sale (de exemplu, nu vă puteți aștepta ca o unitate NVMe cumpărată în 2023 să vă servească datele în terabytes pe secundă, deși ne încrucișăm degetele pentru ca această ipoteză să fie invalidată în viitorul apropiat!) Odată ce limita este atinsă, o puteți trata ca fiind constantă în formulă. Este apoi clar că pe măsură ce concurența crește, la fel și latența. Pentru utilizatorii finali – adolescenții malaysieni în acest scenariu – înseamnă că latența va trece în cele din urmă bariera magică pentru percepția umană medie de câteva secunde. Odată ce se întâmplă acest lucru, utilizatorii devin prea frustrați și renunță la încercarea totală, presupunând Patrick’s Diary of Lessons Learned, Part IV Jurnalul lui Patrick despre lecțiile învățate, partea a IV-a Lecțiile continuă: Spike-urile neașteptate sunt inevitabile, iar extinderea clusterului poate să nu fie suficient de rapidă pentru a atenua efectele negative ale concurenței excesive. A aștepta ca baza de date să o gestioneze în mod corespunzător nu este fără merit, dar nu fiecare bază de date este capabilă de acest lucru. Dacă este posibil, limitați concurența în sistemul dvs. cât mai curând posibil. De exemplu, dacă baza de date nu este niciodată atinsă direct de clienți (care este o idee foarte bună din mai multe motive), dar în schimb este accesată printr-un set de microservices sub controlul dvs., asigurați-vă că microservices-urile sunt, de asemenea, conștiente de limitele concurenței și le respectă. Amintiți-vă că Legea lui Little există - este o cunoaștere fundamentală pentru oricine este interesat de sistemele distribuite. Backup Strike înapoi După ce și-a reproiectat proiectul din nou pentru a lua în considerare fluctuațiile așteptate și neașteptate ale concurenței, Patrick a așteptat cu bucurie ca afacerea sa Fedora să devină în cele din urmă rentabilă. Din păcate, următorul 17 martie nu s-a desfășurat la fel de bine cum era de așteptat. Patrick a petrecut cea mai mare parte a zilei bucurându-se de tablourile de bord Grafana, care l-au asigurat că traficul era sub control și capabil să gestioneze încărcătura clienților, cu o marjă de siguranță sănătoasă. Dar apoi tablourile de bord s-au oprit, menționând cu amabilitate că discurile au devenit grav suprautilizate. Acest lucru părea complet inadmisibil având în vedere concurența observată. În timp ce căuta sursa posibilă a acestei anomalii, Patrick a observat, spre groaza sa, că procedura de backup programată coincide cu sarcina anuală de vârf... Patrick’s Diary of Lessons Learned, Part V Jurnalul lui Patrick despre lecțiile învățate, partea a V-a Gânduri încheiate: Sistemele de baze de date sunt aproape niciodată goale, chiar și fără solicitări de utilizator primite. Operațiunile de întreținere apar adesea și trebuie să le luați în considerare, deoarece acestea sunt o sursă internă de concurență și consum de resurse. Ori de câte ori este posibil, planificați opțiunile de întreținere pentru perioadele cu presiune scăzută preconizată pe sistem. Dacă sistemul dvs. de gestionare a bazelor de date acceptă orice tip de configurație de calitate a serviciului, este o idee bună să investigați astfel de capacități. De exemplu, ar putea fi posibil să setați o prioritate puternică pentru solicitările utilizatorilor față de operațiunile de întreținere regulate, în special în timpul orelor de vârf. şi sfârşitul. Despre Piotr Sarna este un inginer software care este pasionat de proiecte open-source și de limbile Rust și C++. El a dezvoltat anterior un sistem de fișiere distribuite open-source și a avut o scurtă aventură cu kernel-ul Linux în timpul unui stagiu la Samsung Electronics. El este, de asemenea, un contribuitor de lungă durată și întreținător al ScyllaDB, precum și libSQL. Piotr a absolvit Universitatea din Varșovia cu un Master în Informatică. El este co-autor al cărților "Database Performance at Scale" și "Writing for Developers: Blogs that Get Read". Piotr
