Duomenų bazių našumas yra rimtas verslas, bet kodėl gi ne smagu ištirti jo iššūkius ir sudėtingumą? 😉 Čia yra gana fantastinė istorija, kurią pristatėme 1 skyriuje. . Duomenų bazės veikimas skalėje, nemokama atvirojo prieigos knyga Duomenų bazės veikimas mastu Duomenų bazės veikimas mastu Čia aptariamos techninės temos yra išplėstos visoje knygoje. bet tai yra vienintelis ir vienintelis kartas, kai kalbame apie vargšą Patriką. Tegul jo kovos atneša jums vertingų pamokų, paguodos savo duomenų bazės našumo prognozių ... ir galbūt keletą šūksnių taip pat. • • Po to, kai prarado savo darbą FAANG MAANG (MANGA?) įmonėje, Patrick nusprendė atsisakyti savarankiškai ir įkūrė nišą internetinę parduotuvę, skirtą prekybai savo absoliučiu mėgstamiausiu tarp galvos apdangalų, žaliųjų fedorų. Po tam tikrų eksperimentų su nemokamu pasiūlymo lygiu, Patrick nusprendė pasirašyti vienerių metų sutartį su pagrindiniu debesies tiekėju, kad gautų didelę nuolaidą dėl savo NoSQL duomenų bazės kaip paslaugos pasiūlymo. Su numatytu pralaidumu, galinčiu aptarnauti iki 1000 klientų kiekvieną sekundę, technologijų rinkinys buvo paruoštas, o parduotuvė atvėrė savo virtualias duris klientams. Patrickui nusivylus, svetainę kasdien aplankė mažiau nei dešimt klientų. Tuo pačiu metu blizgus naujas duomenų bazės klasteris tęsėsi, o jo kreditinės kortelės pinigų srautas ir laukė, kol bus išnaudotas jo potencialas. Patrick’s Diary of Lessons Learned, Part I Patriko pamokų dienoraštis, I dalis Pamokos prasidėjo iš karto: Nors kai kurios duomenų bazės reklamuoja save kaip universalias, dauguma jų geriausiai tinka tam tikroms darbo apkrovoms.Analizė prieš pasirinkdami duomenų bazę savo poreikiams turi apimti savo darbo apkrovos charakteristikų įvertinimą: Ar tikėtina, kad bus nuspėjamas, pastovus užklausų srautas (pvz., periodiškai gaunami atnaujinimai iš kitų sistemų)? Ar skirtumas yra didelis ir sunku prognozuoti, kai sistema potencialiai ilgą laiką lieka tuščia, kartais pasitaiko aktyvumo smūgių? Duomenų bazės kaip paslaugos pasiūlymai dažnai leidžia pasirinkti tarp numatomo perdavimo ir pagal poreikį. Nors pirmasis yra ekonomiškesnis, jis patiria tam tikrą kainą, nepriklausomai nuo to, kaip užimta duomenų bazė iš tikrųjų yra. Pastarasis kainuoja daugiau už užklausą, bet jūs mokate tik už tai, ką naudojate. Suteikite sau laiko įvertinti savo pasirinkimą ir išvengti ilgalaikių sutarčių (net jei juos vilioja nuolaida), kol pamatysite, kad nustatymas veikia jums tvariai. Pirmasis spike Kovo 17 d. atrodė kaip labai laiminga diena.Patrikas džiaugėsi pastebėjęs daug naujų užsakymų nuo ankstyvo ryto.Bet kai aktyvių klientų skaičius smarkiai išaugo vidurdienį, Patriko nuotaika pradėjo blogėti.Tai buvo griežtai susiję su skambučių, kuriuos jis gavo iš piktų klientų, pranešančių apie jų nesugebėjimą tęsti savo užsakymus, dažnumu. Po trumpo brainstorming sesijos su savimi ir žiniatinklio paieškos varikliu Patrick suprato, kad jam trūko jokių stebėjimo įrankių savo vertingoje (ir gana brangaus) duomenų bazės grupėje. „Pateikta perdavimo srovė vėl smūgiuoja“, - patraukė Patrickas sau, peržiūrėdamas tūkstančius „perdavimo viršijo“ klaidos pranešimų, kurie pradėjo pasirodyti maždaug 11 val. Patrick’s Diary of Lessons Learned, Part II Patriko pamokų dienoraštis, II dalis Štai ką Patrickas išmoko: Jei jūsų darbo apkrova yra jautri spike, pasiruoškite ir pabandykite sukurti savo klasterį, kad galėtumėte išgyventi laikinai padidintą apkrovą. Duomenų bazės kaip paslaugos sprendimai paprastai leidžia dinamiškai konfigūruoti numatytą pralaidumą, o tai reiškia, kad priimtų užklausų slenkstis kartais gali būti laikinai padidintas iki anksčiau konfigūruoto lygio arba, atitinkamai, leidžia laikinai sumažinti, kad sprendimas būtų šiek tiek ekonomiškesnis. Net jei jūsų darbo krūvis yra absoliučiai pastovus, laikinas aparatūros gedimas arba netikėta DDoS ataka gali sukelti didelį gaunamų užklausų padidėjimą. Stebėjimas yra svarbus paskirstytose sistemose.Jis leidžia kūrėjams retrospektyviai ištirti gedimą.Jis taip pat teikia įspėjimus realiuoju laiku, kai aptinkamas galimas gedimo scenarijus, leidžiantis žmonėms greitai reaguoti ir arba užkirsti kelią didesniam gedimui, arba bent jau sumažinti neigiamą poveikį grupei. Pirmieji nuostoliai Patrick net nesugebėjo atsigauti nuo traumos prarasti didžiąją dalį savo galimų pajamų vienintelę dieną per metus, kai žalia fedoras patyrė bet kokią paklausą, kai laiškas atėjo. Be jokių papildomų rūpesčių, Patrick peržiūrėjo duomenų bazę. Jo nuostabai, jis taip pat nerado jokių užsakymo pėdsakų. Dėl išsamumo, Patrick taip pat įdėjo savo norimą mąstymą į praktiką, naršydamas atsarginių atsarginių nuotraukų katalogą. Jis liko tuščias, nes vienas iš Patrick pradinių vykdomųjų sprendimų buvo taupyti laiką ir pinigus nenustatydamas jokių periodinių atsarginių kopijų procedūrų. Kaip duomenų praradimas atsitiko jam, visiems žmonėms? Ištyręs savo pasirinktos duomenų bazės nuoseklumo modelį, Patrickas suprato, kad yra sutarimas tarp nuoseklumo garantijų, našumo ir prieinamumo. Konfigūruojant užklausas, galima arba reikalauti linearizabilityFootnote7 sumažėjusio pralaidumo sąnaudomis, arba sumažinti nuoseklumo garantijas ir atitinkamai padidinti našumą. Didesnės pralaidumo galimybės Patrickui prieš kelias dienas buvo beprasmės, bet galiausiai kliento duomenys nusileido viename serveryje be jokių sistemoje paskirstytų kopijų. Patrick’s Diary of Lessons Learned, Part III Patrick's Diary of Lessons Learned, III dalis Kitos pamokos apima: Atsarginės kopijos yra gyvybiškai svarbios paskirstytoje aplinkoje, ir nėra tokio dalyko, kaip nustatyti atsargines kopijas "per greitai". sistemos nepavyksta, o atsarginės kopijos yra atkurti kuo daugiau svarbių duomenų. Kiekviena duomenų bazės sistema turi tam tikrą nuoseklumo modelį, ir svarbu tai atsižvelgti projektuojant savo projektą. gali būti kompromisų. Kai kuriais naudojimo atvejais (galvokite apie finansines sistemas), nuoseklumas yra raktas. „Spike“ vėl streikuoja Su reguliariais atsarginėmis kopijomis, persvarstytu nuoseklumo modeliu ir priminimu, įtrauktu į jo kalendorių kovo 16 d., kad padidintų klasterį, kad galėtų valdyti padidėjusį srautą, jis jautėsi vidutiniškai saugus. Jei tik jis žinotų, kad dešimties sekundžių vaizdo įrašas apie katę, apsirengusią leprechaunu, ką tik tapo virusu Malaizijoje ... kuris, atsižvelgiant į laiko juostą, įvyko maždaug 2 val. Patriko laiku, sugriovęs minėtas miego stabilizavimo pastangas. Viena vertus, stebėjimo rinkinys atliko savo darbą ir ankstyvą įspėjimą, leidžiantį greitai reaguoti. Kita vertus, net jei Patrickas reaguoja laiku, duomenų bazės retai sugeba iš karto išplėsti, o jo pasirinkta sistema šiuo atžvilgiu nebuvo išimtis. Konkurencijos viršūnė buvo labai didelė ir koncentruota, nes tūkstančiai Malaizijos paauglių skubėjo įsigyti žalias skrybėles, siekdami nuolat besikeičiančių interneto tendencijų. Su gražiai glausta formulė, L = λW, įstatymas gali būti supaprastintas į tai, kad sutapimas yra lygus perdavimo laiko latentiniam laikui. Mažojo įstatymas Tiems, kurie turi sunkumų prisiminti formulę, pagalvokite apie vienetus. Konkurencija yra tik skaičius, vėlavimas gali būti matuojamas sekundėmis, o pralaidumas paprastai išreiškiamas 1/s. Tada priežastis yra ta, kad norint, kad vienetai atitiktų, sutapimas turėtų būti gautas padauginus vėlavimą (sekundes) iš pralaidumo (1/s). TIP: Tipų : Perdavimas priklauso nuo techninės įrangos ir natūraliai turi savo ribas (pvz., Jūs negalite tikėtis, kad NVMe diskas, įsigytas 2023 m., Jums tarnaus duomenimis terabaitais per sekundę, nors mes peržengiame pirštus, kad ši prielaida būtų panaikinta artimiausioje ateityje!) Kartą, kai riba pasiekiama, galite ją traktuoti kaip pastovią formulėje. Tada aišku, kad, kai padidėja konkurencingumas, taip pat ir vėlavimas. Galutiniams vartotojams – Malaizijos paaugliams šiame scenarijuje – tai reiškia, kad vėlavimas galiausiai peržengs magišką barjerą vidutiniam žmogaus suvokimui kelias sekundes. Kai tai atsitiks, vartotojai tampa pernelyg nusivylę ir tiesiog ats Patrick’s Diary of Lessons Learned, Part IV Patriko pamokų dienoraštis, IV dalis Pamokos tęsiasi toliau: Netikėtumai yra neišvengiami, o klasterio išplėtimas gali būti nepakankamai greitas, kad būtų sušvelnintas neigiamas pernelyg didelio konkurencingumo poveikis. Tikėtis, kad duomenų bazė tinkamai elgsis su juo, nėra beprasmiška, tačiau ne kiekviena duomenų bazė gali tai padaryti. Jei įmanoma, kuo greičiau apriboti konkurencingumą savo sistemoje. Pavyzdžiui, jei duomenų bazę niekada tiesiogiai nepalies klientai (tai yra labai gera idėja dėl daugelio priežasčių), bet vietoj to prieinama per jūsų kontroliuojamas mikroservices, įsitikinkite, kad mikroservices taip pat žino apie konkurencingumo ribas ir laikosi jų. Turėkite omenyje, kad "Little's Law" egzistuoja - tai yra pagrindinės žinios visiems, kurie domisi paskirstytomis sistemomis. Backup Strikes atgal Po to, kai dar kartą persvarstė savo projektą, kad būtų atsižvelgta į numatytus ir netikėtus valiutos svyravimus, Patrickas laimingai laukė, kol jo fedora verslas pagaliau taps pelningas. Deja, kovo 17 d. taip pat nevyko taip sklandžiai, kaip tikėtasi. Patrick praleido didžiąją dienos dalį mėgaudamasis pastoviomis Grafana valdymo plokštėmis, kurios nuolat jam užtikrino, kad srautas buvo kontroliuojamas ir galintis tvarkyti klientų apkrovą, turėdamas sveiką saugią maržą. Bet tada valdymo plokštės sustojo, maloniai paminėdamas, kad diskai tapo labai pernelyg naudojami. Tai atrodė visiškai netinkama, atsižvelgiant į pastebėtą vienodumą. Ieškodamas galimo šios anomalijos šaltinio, Patrick pastebėjo, kad jo siaubas, kad suplanuota atsarginės kopijos procedūra sutampa su metine didžiausia apkrova... Patrick’s Diary of Lessons Learned, Part V Patriko pamokų dienoraštis, V dalis Baigiamosios mintys: Duomenų bazės sistemos retai kada būna tuščios, net ir be gaunamų vartotojo užklausų. Kai tik įmanoma, suplanuokite techninės priežiūros galimybes laikotarpiams, kai numatomas mažas slėgis sistemoje. Jei jūsų duomenų bazės valdymo sistema palaiko bet kokią kokybės paslaugų konfigūraciją, gera idėja ištirti tokias galimybes. Pavyzdžiui, gali būti įmanoma nustatyti stiprią naudotojų užklausų prioritetą, palyginti su įprastomis techninės priežiūros operacijomis, ypač aukščiausiomis valandomis. Atitinkamai, laikotarpiai su maža naudotojo sukelta veikla gali būti naudojami pagreitinti fone vykdomą veiklą. Duomenų bazės pasaulyje, sistemoms, kurios naudoja pagrindinio saugojimo LSM medžių variantą, reikia atlikti nemažai suspaudimų (duomenų techninės priežiūros operacijų rūšis), kad skaitymo ir rašymo našumas būtų nuspėjamas ir pastovus. ir pabaiga. Apie Piotr Sarna yra programinės įrangos inžinierius, kuris domisi atviro kodo projektais ir Rust ir C++ kalbomis. Jis anksčiau sukūrė atviro kodo paskirstytą failų sistemą ir turėjo trumpą nuotykį su Linux branduoliu per pamoką „Samsung Electronics“. Jis taip pat yra ilgalaikis ScyllaDB, taip pat libSQL prisidėjėjas ir tvarkytojas. Piotr baigė Varšuvos universitetą su kompiuterių mokslo magistrantūra. Jis yra knygų „Database Performance at Scale“ ir „Writing for Developers: Blogs that Get Read“ bendraautorius. Petras
