Перформансе базе података су озбиљни послови, али зашто се не забавите истражујући његове изазове и сложености? 😉 Ево прилично фантастичне приче коју смо представили у поглављу 1. . Database Performance at Scale, бесплатна књига отвореног приступа Перформансе базе података на скали Перформансе базе података на скали Техничке теме које су овде обухваћене проширене су током читаве књиге. Али ово је једини пут када говоримо о сиромашном Патрику. Нека вам његове борбе донесу неке вриједне лекције, утеху у сопственим предсказањима перформанси базе података ... и можда и неколико смеша. *** Овде Након што је изгубио посао у компанији ФААНГ МААНГ (МАНГА?) , Патрик је одлучио да се повуче сам и основао нишу онлине продавницу посвећену трговини његовом апсолутном омиљеном међу главом, зеленим федорама. Након неких експеримената са бесплатним нивоом понуде, Патрик је одлучио да потпише једногодишњи уговор са великим пружаоцем облака како би добио значајан попуст на своју понуду базе података НоСКЛ-а као услуге. Са предвиђеним пролазом који може да служи до 1.000 купаца сваке секунде, технолошки стек је био спреман и продавница је отворила своја виртуелна врата за купце. На Патриково разочарање, мање од десет купаца је свакодневно посетило сајт. У исто време, сјајан нови кластер база података је наставио да ради, напајајући стални прилив новца са своје кредитне картице и чекајући да се његов потенцијал искористи. Patrick’s Diary of Lessons Learned, Part I Патриков дневник научених лекција, део I Предавања су одмах почела: Iako se neke baze podataka oglašavaju kao univerzalne, većina njih najbolje funkcioniše za određene vrste radnih opterećenja.Analiza pre odabira baze podataka za svoje potrebe mora da uključuje procenu karakteristika sopstvenog radnog opterećenja: Да ли је вероватно да ће бити предвидљив, сталан ток захтјева (нпр, ажурирања се периодично преузимају из других система)? Да ли је варијанта висока и тешка за предвиђање, са потенцијално дугим временским периодима, са повременим прекидима активности? Понуде базе података-као-услуге често вам омогућавају да изаберете између предвиђеног пропуста и куповине на захтев. Иако је први економичнији, наноси одређени трошак без обзира на то колико је база података заправо заузета. Дајте себи времена да процените свој избор и избегнете обавезу на дугорочне уговоре (чак и ако вас привуче попуст) пре него што видите да подешавање ради за вас на одрживи начин. Први спајк 17. март је изгледао као изузетно срећан дан. Патрик је био задовољан што је уочио пуно нових налога почевши од раног јутра. Али пошто је број активних купаца порастао око подне, Патриково расположење је почело да се погоршава. Ово је строго корелирало са стопом позива које је примио од љутих купаца који су пријавили њихову немогућност да настави са својим налогама. Nakon kratke brainstorming sesije sa samim sobom i web pretraživačem, Patrik je shvatio da mu nedostaje bilo kakav alat za posmatranje na svom dragocenom (i prilično skupom) bazom podataka.Kratko nakon što je franticno postavio Grafanu i pretraživao metriku, Patrik je video da iako broj dolaznih zahteva i dalje raste, njihova stopa uspeha je ograničena na određenom nivou, daleko ispod današnjeg očekivanog saobraćaja. "Предвиђени проток удара поново", Патрицк се жалио, док је прокрућивао хиљаде порука о грешци "превазишао проток" који су почели да се појављују око 11 ујутро. Patrick’s Diary of Lessons Learned, Part II Патриков дневник научених лекција, 2. део Evo šta je Patrik naučio: Ako je vaše radno opterećenje podložno špicima, budite spremni na to i pokušajte da arhitektonizujete svoj klaster tako da može da izdrži privremeno povišeno opterećenje.Razlozi baze podataka kao usluge obično omogućavaju dinamičnu konfiguraciju predviđenog kapaciteta, što znači da se prag prihvaćenih zahteva povremeno može privremeno podići na nivo koji je prethodno konfigurisan. Чак и ако је ваше радно оптерећење апсолутно стабилно, привремени хардверски неуспех или изненадни ДДоС напад може изазвати оштар пораст долазних захтјева. Посматрање је кључно у дистрибуираним системима. Омогућава програмерима да ретроспективно истражују неуспјех. Такође пружа упозорења у реалном времену када се открије вероватно сценарио неуспјеха, омогућавајући људима да брзо реагују и или спрече већи неуспјех, или бар минимизирају негативан утицај на кластер. Први губитак Патрицк није ни успео да се опорави од трауме да изгуби већину свог потенцијалног прихода на једини дан током целе године током којег зелена федора доживљава било какву потражњу, када је писмо стигло.Укључује љутњу од бившег купца, који је успјешно наставио са својим налогом и платио га (са рачуном од оператера за обраду плаћања као доказ), али сада није у стању ни да види било какве детаље његовог налога - и још увек чека испоруку! Без даљег ометања, Патрик је прегледао базу података. На његово изненађење, није нашао ни траг наредбе. За потпуност, Патрик је такође ставио своје жељене размишљања у праксу прегледањем директоријума резервних снимака. То је остало празно, јер је једна од Патрикова почетних извршних одлука била да уштеди време и новац не планирајући никакве периодичне процедуре резервне копије. Како се губитак података догодио њему, свим људима? Након проучавања модела конзистентности своје одабране базе података, Патрик је схватио да постоји консензус између гаранција конзистентности, перформанси и доступности. Конфигурисањем упита, може се или захтевати линеаризабилностФоотноте7 по цијени смањеног пропусног капацитета, или смањити гаранције конзистентности и повећати перформансе у складу с тим. Више могућности пропусног капацитета биле су за Патрика пре неколико дана, али на крају подаци клијената слетели су на један сервер без икаквих реплика дистрибуираних у систему. Patrick’s Diary of Lessons Learned, Part III Патриков дневник научених лекција, 3. део Додатне лекције укључују: Резервне копије су од виталног значаја у дистрибуираном окружењу, а не постоји таква ствар као што је постављање рутина за резервну копију "превише брзо". Сваки систем базе података има одређени модел конзистентности, и кључно је узети то у обзир приликом пројектовања вашег пројекта. Можда ће бити компромиса. У неким случајевима употребе (мислите на финансијске системе), конзистентност је кључна. Spike ponovo napada Месеци су пролазили и Патрикови распоред спавања је чак почео да показује знаке стабилизације.Са редовним резервним копијама, редизајнираним моделом конзистентности и подсетником постављеним у његовом календару за 16. март да повећа кластер како би управљао повишеним саобраћајем, осећао се умерено безбедно. Да је само знао да је десет-секундни видео мачке обучене као лепрецхаун управо постао вирусан у Малезији ... што се, узимајући у обзир временску зону, догодило око 2 ујутро Патрика, уништавајући горе поменуте напоре за стабилизацију сна. С једне стране, пакет посматрања је урадио свој посао и покренуо упозорење рано, што је омогућило брз одговор. С друге стране, иако је Патрик реаговао на време, базе података ретко могу да се размјене тренутно, а његов систем избора није био изузетак у том погледу. Пик у конкуренцији је био веома висок и концентрисан, јер су хиљаде малезијских тинејџера журиле да купују зелене шешире у потрази за стално мењајућим трендовима Интернета. Уз прелепо концизну формулу, Л = λВ, закон се може поједноставити на чињеницу да је конкурентност једнака латенцији времена пропуста. Мали закон За оне који имају проблема са памћењем формуле, размислите о јединицама. Конкуренција је само број, латенција се може мерити у секундима, док се проток обично изражава у 1/с. Тип : Тип : Пропуст зависи од хардвера и, наравно, има своје границе (нпр., не можете очекивати да НВМе диск купљен 2023. године служи подацима за вас у терабајтима по секунди, иако ми прелазимо прсте да би ова претпоставка била неважећа у блиској будућности!) Једном када је ограничење погођено, можете га третирати као констант у формули. Тада је јасно да како се конкуренција повећава, тако и латенција. За крајње кориснике – малезијске тинејџере у овом сценарију – то значи да ће латенција на крају прећи магичну баријеру за просечну људску перцепцију од неколико секунди. Када се то деси, корисници постају превише фрустрирани и једноставно одустају од покушаја у целини, прет Patrick’s Diary of Lessons Learned, Part IV Патриков дневник научених лекција, 4. део Лекције се настављају: Неочекивани врхови су неизбежни, а скалирање кластера можда неће бити довољно брзо да ублажи негативне ефекте прекомерне конвергенције. Очекивање да се база података правилно носи са њом није без заслуге, али није свака база података способна за то. Ако је могуће, ограничите конвергенцију у вашем систему што је пре могуће. На пример, ако се база података никада не додирује директно од стране купаца (што је врло добра идеја из више разлога), али уместо тога приступа кроз скуп микро-услуга под вашом контролом, уверите се да су микро-услуге такође свјесне ограничења конвергенције и придржавају се њих. Имајте на уму да Мали закон постоји - то је основно знање за свакога ко је заинтересован за дистрибуиране системе. Backup Strikes Назад Након што је поново редизајнирао свој пројекат како би узео у обзир очекиване и неочекиване флуктуације истовремене валуте, Патрик је срећно чекао да његов бизнис са федором коначно постане профитабилан. Нажалост, следећи 17. март није ишао тако глатко као што се очекивало. Патрик је провео већину дана уживајући у стабилним Графана таблама, што га је стално уверавало да је саобраћај под контролом и способан да се носи са оптерећењем купаца, са здравом сигурносном маргином. Али онда су табла престала, љубазно помињући да су дискови постали озбиљно претерано коришћени. Ово се чинило потпуно ван мјеста с обзиром на посматрану конкуренцију. Док је тражио могући извор ове аномалије, Патрик је приметио, на свој ужас, да је заказана процедура резервне копије поклапала са годишњим врхунским оптерећењем... Patrick’s Diary of Lessons Learned, Part V Патриков дневник научених лекција, 5. део Завршне мисли : Системи базе података су ретко никада празни, чак и без долазних захтева корисника. операције одржавања често се дешавају и морате их узети у обзир јер су они унутрашњи извор истовремене и потрошње ресурса. Kad god je moguće, rasporedite opcije održavanja za vreme očekivanog niskog pritiska na sistemu. Ako vaš sistem za upravljanje bazama podataka podržava bilo koju vrstu konfiguracije kvaliteta usluge, dobra je ideja da istražite takve mogućnosti. Na primer, možda je moguće da postavite snažan prioritet za korisničke zahteve u odnosu na redovne operacije održavanja, posebno tokom vrhunskih sati. Na kraju . Руте у Piotr Sarna је софтверски инжењер који се бави пројектима отвореног кода и језицима Rust и C++. Раније је развио дистрибуирани датотечни систем отвореног кода и имао је кратку авантуру са Линук језгром током стажирања у Самсунг Елецтроницс-у. Такође је дугогодишњи доприносилац и одржавач СциллаДБ-а, као и либСкЛ-а. Пиотр је дипломирао са Универзитета у Варшави са магистром из компјутерске науке. Петар
