Негде у далекој будућности, аутоматско уклањање непотребних података биће један од важних задатака ДБМС-а [1]. У међувремену, ми сами треба да се побринемо за брисање или премештање непотребних података у јефтиније системе за складиштење. Рецимо да сте одлучили да избришете неколико милиона редова. Прилично једноставан задатак, посебно ако је услов познат и постоји одговарајући индекс. „ИЗБРИШИ ИЗ табеле1 ВХЕРЕ цол1 = :валуе“ – шта би могло бити једноставније, зар не?
Видео:
-
У програмском комитету Хигхлоад сам од прве године, односно од 2007. године.
-
А у Постгресу сам од 2005. године. Користио се у многим пројектима.
-
Групирајте са РуПостгес такође од 2007.
-
Порасли смо на 2100+ учесника на Меетуп-у. Други је у свету после Њујорка, дуго га је претекао Сан Франциско.
-
Живим у Калифорнији неколико година. Више се бавим америчким компанијама, укључујући и велике. Они су активни корисници Постгреса. И има свакаквих занимљивих ствари.
је моја компанија. Бавимо се аутоматизацијом задатака који елиминишу успоравање развоја.
Ако нешто радите, понекад постоје некакви утикачи око Постгреса. Рецимо да треба да сачекате да администратор постави тестно постоље за вас или да сачекате да вам ДБА одговори. А таква уска грла налазимо у процесу развоја, тестирања и администрације и покушавамо да их отклонимо уз помоћ аутоматизације и нових приступа.
Недавно сам био у ВЛДБ-у у Лос Анђелесу. Ово је највећа конференција о базама података. И постојао је извештај да ће у будућности ДБМС не само чувати, већ и аутоматски брисати податке. Ово је нова тема.
Све је више података у свету зетабајта – то је 1 петабајта. А сада се већ процењује да имамо више од 000 зетабајта података ускладиштених у свету. А таквих је све више.
И шта с тим? Очигледно је потребно уклонити. Ево линка до овог занимљивог извештаја. Али до сада ово није имплементирано у ДБМС.
Они који умеју да броје новац желе две ствари. Желе да их избришемо, па би технички требало да будемо у могућности да то урадимо.
Оно што ћу следеће рећи је нека апстрактна ситуација која укључује гомилу стварних ситуација, односно неку врсту компилације онога што се мени и околним базама података догодило много пута, много година. Грабуље су свуда и сви стално газе.
Рецимо да имамо базу или неколико база које расту. А неки записи су очигледно смеће. На пример, корисник је почео да ради нешто тамо, али то није завршио. И после неког времена знамо да се ово недовршено више не може чувати. Односно, желели бисмо да очистимо неке ствари за смеће како бисмо уштедели простор, побољшали перформансе итд.
Генерално, задатак је аутоматизовати уклањање одређених ствари, одређених линија у некој табели.
И ми имамо такав захтев, о коме ћемо данас, односно о уклањању смећа.
Замолили смо искусног програмера да то уради. Узео је овај захтев, проверио за себе - све ради. Тестирано на инсценацији - све је у реду. Разваљен - све ради. Једном дневно га покрећемо - све је у реду.
База података расте и расте. Дневни ДЕЛЕТЕ почиње да ради мало спорије.
Онда схватимо да сада имамо маркетиншку компанију и да ће промет бити неколико пута већи, па одлучујемо да привремено паузирамо непотребне ствари. И заборави да се вратиш.
Неколико месеци касније сетили су се. И тај програмер је дао отказ или је заузет нечим другим, наложио је другом да то врати.
Проверио је дев, инсценацију - све је у реду. Наравно, још увек треба да очистите оно што се накупило. Проверио је да све ради.
Шта се даље дешава? Тада нам се све распада. Пада тако да у неком тренутку све падне. Сви су у шоку, нико не разуме шта се дешава. А онда се испостави да је ствар била у овом БРИСАЊУ.
Нешто није у реду? Ево листе онога што је могло поћи наопако. Шта је од ових најважнијих?
-
На пример, није било прегледа, односно ДБА стручњак га није погледао. Искусним оком би одмах пронашао проблем, а осим тога, има приступ прод, где се накупило неколико милиона редова.
-
Можда су проверили нешто погрешно.
-
Можда је хардвер застарео и морате да надоградите ову базу.
-
Или нешто није у реду са самом базом података и морамо да пређемо са Постгреса на МиСКЛ.
-
Или можда нешто није у реду са операцијом.
-
Можда има грешака у организацији посла и треба некога отпустити и запослити најбоље људе?
Није било ДБА провере. Да постоји ДБА, видео би ових неколико милиона редова и чак без икаквих експеримената рекао би: „Они то не раде“. Претпоставимо да је овај код био у ГитЛаб-у, ГитХубу и да би постојао процес прегледа кода и да не постоји таква ствар да би се ова операција без одобрења ДБА одвијала на прод-у, онда би очигледно ДБА рекао: „Ово се не може урадити .”
И рекао би да ћете имати проблема са ИО диском и сви процеси ће полудети, можда ће бити закључавања, а такође ћете блокирати аутовакуум на гомилу минута, тако да ово није добро.
Друга грешка - проверили су на погрешном месту. Видели смо након чињенице да се много нежељених података накупило на прод-у, али програмер није имао акумулиране податке у овој бази података, и нико није направио ово смеће током постављања. Сходно томе, било је 1 линија које су брзо функционисале.
Разумемо да су наши тестови слаби, тј. процес који је изграђен не открива проблеме. Адекватан ДБ експеримент није изведен.
Идеалан експеримент се пожељно изводи на истој опреми. Није увек могуће то урадити на истој опреми, али је веома важно да то буде копија базе података у пуној величини. То је оно што проповедам већ неколико година. И пре годину дана сам причао о овоме, све то можете погледати на Јутјубу.
Можда нам је опрема лоша? Ако погледате, онда је кашњење скочило. Видели смо да је искоришћеност 100%. Наравно, да су ово модерни НВМе дискови, онда би нам вероватно било много лакше. А можда и не бисмо легли од тога.
Ако имате облаке, онда се надоградња тамо лако врши. Подигнуте нове реплике на новом хардверу. заменити. И све је у реду. Прилично лако.
Да ли је могуће некако додирнути мање дискове? И овде, само уз помоћ ДБА, улазимо у одређену тему која се зове подешавање контролне тачке. Испоставило се да нисмо имали подешавање контролног пункта.
Шта је контролни пункт? Има га у било ком ДБМС-у. Када имате податке у меморији који се мењају, они се не записују одмах на диск. Информација да су подаци промењени прво се уписују у дневник уписивања унапред. И у неком тренутку, ДБМС одлучује да је време да се праве странице баци на диск, тако да ако имамо квар, можемо мање да урадимо РЕДО. То је као играчка. Ако погинемо, игру почињемо са последњег контролног пункта. И сви ДБМС то имплементирају.
Подешавања у Постгресу заостају. Дизајнирани су за количине података и трансакција старе 10-15 година. И контролни пункт није изузетак.
Ево информација из нашег Постгрес извештаја о контроли, односно аутоматске провере здравља. А ево и неке базе података од неколико терабајта. И добро се види да су присилни пунктови у скоро 90% случајева.
Шта то значи? Постоје две поставке. Контролна тачка може доћи до истека, на пример, за 10 минута. Или може доћи када се попуни доста података.
И подразумевано је мак_вал_сазе подешен на 1 гигабајт. У ствари, ово се заиста дешава у Постгресу након 300-400 мегабајта. Променили сте толико података и ваша контролна тачка се догодила.
А ако га нико није подесио, а услуга је расла, а компанија зарађује много новца, има много трансакција, онда контролни пункт долази једном у минуту, понекад сваких 30 секунди, а понекад се чак и преклапају. Ово је прилично лоше.
И морамо да се побринемо да то долази ређе. То јест, можемо повећати мак_вал_сизе. И долазиће ређе.
Али развили смо читаву методологију како да то урадимо исправније, односно како да донесемо одлуку о избору подешавања, јасно на основу конкретних података.
Сходно томе, радимо две серије експеримената на базама података.
Прва серија - мењамо мак_вал_сизе. И радимо огромну операцију. Прво, то радимо на подразумеваној поставци од 1 гигабајта. И радимо масовно БРИСАЊЕ много милиона редова.
Видите колико нам је тешко. Видимо да је ИО диска веома лош. Гледамо колико смо ВАЛ-ова генерисали, јер је ово веома важно. Да видимо колико пута се контролни пункт десио. И видимо да није добро.
Затим повећавамо мак_вал_сизе. Понављамо. Повећавамо, понављамо. И толико пута. У принципу, 10 поена је добро, где је 1, 2, 4, 8 гигабајта. И посматрамо понашање одређеног система. Јасно је да овде опрема треба да буде као на прод. Морате имати исте дискове, исту количину меморије и иста Постгрес подешавања.
И на овај начин ћемо разменити наш систем, а знамо како ће се ДБМС понашати у случају лошег масовног ДЕЛЕТЕ-а, како ће да контролише.
Контролни пункт на руском су контролни пунктови.
Пример: ИЗБРИШИ неколико милиона редова по индексу, редови су „разбацани“ по страницама.
Ево примера. Ово је нека база. А са подразумеваном поставком од 1 гигабајта за мак_вал_сизе, врло је јасно да наши дискови иду на полицу за снимање. Ова слика је типичан симптом веома болесног пацијента, односно заиста се осећао лоше. И постојала је једна једина операција, било је само ДЕЛЕТЕ од неколико милиона редова.
Ако је таква операција дозвољена у прод, онда ћемо само да легнемо, јер је јасно да нас један ДЕЛЕТЕ убија у пуку.
Даље, где је 16 гигабајта, јасно је да су зуби већ отишли. Зуби су већ бољи, односно куцамо у плафон, али не тако лоше. Тамо је било неке слободе. На десној страни је запис. И број операција - други графикон. И јасно је да већ мало лакше дишемо када 16 гигабајта.
И где се 64 гигабајта види да је постало потпуно боље. Зуби су већ изражени, има више могућности да преживите друге операције и урадите нешто са диском.
Зашто тако?
Мало ћу заронити у детаље, али ова тема, како се врши подешавање контролног пункта, може резултирати целим извештајем, тако да нећу много да учитавам, али ћу мало скицирати које потешкоће постоје.
Ако се контролна тачка дешава пречесто, и ажурирамо наше редове не секвенцијално, већ пронађемо по индексу, што је добро, јер не бришемо целу табелу, онда се може десити да смо прво додирнули прву страницу, па хиљадиту, а затим се вратио на прву . А ако је између ових посета првој страници контролна тачка већ сачувала на диск, онда ће је поново сачувати, јер смо је испрљали други пут.
И натераћемо контролни пункт да га сачува много пута. Како би за њега било сувишних операција.
Али то није све. Странице су 8 килобајта у Постгресу и 4 килобајта у Линуку. И постоји поставка фулл_паге_вритес. Подразумевано је омогућено. И то је тачно, јер ако га искључимо, онда постоји опасност да само половина странице буде сачувана ако се сруши.
Понашање писања у ВАЛ прослеђеног дневника је такво да када имамо контролну тачку и променимо страницу по први пут, цела страница, односно свих 8 килобајта, улази у дневник унапред, иако смо променили само линију, која тежи 100 бајтова. И морамо да запишемо целу страницу.
У наредним променама биће само одређена тупле, али по први пут све записујемо.
И, сходно томе, ако се контролни пункт поново десио, онда морамо поново све почети од нуле и гурнути целу страницу. Са честим контролним тачкама, када пролазимо кроз исте странице, фулл_паге_вритес = он ће бити више него што би могло бити, тј. генеришемо више ВАЛ-а. Више се шаље у реплике, у архиву, на диск.
И, сходно томе, имамо два вишка.
Ако повећамо мак_вал_сизе, испоставиће се да олакшавамо и контролну тачку и вал писца. И то је супер.
Хајде да ставимо терабајт и живимо са тим. Шта је лоше у томе? Ово је лоше, јер ћемо се у случају квара пењати сатима, јер је пункт био давно и много се већ променило. И све ово треба да урадимо РЕДО. И тако радимо другу серију експеримената.
Урадимо операцију и видимо када ће се контролни пункт завршити, намерно убијамо -9 Постгрес.
И након тога га поново покрећемо, и видимо колико ће дуго да расте на овој опреми, односно колико ће се ПОНОВИТИ у овој лошој ситуацији.
Двапут ћу приметити да је ситуација лоша. Прво, срушили смо се непосредно пре него што је контролни пункт завршен, тако да имамо много да изгубимо. И друго, имали смо велику операцију. А да су контролне тачке на временском ограничењу, онда би, највероватније, мање ВАЛ-а било генерисано од последње контролне тачке. То јест, то је двоструки губитник.
Такву ситуацију меримо за различите величине мак_вал_сизе и разумемо да ако је мак_вал_сизе 64 гигабајта, онда ћемо се у двоструко најгорем случају пењати 10 минута. И мислимо да ли нам то одговара или не. Ово је пословно питање. Ову слику треба да покажемо онима који су одговорни за пословне одлуке и запитамо се: „Колико дуго можемо највише да лежимо у случају проблема? Можемо ли да легнемо у најгорој ситуацији 3-5 минута? И ти доносиш одлуку.
И ево једне занимљиве тачке. Имамо неколико извештаја о Патронију на конференцији. И можда га користите. Ово је аутофаиловер за Постгрес. ГитЛаб и Дата Егрет су разговарали о томе.
А ако имате аутофаиловер који долази за 30 секунди, онда можда можемо да легнемо 10 минута? Јер ћемо до овог тренутка прећи на реплику и све ће бити у реду. Ово је спорна тачка. Не знам јасан одговор. Само осећам да ова тема није само око опоравка након пада.
Ако имамо дуг опоравак након неуспеха, онда ће нам бити непријатно у многим другим ситуацијама. На пример, у истим експериментима, када нешто радимо и понекад морамо да чекамо 10 минута.
И даље не бих ишао предалеко, чак и да имамо аутофаиловер. По правилу, вредности као што су 64, 100 гигабајта су добре вредности. Понекад је чак вредно изабрати мање. Генерално, ово је суптилна наука.
Да бисте извршили итерације, на пример, мак_вал_сизе =1, 8, морате поновити масовну операцију много пута. Успео си. И на истој бази желите да то урадите поново, али сте већ све избрисали. Шта да радим?
Касније ћу говорити о нашем решењу, шта ми радимо да бисмо поновили у таквим ситуацијама. И ово је најисправнији приступ.
Али у овом случају, имали смо среће. Ако, као што овде пише „ПОЧНИ, ИЗБРИШИ, ВРАТИ“, онда можемо поновити ДЕЛЕТЕ. Односно, ако смо га сами отказали, онда то можемо поновити. И физички код вас подаци ће лежати на истом месту. Чак се и не надимаш. Можете итерирати преко таквих ДЕЛЕТЕ-ова.
Ово ДЕЛЕТЕ са РОЛЛБАЦК је идеално за подешавање контролне тачке, чак и ако немате правилно распоређене лабораторије базе података.
Направили смо плочу са једном колоном "и". Постгрес има услужне колоне. Они су невидљиви осим ако се то посебно не траже. То су: цтид, кмид, кмак.
Цтид је физичка адреса. Нула страница, прва тупле на страници.
Може се видети да је након РООЛБАЦК-а торка остала на истом месту. То јест, можемо покушати поново, понашаће се на исти начин. Ово је главна ствар.
Ксмак је време смрти тупле. Отиснут је печат, али Постгрес зна да је трансакција враћена, тако да није важно да ли је 0 или је трансакција враћена. Ово сугерише да је могуће поновити ДЕЛЕТЕ и проверити групне операције понашања система. Можете направити лабораторије базе података за сиромашне.
Овде се ради о програмерима. Што се тиче ДБА, такође увек грде програмере због овога: „Зашто радите тако дуге и тешке операције?“. Ово је сасвим друга окомита тема. Некада је постојала администрација, а сада ће бити развоја.
Очигледно, нисмо се распали на комаде. То је јасно. Немогуће је не разбити такав ДЕЛЕТЕ за гомилу милиона редова на делове. Радиће се 20 минута, и све ће лећи. Али, нажалост, чак и искусни програмери праве грешке, чак иу веома великим компанијама.
Зашто је важно разбити?
-
Ако видимо да је диск тврд, хајде да га успоримо. А ако смо сломљени, онда можемо додати паузе, можемо успорити пригушивање.
-
А друге нећемо још дуго блокирати. У неким случајевима није важно, ако бришете право смеће на коме нико не ради, онда највероватније нећете никога блокирати осим рада аутовакума, јер ће чекати да се трансакција заврши. Али ако уклоните нешто што неко други може да затражи, онда ће бити блокирани, доћи ће до неке ланчане реакције. Дуге трансакције треба избегавати на веб локацијама и мобилним апликацијама.
Ово је занимљиво. Често видим да се програмери питају: „Коју величину пакета да изаберем?“.
Јасно је да што је већа величина пакета, то су мањи трошкови трансакције, тј. додатни режијски трошкови од трансакција. Али у исто време, време за ову трансакцију се повећава.
Имам врло једноставно правило: узмите колико год можете, али не прелазите преко извршних датотека у секунди.
Зашто секунду? Објашњење је врло једноставно и разумљиво свима, чак и нетехничарима. Видимо реакцију. Узмимо 50 милисекунди. Ако се нешто променило, онда ће наше око реаговати. Ако мање, онда теже. Ако нешто одговори после 100 милисекунди, на пример, кликнули сте мишем, а оно вам је одговорило после 100 милисекунди, већ осећате ово мало кашњење. Секунда се већ доживљава као кочница.
Сходно томе, ако своје масовне операције разбијемо на рафале од 10 секунди, онда имамо ризик да ћемо некога блокирати. И радиће неколико секунди, и људи ће то већ приметити. Због тога више волим да не радим више од секунде. Али у исто време, немојте га врло фино разбити, јер ће трошкови трансакције бити приметни. База ће бити тежа, а могу се појавити и други различити проблеми.
Бирамо величину паковања. У сваком случају, можемо то учинити другачије. Може се аутоматизовати. И уверени смо у ефикасност обраде једног паковања. То јест, радимо БРИСАЊЕ једног пакета или АЖУРИРАЊЕ.
Иначе, све о чему говорим није само о БРИСАЊУ. Као што сте претпоставили, ово су све масовне операције над подацима.
И видимо да је план одличан. Можете видети скенирање индекса, скенирање само индекса је још боље. А ми имамо малу количину података укључених. И мање од секунде испуњава. Супер.
И још треба да се уверимо да нема деградације. Дешава се да први пакети брзо раде, а онда постаје све горе, горе и горе. Процес је такав да морате много тестирати. Управо за то служе лабораторије за базе података.
И још морамо нешто да припремимо како би нам то омогућило да то исправно пратимо у производњи. На пример, можемо да упишемо време у дневник, можемо да упишемо где смо сада и кога смо сада избрисали. И то ће нам омогућити да касније разумемо шта се дешава. И у случају да нешто крене наопако, брзо пронађите проблем.
Ако треба да проверимо ефикасност захтева и морамо да понављамо много пута, онда постоји таква ствар као колега бот. Он је већ спреман. Свакодневно га користе десетине програмера. И он зна како да на захтев за 30 секунди да огромну базу података у терабајту, вашу сопствену копију. И можете да избришете нешто тамо и кажете РЕСЕТ, и поново то избришите. Можете експериментисати на овај начин. Видим будућност за ову ствар. И ми то већ радимо.
Шта су стратегије поделе? Видим 3 различите стратегије партиционисања које користе програмери на пакету.
Први је врло једноставан. Имамо нумерички ИД. И хајде да га поделимо на различите интервале и порадимо на томе. Лоша страна је јасна. У првом сегменту можемо имати 100 редова правог смећа, у другом 5 редова или уопште нећемо, или ће свих 1 редова испасти смеће. Веома неуједначен рад, али га је лако сломити. Узели су максималну легитимацију и разбили је. Ово је наиван приступ.
Друга стратегија је уравнотежен приступ. Користи се у Гитлабу. Узели су и прегледали сто. Пронашли смо границе ИД пакета тако да сваки пакет има тачно 10 записа. И ставите их у ред. И онда обрађујемо. То можете учинити у више нити.
И у првој стратегији, иначе, то можете учинити у неколико нити. Није тешко.
Али постоји хладнији и бољи приступ. Ово је трећа стратегија. А када је могуће, боље је изабрати. То радимо на основу посебног индекса. У овом случају, то ће највероватније бити индекс према нашем стању смећа и ИД-у. Укључићемо ИД тако да је скенирање само индекса како не бисмо ишли на хрпу.
Генерално, скенирање само индекса је брже од скенирања индекса.
И брзо пронађемо наше ИД-ове које желимо да избришемо. БАТЦХ_СИЗЕ бирамо унапред. И не само да их добијамо, већ их добијамо на посебан начин и одмах их хакујемо. Али ми закључавамо тако да ако су већ закључани, не закључавамо их, већ идемо даље и узимамо следеће. Ово је за закључавање прескакања ажурирања. Ова супер карактеристика Постгреса нам омогућава да радимо у неколико нити ако желимо. Могуће је у једном току. А овде постоји ЦТЕ - ово је један захтев. И имамо право брисање на другом спрату овог ЦТЕ-а - returning *. Можете вратити ИД, али је боље *ако немате много података на свакој линији.
Зашто нам то треба? Ово је оно што треба да пријавимо. У ствари, сада смо избрисали толико редова. И имамо границе по ИД-у или по цреатед_ат овако. Можете учинити мин, мак. Нешто друго може да се уради. Овде можете много ствари. И веома је згодно за праћење.
Постоји још једна напомена о индексу. Ако одлучимо да нам је потребан посебан индекс за овај задатак, онда морамо да се уверимо да не поквари хрпу ажурирања само тупле. То јест, Постгрес има такву статистику. Ово се може видети у пг_стат_усер_таблес за вашу табелу. Можете видети да ли се користе врућа ажурирања или не.
Постоје ситуације када ваш нови индекс може једноставно да их одсече. И имате све друге исправке које већ раде, успорите. Не само зато што се индекс појавио (сваки индекс мало успорава ажурирање, али мало), али овде га и даље уништава. И немогуће је направити посебну оптимизацију за ову табелу. Ово се понекад дешава. Ово је таква суптилност да се мало људи сећа. А на ове грабље је лако згазити. Понекад се деси да треба да нађете приступ са друге стране и да ипак прођете без овог новог индекса, или направите други индекс, или на неки други начин, на пример, можете користити други метод.
Али ово је најоптималнија стратегија, како се поделити у групе и пуцати на серије са једним захтевом, мало обрисати итд.
Дуге трансакције
Блокиран аутовакуум -
проблем блокирања -
Грешка број 5 је велика. Николај из Окметра је говорио о Постгрес мониторингу. Идеално праћење Постгреса, нажалост, не постоји. Неки су ближе, неки даље. Окметар је довољно близу да буде савршен, али много тога недостаје и треба га додати. Морате бити спремни за ово.
На пример, мртве торке се најбоље прате. Ако имате много мртвих ствари у табели, онда нешто није у реду. Боље је одмах реаговати, иначе може доћи до деградације, па можемо да легнемо. Дешава се.
Ако постоји велики ИО, онда је јасно да то није добро.
Дуге трансакције такође. Дуге трансакције не би требало да буду дозвољене на ОЛТП-у. А ево везе до исечка који вам омогућава да узмете овај исечак и већ пратите дуге трансакције.
Зашто су дуге трансакције лоше? Зато што ће све браве бити ослобођене тек на крају. И зајебамо све. Плус, блокирамо аутовакуум за све столове. Уопште није добро. Чак и ако имате омогућен хот стандби на реплици, и даље је лоше. Генерално, нигде није боље избегавати дуге трансакције.
Ако имамо много столова који нису усисавани, онда морамо имати упозорење. Овде је таква ситуација могућа. На рад аутовакума можемо индиректно утицати. Ово је исечак из Авита, који сам мало побољшао. И испоставило се да је занимљив алат да видимо шта имамо са аутовакуумом. На пример, неки столови тамо чекају и неће чекати свој ред. Такође морате да га ставите у надзор и имате упозорење.
И издаје блокове. Шума дрвећа блокирања. Волим да узмем нешто од некога и побољшам то. Овде сам узео кул рекурзивни ЦТЕ из Дата Егрет који приказује шуму стабала браве. Ово је добар дијагностички алат. А на основу тога можете изградити и праћење. Али ово се мора урадити пажљиво. Морате да направите мали статемент_тимеоут за себе. И лоцк_тимеоут је пожељно.
Понекад се све ове грешке јављају у збиру.
По мом мишљењу, овде је главна грешка организациона. Организацијски је, јер техника не вуче. Ово је број 2 - проверили су на погрешном месту.
Проверили смо на погрешном месту, јер нисмо имали производни клон, који је лако проверити. Програмер можда уопште нема приступ производњи.
А нисмо тамо проверили. Да смо тамо проверили, и сами бисмо видели. Програмер је све то видео чак и без ДБА ако је то проверио у добром окружењу, где постоји иста количина података и идентична локација. Видео би сву ову деградацију и било би га срамота.
Више о аутовакуму. Након што смо урадили масивно чишћење од неколико милиона редова, још увек морамо да урадимо РЕПАЦК. Ово је посебно важно за индексе. Осећаће се лоше након што тамо све очистимо.
А ако желите да вратите свакодневни посао чишћења, онда бих предложио да то радите чешће, али мање. То може бити једном у минуту или чак и чешће мало. И треба да пазите на две ствари: да ова ствар нема грешака и да не заостаје. Трик који сам показао само ће ово решити.
Оно што радимо је отворени код. Објављено је на ГитЛаб-у. И ми то радимо тако да људи могу да провере чак и без ДБА. Радимо лабораторију базе података, односно зовемо основну компоненту на којој Џо тренутно ради. И можете узети копију производње. Сада постоји имплементација Јое за слацк, тамо можете рећи: „објасните такав и такав захтев“ и одмах добити резултат за своју копију базе података. Можете чак и ИЗБРИСАТИ тамо, и нико то неће приметити.
Рецимо да имате 10 терабајта, ми направимо лабораторију базе података такође 10 терабајта. А са истовременим базама података од 10 терабајта, 10 програмера може да ради истовремено. Свако може да ради шта хоће. Може обрисати, испустити, итд. То је таква фантазија. О овоме ћемо разговарати сутра.
Ово се зове танко обезбеђивање. Ово је суптилно обезбеђивање. Ово је нека врста фантазије која у великој мери отклања кашњења у развоју, тестирању и чини свет бољим местом у том погледу. То јест, само вам омогућава да избегнете проблеме са великим операцијама.
Пример: база података од 5 терабајта, добијање копије за мање од 30 секунди. И то чак не зависи од величине, односно није битно колико терабајта.
Данас можете ићи на и копати по нашим алатима. Можете се регистровати да видите шта има. Можете инсталирати овај бот. Бесплатно је. Пишите.
pitanja
Врло често се у реалним ситуацијама испостави да је података који треба да остану у табели много мање од онога што треба обрисати. Односно, у таквој ситуацији често је лакше имплементирати такав приступ, када је лакше креирати нови објекат, копирати само потребне податке тамо, и трунк стару табелу. Јасно је да је за овај тренутак потребан програмски приступ, док ћете се пребацивати. Како је овај приступ?
Ово је веома добар приступ и веома добар задатак. Веома је слично ономе што пг_репацк ради, веома је слично ономе што морате да урадите када направите ИД од 4 бајта. Многи оквири су то урадили пре неколико година, и само су плоче порасле и треба их конвертовати у 8 бајтова.
Овај задатак је прилично тежак. Успели смо. И морате бити веома опрезни. Има брава итд. Али то се ради. То јест, стандардни приступ је да идете са пг_репацком. Такву ознаку декларишете. И пре него што почнете да учитавате податке снимака у њега, такође декларишете једну плочу која прати све промене. Постоји трик да неке промене можда нећете ни пратити. Постоје суптилности. А онда прелазите померањем промена. Биће кратка пауза када све угасимо, али генерално то се ради.
Ако погледате пг_репацк на ГитХуб-у, онда, када је постојао задатак да се конвертује ИД из инт 4 у инт 8, постојала је идеја да се користи сам пг_репацк. Ово је такође могуће, али је мало хак, али ће радити и за ово. Можете интервенисати у окидачу који пг_репацк користи и тамо рећи: „Не требају нам ови подаци“, тј. преносимо само оно што нам је потребно. А онда се само пребаци и то је то.
Овим приступом и даље добијамо другу копију табеле, у којој су подаци већ индексирани и веома равномерно сложени са лепим индексима.
Надутост није присутна, то је добар приступ. Али знам да постоје покушаји да се за то развије аутоматизација, односно да се направи универзално решење. Могу да вас повежем са овом аутоматизацијом. Написано је у Пајтону, што је добра ствар.
Ја сам само мало из света МиСКЛ-а, па сам дошао да слушам. И ми користимо овај приступ.
Али то је само ако имамо 90%. Ако имамо 5%, онда није баш добро да га користимо.
Хвала на извештају! Ако нема ресурса за прављење комплетне копије прод-а, постоји ли неки алгоритам или формула за израчунавање оптерећења или величине?
Добро питање. До сада смо у могућности да пронађемо базе података од више терабајта. Чак и ако хардвер тамо није исти, на пример, мање меморије, мање процесора и дискови нису потпуно исти, али ми то радимо. Ако нема апсолутно нигде, онда треба размислити. Да размислим до сутра, дошли сте, разговараћемо, ово је добро питање.
Хвала на извештају! Прво сте почели о томе да постоји кул Постгрес, који има таква и таква ограничења, али се развија. А ово је све углавном штака. Није ли ово све у супротности са развојем самог Постгреса, у коме ће се појавити неки ДЕЛЕТЕ деферент или нешто друго што би требало да држи на ниском нивоу оно што покушавамо да замаземо неким нашим чудним средствима овде?
Ако смо у СКЛ-у рекли да обришемо или ажурирамо много записа у једној трансакцији, како онда Постгрес може да их дистрибуира тамо? Ми смо физички ограничени у операцијама. Још дуго ћемо то радити. А ми ћемо закључати у ово време итд.
Готово са индексима.
Могу претпоставити да би исто подешавање контролне тачке могло бити аутоматизовано. Једног дана би могло бити. Али онда стварно не разумем питање.
Питање је да ли постоји такав вектор развоја који иде ту и тамо, а овде ваш иде паралелно? Оне. Зар још нису размишљали о томе?
Говорио сам о принципима који се сада могу користити. Постоји још један бот , са овим можете извршити аутоматизовано подешавање контролне тачке. Хоће ли то једног дана бити у Постгресу? Не знам, о томе се још није ни разговарало. Још смо далеко од тога. Али постоје научници који праве нове системе. И угурали су нас у аутоматске индексе. Има развоја. На пример, можете погледати аутоматско подешавање. Аутоматски бира параметре. Али он још неће радити подешавање контролне тачке за вас. То јест, покупиће се за перформансе, бафер љуске итд.
А за подешавање контролне тачке, можете да урадите ово: ако имате хиљаду кластера и различит хардвер, различите виртуелне машине у облаку, можете да користите наш бот уради аутоматизацију. И мак_вал_сизе ће бити изабран аутоматски према вашим циљним подешавањима. Али за сада то, нажалост, није ни близу у сржи.
Добар дан Говорили сте о опасностима дугих трансакција. Рекли сте да је аутовакуум блокиран у случају брисања. Како нам иначе штети? Зато што више говоримо о ослобађању простора и могућности да га користите. Шта нам још недостаје?
Аутовакуум овде можда није највећи проблем. А чињеница да дуга трансакција може закључати друге трансакције, ова могућност је опаснија. Она се може срести или не мора. Ако се упознала, онда може бити јако лоше. А са аутовакумом - ово је такође проблем. Постоје два проблема са дугим трансакцијама у ОЛТП-у: закључавање и аутовакум. А ако имате омогућену повратну информацију о врућој приправности на реплици, онда ћете и даље добити аутовакуумску браву на мастеру, она ће стићи из реплике. Али бар неће бити брава. И биће локса. Говоримо о променама података, тако да су браве овде важна тачка. А ако је све ово дуго, дуго, онда је све више трансакција закључано. Они могу украсти друге. И појављују се лок дрвеће. Дао сам везу до исечка. И овај проблем постаје уочљивији брже од проблема са аутовакуумом, који се може само акумулирати.
Хвала на извештају! Започели сте свој извештај рекавши да сте тестирали погрешно. Наставили смо нашу идеју да треба да узмемо исту опрему, са базом на исти начин. Рецимо да смо програмеру дали основу. И он је удовољио захтеву. И изгледа да је добро. Али он не проверава уживо, већ уживо, на пример, имамо оптерећење од 60-70%. Чак и ако користимо ово подешавање, не функционише баш добро.
Важно је имати стручњака у тиму и користити ДБА стручњаке који могу предвидети шта ће се догодити са стварним оптерећењем у позадини. Када смо управо спровели наше чисте промене, видимо слику. Али напреднији приступ, када смо поново урадили исту ствар, али са оптерећењем симулираним са производњом. Прилично је кул. До тада, морате одрасти. То је као одрасла особа. Само смо погледали шта имамо и такође смо погледали да ли имамо довољно ресурса. То је добро питање.
Када већ радимо одабир смећа и имамо, на пример, избрисану заставицу
То је оно што аутовацуум ради аутоматски у Постгресу.
Ох, да ли он то ради?
Аутовакуум је сакупљач смећа.
Хвала!
Хвала на извештају! Постоји ли опција да се одмах дизајнира база података са партиционисањем на начин да се сво ђубре запрља са главне табеле негде на страну?
Наравно да имам.
Да ли је онда могуће да се заштитимо ако смо закључали сто који не би требало да се користи?
Наравно да имам. Али то је као питање кокошке и јаја. Ако сви знамо шта ће се десити у будућности, онда ћемо, наравно, све учинити кул. Али посао се мења, постоје нове рубрике, нови захтеви. А онда – упс, желимо да га уклонимо. Али ова идеална ситуација, у животу се дешава, али не увек. Али генерално, то је добра идеја. Само скратите и то је то.
Извор: ввв.хабр.цом