Перформансите на базата на податоци се сериозен бизнис, но зошто да не се забавувате малку истражувајќи ги неговите предизвици и сложености? 😉 Еве една прилично фантастична приказна што ја презентиравме во Поглавје 1 од . Performance at Scale, бесплатна книга со отворен пристап Перформанси на базата на податоци во скала Перформанси на базата на податоци во скала Техничките теми што се опфатени тука се прошируваат низ целата книга. но ова е единствениот пат кога зборуваме за сиромашниот Патрик. Нека неговите борби ви донесат некои вредни лекции, утеха во сопствените предлози за перформансите на вашата база на податоци ... и можеби и неколку шеги. * на По губењето на работата во компанијата FAANG MAANG (MANGA?) , Патрик одлучил сам да се откаже и основал ниша онлајн продавница посветена на тргување со неговиот апсолутен омилен меѓу чевли, зелени федори. По некое експериментирање со бесплатната понуда, Патрик одлучи да потпише едногодишен договор со голем давател на облак за да добие значителен попуст на својата понуда на NoSQL база на податоци како услуга. Со предвидениот промет способен да служи до 1.000 клиенти секоја секунда, технологијата беше подготвена и продавницата ги отвори своите виртуелни врати за клиентите. За разочарување на Патрик, помалку од десет клиенти го посетуваа сајтот дневно. Во исто време, сјајниот нов кластер на бази на податоци продолжи да работи, напојуван од постојан прилив на пари од неговата кредитна картичка и чекајќи го својот потенцијал да биде искористен. Patrick’s Diary of Lessons Learned, Part I Дневник на Патрик за научените лекции, дел I Училиштето веднаш започна: Иако некои бази на податоци се рекламираат како универзални, повеќето од нив најдобро функционираат за одредени видови на работни оптоварувања.Анализата пред да изберете база на податоци за вашите сопствени потреби мора да вклучува проценка на карактеристиките на сопственото работно оптоварување: Дали е веројатно да има предвидлив, стабилен проток на барања (на пример, ажурирања кои периодично се преземаат од други системи)? Дали варијантата е висока и тешко е да се предвиди, со што системот е неподвижен за потенцијално долги временски периоди, со повремени бунтови на активност? Базата на податоци-како-услуга често ви овозможува да изберете помеѓу предвидениот проток и купувањето на побарувачка. Иако првиот е поефикасен во однос на трошоците, тоа предизвикува одредени трошоци без оглед на тоа колку е зафатена базата на податоци. Дајте си време да го процените вашиот избор и да избегнете да се обврзувате на долгорочни договори (дури и ако сте привлечени од попуст) пред да видите дека конфигурацијата работи за вас на одржлив начин. Првиот Spike 17 март се чинеше како исклучително среќен ден. Патрик бил среќен што забележал многу нови нарачки почнувајќи од рано наутро. Но, како што бројот на активни клиенти скокнал околу полноќ, расположението на Патрик почнало да се влошува. По кратка сесија за размислување со себе и со веб пребарувачот, Патрик сфати, за негово разочарување, дека му недостасуваат алатки за набљудување на неговиот скап (и прилично скап) збир на бази на податоци. „Предвидениот проток напаѓа повторно“, се жалеше Патрик, додека се движеше низ илјадници пораки за грешка „проток надмина“ кои почнаа да се појавуваат околу 11 часот наутро. Patrick’s Diary of Lessons Learned, Part II Дневник на Патрик за научените лекции, дел II Еве што научил Патрик: Ако вашето работно оптоварување е подложно на врвови, бидете подготвени за тоа и обидете се да го архитектирате вашиот кластер за да може да преживее привремено зголемено оптоварување. Решенијата за база на податоци како услуга имаат тенденција да овозможат конфигурирање на предвидениот проток на динамичен начин, што значи дека прагот на прифатените барања понекогаш може да се подигне привремено на претходно конфигурирано ниво. Дури и ако вашето работно оптоварување е апсолутно стабилно, привремениот хардверски неуспех или изненадувачки DDoS напад може да предизвика нагло зголемување на влезните барања. Набљудувањето е клучно во дистрибуираните системи. Тоа им овозможува на програмерите ретроспективно да истражуваат неуспех. Исто така, обезбедува предупредувања во реално време кога се открива веројатно сценарио за неуспех, овозможувајќи им на луѓето брзо да реагираат и или да спречат поголем неуспех да се случи, или барем да го минимизираат негативното влијание врз кластерот. Првата загуба Патрик дури и не успеа да се опорави од траумата на губење на најголем дел од својот потенцијален приход на единствениот ден во текот на годината во кој зелените федори доживеале било каков вид на побарувачка, кога дојде писмото. Без понатамошно пребарување, Патрик ја пребарувал базата на податоци. На негово изненадување, тој исто така не пронашол никакви траги од нарачката. За комплетност, Патрик, исто така, го стави своето желно размислување во пракса со пребарување во директориумот за резервни слики. Тоа остана празно, бидејќи една од првичните извршни одлуки на Патрик беше да заштеди време и пари со тоа што не планираше никакви периодични процедури за резервна копија. По проучувањето на моделот за конзистентност на базата на податоци по негов избор, Патрик сфати дека постои консензус помеѓу гаранциите за конзистентност, перформансите и достапноста. Со конфигурирање на прашањата, може да се побара линеаризабилностФотоноте7 по цена на намалениот проток, или да се намалат гаранциите за конзистентност и да се зголеми перформансите соодветно. Повисоките капацитети за проток беа безгрижни за Патрик пред неколку дена, но на крајот податоците на клиентите слетаа на еден сервер без никакви реплики дистрибуирани во системот. Patrick’s Diary of Lessons Learned, Part III Дневник на Патрик за научените лекции, дел 3 Дополнителни лекции вклучуваат: Резервните копии се од суштинско значење во дистрибуирана средина, и не постои такво нешто како поставување на рутини за резервна копија „премногу брзо“. Секој систем на база на податоци има одреден модел на конзистентност, и тоа е од клучно значење да се земе предвид при дизајнирањето на вашиот проект. Може да има компромиси да се направи. Во некои случаи на употреба (мисли финансиски системи), конзистентноста е клучот. Во други, конечната конзистентност е прифатлива, се додека го одржува системот високо достапен и одговорен. Шпанецот повторно штрајкува Со редовни резервни копии, редизајниран модел на конзистентност и потсетник поставен во неговиот календар за 16 март за да го прошири кластерот за да управува со зголемениот сообраќај, тој се чувствува умерено безбеден. Ако само знаеше дека видеото од десет секунди на мачка облечена како лепречанка само што стана вирусно во Малезија... што, земајќи ги предвид временските зони, се случило околу 2 часот наутро, уништувајќи ги споменатите напори за стабилизација на спиењето. Од една страна, пакетот за набљудување ја изврши својата работа и започна рано предупредување, овозможувајќи брз одговор. Од друга страна, иако Патрик реагираше на време, базите на податоци ретко се способни да се скали веднаш, а неговиот систем на избор не беше исклучок во врска со тоа. Врвот во конкуренцијата беше многу висок и концентриран, бидејќи илјадници малезиски тинејџери брзаа да купат зелени шешири во потрага по постојано менување на интернет трендовите. Со убаво концизна формула, L = λW, законот може да се поедностави на фактот дека конкурентноста е еднаква на времетраењето на пропустот. Малиот закон За оние кои имаат потешкотии да се сеќаваат на формулата, размислете за единици. Конкуренцијата е само број, латенцијата може да се измери во секунди, додека пропустот обично се изразува во 1/s. Тогаш, се разбира дека за да се совпаднат единиците, треба да се добие конкуренција со множење на латенцијата (секунди) со пропустот (1/s). Тип : Тип : Пропуштањето зависи од хардверот и природно има свои граници (на пример, не можете да очекувате NVMe диск купен во 2023 година да ви ги служи податоците во терабајти во секунда, иако ние ги прекршуваме прстите за оваа претпоставка да биде невалидирана во блиска иднина!) Откако лимитот е погоден, можете да го третирате како константа во формулата. Тогаш е јасно дека како што се зголемува concurrency, така и латенцијата. За крајните корисници – малезиските тинејџери во овој сценарио – тоа значи дека латенцијата на крајот ќе ја премине магичната бариера за просечната човечка перцепција од неколку секунди. Откако тоа се случи, корисниците стануваат премногу фрустрирани и едноставно се откажуваат од обидот целосно Patrick’s Diary of Lessons Learned, Part IV Дневник на Патрик за научените лекции, дел IV Лекциите продолжуваат: Неочекуваните врвови се неизбежни, а проширувањето на кластерот не може да биде доволно брзо за да се намалат негативните ефекти на прекумерната конкуренција. Очекувањето од базата да се справи со неа правилно не е без заслуга, но не секоја база на податоци е способна за тоа. Ако е можно, ограничете ја конкуренцијата во вашиот систем што е можно поскоро. На пример, ако базата на податоци никогаш не е директно допрена од страна на клиентите (што е многу добра идеја од неколку причини), но наместо тоа е пристапна преку сет на микро-услуги под ваша контрола, осигурајте се дека микро-услугите исто така се свесни за ограничувањата на конкуренцијата и се придржуваат до нив. Имајте на ум дека Законот на Мали постои – тоа е фундаментално знаење за секој кој е заинтересиран за дистрибуирани системи. Заштитниот удар се враќа По редизајнирањето на неговиот проект уште еднаш за да се земат предвид очекуваните и неочекуваните флуктуации на истовремена валута, Патрик среќно чекаше неговиот бизнис на fedora конечно да стане ремен профитабилен. За жал, следниот 17-ти март не се одвиваше како што се очекуваше. Патрик поголемиот дел од денот го поминуваше уживајќи во стабилните табла на Графана, што го увери дека сообраќајот е под контрола и способен да се справи со товарот на клиентите, со здрава безбедна маржа. Но, потоа таблата престана, љубезно споменувајќи дека дисковите станаа сериозно претерано користени. Ова изгледаше целосно надвор од место, со оглед на забележаната конвергенција. Додека бараше можен извор на оваа аномалија, Патрик забележа, на неговиот ужас, дека закажаната процедура за резервна копија се совпадна со годишниот врв на товарот... Patrick’s Diary of Lessons Learned, Part V Дневникот на Патрик за научените лекции, дел V Завршни мисли : Операциите за одржување често се случуваат и мора да ги земете предвид, бидејќи тие се внатрешен извор на истовремена валута и потрошувачка на ресурси. Секогаш кога е можно, закажете опции за одржување за времиња со очекуваниот низок притисок на системот. Ако вашиот систем за управување со бази на податоци поддржува било каков вид на квалитетна конфигурација на услуги, добра идеја е да се испитаат таквите можности. На пример, може да биде можно да се постави силен приоритет за барањата на корисниците во однос на редовните операции за одржување, особено за време на врвните часови. Соодветно, периодите со ниска активност предизвикана од корисникот може да се користат за да се забрзаат активностите во позадина. Во светот на базата на податоци, системите кои користат варијанта на LSM дрвја за основно складирање треба да изведат доста компресии (нешто како операција за одржување на податоците) за да се задржи перформансите за читање/пишување предвидливи и стабилни. на крајот. Поглед на Piotr Sarna е софтверски инженер кој е заинтересиран за проекти со отворен код и за јазиците Rust и C++. Претходно развил дистрибуиран датотечен систем со отворен код и имал кратка авантура со Linux јадрото за време на обуката во Samsung Electronics. Тој е исто така долгогодишен придонесник и одржувач на ScyllaDB, како и libSQL. Piotr дипломирал на Универзитетот во Варшава со магистер по компјутерски науки. Тој е соавтор на книгите „Database Performance at Scale“ и „Writing for Developers: Blogs that Get Read“. Петар
