Уважаеми DELETE. Николай Самохвалов (Postgres.ai)

Някой ден в далечното бъдеще автоматичното премахване на ненужни данни ще бъде една от важните задачи на СУБД [1]. Междувременно ние сами трябва да се погрижим за изтриването или преместването на ненужни данни в по-евтини системи за съхранение. Да приемем, че решите да изтриете няколко милиона реда. Доста проста задача, особено ако условието е известно и има подходящ индекс. „DELETE FROM table1 WHERE col1 = :value“ – какво по-просто, нали?

Video:

• Аз съм в програмния комитет на Highload от първата година, т.е. от 2007 г.

• И съм в Postgres от 2005 г. Използвал го е в много проекти.

• Групата също е с RuPostges от 2007 г.

• Нараснахме до 2100+ участници в Meetup. Това е второ място в света след Ню Йорк, след като отдавна изпревари Сан Франциско.

• Живея в Калифорния от няколко години. Работя предимно с американски компании, включително големи. Те са активни потребители на Postgres. И там възникват всякакви интересни неща.

https://postgres.ai/ – това е моята компания. Ние сме в бизнеса с автоматизиране на задачи, които елиминират забавянето на развитието.

Ако направите нещо, понякога има някои проблеми около Postgres. Да кажем, че трябва да изчакате, докато администраторът ви предостави тестов стенд, или трябва да изчакате, докато DBA ви отговори. И ние откриваме такива тесни места в процеса на разработка, тестване и администриране и се опитваме да ги елиминираме с помощта на автоматизация и нови подходи.

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

Наскоро бях във VLDB в Лос Анджелис. Това е най-голямата конференция за бази данни. И имаше доклад, че в бъдеще СУБД не само ще съхраняват, но и автоматично ще изтриват данни. Това е нова тема.

В света има все повече данни. Зетабайтите са 1 000 000 петабайта. И сега вече се изчислява, че имаме повече от 100 зетабайта данни, съхранени в света. А те стават все повече и повече.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

И какво да правя с него? Ясно е, че трябва да се изтрие. Ето линк към този интересен доклад. Но досега това не е внедрено в СУБД.

Тези, които знаят как да броят пари, искат две неща. Те искат да изтрием, така че технически трябва да можем да го направим.

Това, което ще разкажа по-нататък, е абстрактна ситуация, която включва куп реални ситуации, тоест определена компилация от това, което всъщност се е случило с мен и околните бази данни много пъти, много години. Греблата са навсякъде и всеки ги стъпва през цялото време.

Да кажем, че имаме база или няколко бази, които растат. А някои от записите са очевиден боклук. Например, потребителят е започнал да прави нещо там, но не е завършил. И след известно време знаем, че тази незавършена работа вече не може да се съхранява. Тоест, бихме искали да изчистим някои ненужни неща, за да спестим място, да подобрим производителността и т.н.

Като цяло задачата е да се автоматизира изтриването на конкретни неща, конкретни редове в таблица.

И имаме една заявка, за която ще говорим днес, тоест за извозването на боклука.

Помолихме опитен разработчик да направи това. Той взе тази заявка, провери я сам - всичко работи. Тествах го на постановка - всичко е наред. Разточих го - всичко работи. Веднъж на ден пускаме това - всичко е наред.

Базата данни расте и расте. Дневният DELETE започва да работи малко по-бавно.

Тогава разбираме, че вече сме маркетингова компания и трафикът ще бъде няколко пъти по-голям, затова решаваме временно да спрем ненужните неща. И забравяме да го върнем.

Няколко месеца по-късно се сетиха. И този разработчик напусна или беше зает с нещо друго, възложиха на друг да го върне.

Провери на dev, на staging - всичко е наред. Естествено, все още трябва да почистите натрупаното. Той провери, всичко работи.

Какво се случва след това? Тогава всичко се разпада за нас. Пада толкова много, че в един момент всичко пада. Всички са в шок, никой не разбира какво се случва. И тогава се оказва, че този DELETE е проблемът.

Нещо се обърка? Ето списък с неща, които могат да се объркат. Кое от тях е най-важното?

• Например, нямаше преглед, т.е. експертът на DBA не погледна. С опитно око веднага би открил проблема, а освен това има достъп до prod, където са се натрупали няколко милиона реда.

• Може би са проверили нещо нередно.

• Може би хардуерът е остарял и трябва да надстроите тази база данни.

• Или нещо не е наред със самата база данни и трябва да преминем от Postgres към MySQL.

• Или може би нещо не е наред с операцията.

• Може би има грешки в организацията на работа и трябва да уволните някого и да наемете по-добри хора?

Нямаше проверка на DBA. Ако имаше DBA, той щеше да види тези няколко милиона реда и дори без никакви експерименти щеше да каже: "Те не правят това." Да кажем, че ако този код беше в GitLab, GitHub и имаше процес на преглед на кода и нямаше такова нещо, че без одобрението на DBA тази операция да се извърши на prod, тогава очевидно DBA щеше да каже: „Не можете да направите това. ”

И той би казал, че ще имате проблеми с IO на диска и всички процеси ще полудеят, може да има ключалки и ще блокирате автовакуума за няколко минути, така че това не е добре.

http://bit.ly/nancy-hl2018-2

Втората грешка е, че са проверили на грешното място. Видяхме след факта, че много ненужни данни са се натрупали в prod, но разработчикът не е имал натрупани данни в тази база данни и никой наистина не е създал този боклук при етапа. Съответно имаше 1 реда, които бързо бяха завършени.

Разбираме, че нашите тестове са слаби, т.е. изграденият процес не улавя проблеми. Не е извършен адекватен DB експеримент.

За предпочитане е идеалният експеримент да се проведе на същото оборудване. Не винаги е възможно да се направи това на същия хардуер, но е много важно това да е пълноразмерно копие на базата данни. Това е, което проповядвам вече няколко години. И преди година говорих за това, можете да гледате всичко в YouTube.

Може би нашето оборудване е лошо? Ако погледнете, латентността е скочила. Видяхме, че рециклирането е 100%. Разбира се, ако това бяха модерни NVMe устройства, вероятно щеше да ни е много по-лесно. И може би не бихме легнали заради това.

Ако имате облаци, тогава надграждането е лесно. Пуснахме нови реплики на нов хардуер. Превключвам. И всичко е наред. Доста лесно.

Възможно ли е по някакъв начин да се докоснат по-малки дискове? И тук, с помощта на DBA, се потапяме в определена тема, наречена настройка на контролни точки. Оказва се, че не сме извършили настройка на контролни точки.

Какво е контролно-пропускателен пункт? Това е достъпно във всяка СУБД. Когато данните в паметта ви се променят, те не се записват веднага на дискове. Информацията, че данните са променени, първо се записва в регистрационния файл за напред, в журнала за предварително записване. И в един момент СУБД решава, че е време да хвърли истинските страници на диска, така че ако имаме грешка, да можем да правим по-малко REDO. Това е като играчка. Ако бъдем убити, ще започнем играта от последната контролна точка. И всички СУБД прилагат това.

Настройките в Postgres изостават. Те са предназначени за 10-15 годишни обеми от данни и операции. И контролно-пропускателният пункт не е изключение.

Тази информация е от нашия отчет с Postgres check-up, т.е. автоматична проверка на здравето. И тук има база данни от няколко терабайта. И е ясно, че контролно-пропускателните пунктове са принудителни в почти 90% от случаите.

Какво означава? Там има две настройки. Контролната точка може да се появи в изчакване, например след 10 минути. Или може да възникне, когато са попълнени доста много данни.

И по подразбиране max_wal_saze е настроен на 1 гигабайт. Всъщност това реално се случва в Postgres след 300-400 мегабайта. Променили сте толкова много данни и имате контролна точка.

И ако никой не го е настроил, но услугата е нараснала и компанията печели много пари, има много транзакции, тогава контролната точка се появява веднъж на минута, понякога веднъж на всеки 30 секунди, а понякога дори се припокриват . Това наистина е лошо.

И трябва да се уверим, че идва по-рядко. Тоест можем да повишим max_wal_size. И той ще атакува по-рядко.

Но ние разработихме цяла методология как да направим това по-правилно, тоест как да вземем решения за избор на настройки, ясно въз основа на конкретни данни.

Съответно извършваме две серии от експерименти с бази данни.

Първа серия - променяме max_wal_size. И извършваме мащабна операция. Първо го правим при настройката по подразбиране от 1 гигабайт. И ние извършваме масивно ИЗТРИВАНЕ на много милиони редове.

Виждате колко ни е трудно. Виждаме, че IO на диска е много лош. Нека да видим колко WAL сме генерирали, защото това е много важно. Да видим колко пъти се е случила контролната точка. И виждаме, че не е добре.

След това увеличаваме max_wal_size. Повтаряме. Увеличете, повторете. И така много пъти. По принцип 10 точки е добре, където 1, 2, 4, 8 гигабайта. И ние разглеждаме поведението на конкретна система. Ясно е, че оборудването тук трябва да е като на прод. Трябва да имате същите дискове, същото количество памет и същите настройки на Postgres.

И по този начин ще обменим нашата система и знаем как ще се държи СУБД в случай на лошо масово ИЗТРИВАНЕ, как ще проверява.

Чекпойнт на руски означава контролни точки.

Пример: ИЗТРИВАНЕ на няколко милиона реда по индекс, редовете са „разпръснати“ по страниците.

Ето един пример. Това е някаква основа. И с настройката по подразбиране от 1 гигабайт за max_wal_size, много ясно, че нашите дискове за запис отиват на рафта. Тази картина е типичен симптом на много болен пациент, тоест той наистина се чувстваше зле. И имаше само една операция, тук беше само ИЗТРИВАНЕ на няколко милиона реда.

Ако такава операция е разрешена в prod, тогава просто ще паднем, защото е ясно, че един DELETE ни убива в рафта.

Освен това, където има 16 гигабайта, можете да видите, че зъбите вече са започнали да се появяват. Зъбите вече са по-добре, т.е. чукаме по тавана, но не толкова зле. Там се появи малко свобода. Вдясно е записът. А броят на операциите е втората графика. И е ясно, че вече дишаме малко по-лесно с 16 гигабайта.

И там, където се виждат 64 гигабайта, стана напълно по-добре. Вече зъбите са ясно видими, има повече възможности да оцелеете при други операции и да направите нещо с диска.

Защо?

Ще се потопя малко в подробностите, но тази тема за това как да извършите настройка на контролни точки може да доведе до цял доклад, така че няма да навлизам в много подробности, но ще очертая малко какви трудности има.

Ако контролната точка се случва твърде често и ние не актуализираме редовете си последователно, а ги намираме по индекс, което е добре, защото не изтриваме цялата таблица, тогава може да се случи, че първо сме докоснали първата страница, след това хилядната, и след това се върна към първия . И ако между тези посещения на първата страница контролната точка вече го е записала на диск, тогава ще го запази отново, защото сме го изцапали втори път.

И ние ще принудим контролно-пропускателния пункт да го спаси много пъти. Като че ли има излишни операции за него.

Но това не е всичко. В Postgres страниците тежат 8 килобайта, а в Linux 4 килобайта. И има настройка full_page_writes. Той е активиран по подразбиране. И това е правилно, защото ако го изключим, има опасност при повреда да се запази само половината от страницата.

Поведението на записа в WAL на журнала за препращане е такова, че когато имаме контролна точка и променим страница за първи път, цялата страница, тоест всичките 8 килобайта, завършва в журнала за препращане, въпреки че ние промени само ред, който тежи 100 байта. И сме принудени да запишем цялата страница.

В следващите промени ще има само конкретен кортеж, но за първи път записваме всичко.

И съответно, ако контролната точка се случи отново, тогава трябва да започнем всичко от нулата и да натъпчем цялата страница. При чести контролни точки, когато преминаваме през едни и същи страници, full_page_writes = on ще бъде по-голямо, отколкото би могло да бъде, т.е. ние генерираме повече WAL. Повече се изпраща на реплики, в архива, на диск.

И съответно имаме две съкращения.

Ако увеличим max_wal_size, се оказва, че улесняваме работата както на checkpoint, така и на wal writer. И това е страхотно.

Нека инсталираме терабайт и да живеем с него. Какво му е лошото? Това е лошо, защото в случай на повреда ще ставаме с часове, защото контролно-пропускателният пункт беше отдавна и много вече се промени. И трябва да направим REDO за всичко това. И така, ние правим втора серия от експерименти.

Извършваме операцията и виждаме кога контролната точка е близо до завършване, нарочно правим kill -9 Postgres.

И след това го стартираме отново и виждаме колко време ще отнеме да се издигне на това оборудване, т.е. колко REDO ще направи в тази лоша ситуация.

Два пъти ще отбележа, че положението е лошо. Първо, паднахме точно преди края на контролния пункт, така че имаме много за губене. И второ, имахме мащабна операция. И ако контролните точки имаха изчакване, тогава най-вероятно щеше да се генерира по-малко WAL от последната контролна точка. Тоест, това е два пъти губещ.

Ние измерваме тази ситуация за различен max_wal_size и разбираме, че ако max_wal_size е 64 гигабайта, тогава в двойно най-лоша ситуация ще се издигнем за 10 минути. И мислим дали това ни устройва или не. Това е бизнес въпрос. Трябва да покажем тази картина на отговорните за бизнес решенията и да попитаме: „Колко е максималното време, което можем да чакаме в случай на проблем? Можем ли да легнем в по-лоша ситуация за 3-5 минути?“ И вземаш решение.

И тук има един интересен момент. Имаме няколко доклада за Patroni на конференцията. И може би го използвате. Това е автоматичен отказ за Postgres. GitLab и Data Egret говориха за това.

И ако имате автоматичен отказ, който ще се случи след 30 секунди, тогава може би можем да легнем за 10 минути? Защото до този момент ще преминем към репликата и всичко ще бъде наред. Това е спорен въпрос. Не знам ясен отговор. Просто чувствам, че тази тема не е само за възстановяване след бедствие.

Ако имаме дълго възстановяване от провал, тогава ще се чувстваме неудобно в много други ситуации. Например в същите експерименти, когато правим нещо и понякога трябва да изчакаме 10 минути.

Все още не бих отишъл твърде далеч, дори ако имаме автоматично прехвърляне на грешки. По правило стойности като 64, 100 гигабайта са добри стойности. Понякога дори си струва да изберете по-малко. Изобщо това е тънка наука.

За да повторите, например, max_wal_size = 1, 8, трябва да повторите масовата операция много пъти. Направи го. И искате да го направите отново на същата база, но вече сте изтрили всичко. Какво да правя?

Ще ви разкажа по-късно за нашето решение и какво правим, за да повторим в такива ситуации. И това е най-правилният подход.

Но в случая имахме късмет. Ако, както се казва тук „НАЧАЛО, ИЗТРИВАНЕ, ВРЪЩАНЕ“, тогава можем да повторим ИЗТРИВАНЕ. Тоест, ако сами сме го отменили, тогава можем да го повторим. И физически вашите данни ще бъдат там. Дори не се подуваш. Можете да повторите такъв DELETE.

Това DELETE с ROLLBACK е идеално за настройка на контролни точки, дори ако нямате правилно разгърнати лаборатории за база данни.

Направихме знак с една колона „i“. Postgres има полезни колони. Те са невидими, освен ако не е изрично поискано. Това са: ctid, xmid, xmax.

Ctid е физическият адрес. Страница нула, първият кортеж в страницата.

Вижда се, че след ROOLBACK кортежът остава на същото място. Тоест, можем да опитаме отново, ще се държи по същия начин. Това е основното.

Xmax е времето на смъртта на кортежа. Той е въведен, но Postgres знае, че тази транзакция е върната назад, така че няма значение дали е 0 или върната транзакция. Това предполага, че DELETE може да се използва за повторение и тестване на масивни операции на системното поведение. Можете да направите лаборатории за бази данни за бедните.

Тук става въпрос за програмисти. Относно DBA също, те винаги се карат на програмистите за това: „Защо правите толкова дълги и трудни операции?“ Това е съвсем различна перпендикулярна тема. Преди имаше администрация, а сега ще има развитие.

Очевидно не сме го разделили на части. Ясно е. Невъзможно е да разбиете такъв DELETE за куп милиони редове на части. Това ще отнеме 20 минути и всичко ще легне. Но, за съжаление, дори опитни разработчици правят грешки, дори в много големи компании.

Защо разбиването е важно?

• Ако видим, че дискът е твърд, тогава нека го забавим. И ако сме счупени, тогава можем да добавим паузи, можем да забавим дроселирането.

• И няма да блокираме други за дълго. В някои случаи няма значение, ако премахвате истински боклук, върху който никой не работи, тогава най-вероятно няма да блокирате никого, освен работата на autovacuum, защото ще изчака транзакцията да завърши. Но ако изтриете нещо, което някой друг може да поиска, тогава той ще бъде блокиран, ще има някаква верижна реакция. Трябва да се избягват дълги транзакции в уебсайтове и мобилни приложения.

https://postgres.ai/products/joe/

Това е интересно. Често виждам разработчици да питат: „Какъв размер на опаковката да избера?“

Ясно е, че колкото по-голям е размерът на партидата, толкова по-ниски са режийните разходи за транзакции, т.е. допълнителни режийни разходи за транзакции. Но в същото време времето за тази сделка се увеличава.

Имам много просто правило: вземете колкото е възможно повече, но не превишавайте изпълнението за секунда.

Защо втори? Обяснението е много просто и разбираемо за всеки, дори и за нетехнически хора. Виждаме реакцията. Да вземем 50 милисекунди. Ако нещо се е променило, окото ни ще реагира. Ако е по-малко, е по-трудно. Ако нещо отговори след 100 милисекунди, например, щракнахте с мишката и то ви отговори след 100 милисекунди, вече усещате това леко забавяне. Секунда вече се възприема като спирачка.

Съответно, ако разделим масовите си операции на 10-секундни изблици, рискуваме да блокираме някого. И ще работи за няколко секунди и хората вече ще го забележат. Затова предпочитам да не го правя повече от секунда. Но в същото време не го разбивайте твърде малко, защото режийните разходи за транзакция ще бъдат забележими. Ще бъде по-тежък за основата и могат да възникнат различни други проблеми.

Избираме размера на опаковката. Във всеки случай можем да направим това по различен начин. Може да се автоматизира. И сме убедени в ефективността на обработката на една опаковка. Тоест правим ИЗТРИВАНЕ на един пакет или АКТУАЛИЗИРАНЕ.

Между другото, всичко, което ви казвам, не е само за ИЗТРИВАНЕ. Както се досещате, това са всякакви групови операции с данни.

И виждаме, че планът е отличен. Можете да видите сканиране на индекс, още по-добре сканиране само на индекс. И имаме малко количество включени данни. И всичко работи за по-малко от секунда. Супер.

И все още трябва да се уверим, че няма деградация. Случва се първите партиди бързо да се разработят, а след това всичко става все по-зле и по-зле и по-зле. Процесът е такъв, че трябва да тествате много. Точно за това са необходими лаборатории за база данни.

И все още трябва да подготвим нещо, което да ни позволи да наблюдаваме това правилно в производството. Например, можем да напишем часа в дневника, можем да напишем къде сме сега и кого сме изтрили сега. И това ще ни позволи по-късно да разберем какво се случва. И ако нещо се обърка, бързо открийте проблема.

Ако трябва да проверим ефективността на заявките и трябва да повторим много пъти, тогава има такова нещо като колега бот. Той вече е готов. Използва се от десетки разработчици всеки ден. И той може да предостави огромна терабайтова база данни при поискване за 30 секунди, ваше собствено копие. И можете да изтриете нещо там и да кажете НУЛИРАНЕ и да го изтриете отново. Можете да експериментирате с него по този начин. Виждам бъдеще в това нещо. И ние вече правим това.

https://docs.gitlab.com/ee/development/background_migrations.html

Какви са стратегиите за разделяне? Виждам 3 различни стратегии за разделяне, които разработчиците използват в пакета.

Първият е много прост. Имаме цифров идентификатор. И нека го разделим на различни интервали и да работим с това. Минусът е ясен. В първия сегмент може да имаме 100 реда истински боклук, във втория 5 реда или изобщо да няма, или всичките 1 реда ще се окажат боклук. Много неравна работа, но лесна за счупване. Взеха максималната лична карта и я разбиха. Това е наивен подход.

Втората стратегия е балансиран подход. Използва се в Gitlab. Взехме и сканирахме масата. Намерихме границите на ID пакетите, така че всеки пакет съдържаше точно 10 000 записа. И ме наредиха на някаква опашка. И обработваме по-нататък. Можете да направите това в няколко теми.

В първата стратегия, между другото, можете да направите това и в няколко нишки. Не е трудно.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

Но има по-готин и оптимален подход. Това е третата стратегия. И когато е възможно, по-добре е да го изберете. Правим това въз основа на специален индекс. В този случай най-вероятно ще бъде индекс, базиран на нашето състояние на боклук и ID. Ще включим идентификационния номер, така че да е сканиране само на индекс, така че да не отиваме в купчината.

Обикновено сканирането само на индекс е по-бързо от сканирането на индекс.

И бързо намираме своите идентификационни номера, които искаме да изтрием. Избираме BATCH_SIZE предварително. И ние не само ги получаваме, ние ги получаваме по специален начин и веднага ги поправяме. Но ние ги заключваме по такъв начин, че ако вече са заключени, не ги заключваме, а продължаваме напред и вземаме следващите. Това е за заключено пропускане на актуализация. Тази супер функция на Postgres ни позволява да работим в множество нишки, ако искаме. Евентуално в една тема. И тогава има CTE - това е една заявка. И имаме истинско премахване, което се случва на втория етаж на този CTE - returning *. Можете да върнете ID, но е по-добре *, ако имате малко данни във всеки ред.

Защо имаме нужда от това? Имаме нужда от това, за да докладваме. Сега всъщност изтрихме толкова много редове. И нашите граници по ID или created_at са като тези. Можете да направите мин., макс. Може да се направи нещо друго. Има много неща, които можете да натъпчете тук. И това е много удобно за наблюдение.

Има още една забележка относно индекса. Ако решим, че имаме нужда от специален индекс за тази конкретна задача, тогава трябва да се уверим, че той не разваля актуализациите само на купчина кортежи. Тоест Postgres има такава статистика. Това може да се види в pg_stat_user_tables за вашата таблица. Можете да видите дали се използват горещи актуализации или не.

Има ситуации, когато вашият нов индекс може просто да ги отреже. И всички други актуализации, които вече се изпълняват, ще се забавят. Не само защото се появи индексът (всеки индекс забавя малко актуализациите, но само малко), но тук пак ще обърка нещата. И е невъзможно да се направи специална оптимизация за тази таблица. Това се случва понякога. Това е тънкост, която малко хора помнят. И е лесно да стъпите на този рейк. Понякога се случва, че трябва да намерите подход от другата страна и все още да правите без този нов индекс, или да направите друг индекс, или да направите нещо друго, например можете да използвате втория метод.

Но това е най-оптималната стратегия, как да го разделите на партиди и да снимате на партиди с една заявка, да изтриете малко по малко и т.н.

Дълги транзакции - https://gitlab.com/snippets/1890447

Блокиран автовакуум https://gitlab.com/snippets/1889668

Проблем с блокиране https://gitlab.com/snippets/1890428

Грешка №5 е голяма. Николай от Okmeter говори за мониторинга на Postgres. За съжаление не съществува перфектно наблюдение на Postgres. Някои са по-близо, други по-далеч. Okmeter е достатъчно близо, за да бъде перфектен, но много липсват и трябва да се добавят. Трябва да сте подготвени за това.

Например, по-добре е да наблюдавате мъртвите кортежи. Ако имате много мъртви неща в масата си, значи нещо не е наред. По-добре е да реагираме сега, иначе може да има деградация и да си легнем. Случва се.

Ако има голям IO, тогава е ясно, че това не е добре.

Дълги транзакции също. Дългите транзакции не трябва да се допускат на OLTP. И ето връзка към фрагмента, която ви позволява да вземете този фрагмент и вече да извършвате известно проследяване на дълги транзакции.

Защо дългите транзакции са лоши? Защото всички ключалки ще бъдат освободени едва в края. И затваряме всички. Освен това блокираме автовакуума за всички маси. Това никак не е добре. Дори ако имате активиран горещ режим на готовност на репликата, това пак е лошо. Като цяло е по-добре да избягвате дълги транзакции навсякъде.

Ако имаме много маси, които не са вакуумирани, тогава трябва да имаме сигнал. Тук е възможна такава ситуация. Можем косвено да повлияем на работата на автовакуума. Това е фрагмент от Avito, който малко подобрих. И се оказа интересен инструмент, за да видим какво имаме с автовакуума. Например, има някои маси, които чакат там и те няма да дочакат своя ред. Трябва също да го поставите в режим на наблюдение и да имате предупреждение.

И издава блокове. Гора от блокиращи дървета. Харесва ми да взема нещо от някого и да го подобрявам. Тук взех страхотен рекурсивен CTE от Data Egret, който показва гора от заключващи се дървета. Това е добро нещо за диагностика. И на негова основа може да се изгради и мониторинг. Но това трябва да се прави внимателно. Трябва да направите малък statement_timeout за себе си. И lock_timeout е желателно.

Понякога всички тези грешки се появяват заедно.

Според мен най-важната грешка тук е организационната. Организационно е, защото технологията не работи. Това е номер 2 - проверили са на грешното място.

Не проверихме там, защото нямахме производствен клонинг, който да е лесен за проверка. Разработчикът може изобщо да няма достъп до продукцията.

И проверихме на грешното място. Ако бяха проверили там, щяхме да го видим сами. Разработчикът би могъл да види всичко това дори без DBA, ако го провери в добра среда, където има същото количество данни и идентична подредба. Щеше да види цялата тази деградация и щеше да се засрами.

Повече за автомобилния вакуум. След като направихме масивно почистване на няколко милиона реда, все още трябва да направим REPACK. Това е особено важно за индексите. Ще се почувстват зле, след като изчистим всичко там.

И ако искате да върнете ежедневната работа по събличане, тогава бих предложил да го правите по-често, но по-малко. Може да бъде веднъж на минута или дори по-често малко. И трябва да следим две неща: това нещо да няма грешки и да не изостава. Трикът, който показах, ще ви позволи да разрешите това.

Това, което правим, е с отворен код. Това е публикувано в GitLab. И го правим така, че хората да могат да проверяват дори без DBA. Правим лаборатория за база данни, тоест наричаме базовия компонент, върху който Джо работи в момента. И можете да вземете копие от продукцията. Сега има имплементация на Joe for slack, можете да кажете там: „обяснете такава и такава заявка“ и незабавно да получите резултата за вашето копие на базата данни. Можете дори да направите DELETE там и никой няма да забележи.

Да кажем, че имате 10 терабайта, ние правим лаборатория за база данни също 10 терабайта. И 10 разработчици могат да работят едновременно с едновременни 10 терабайтови бази данни. Всеки може да прави каквото иска. Може да изтрие, изтрие и т.н. Това е фантастично. Ще говорим за това утре.

Това се нарича тънко осигуряване. Това е фино осигуряване. Това е някакъв вид фантазия, която значително елиминира забавянията в разработката и тестването и прави света по-добро място в това отношение. Тоест, просто ви позволява да избегнете проблеми с масовите операции.

Пример: база данни от 5 терабайта, получаване на копие за по-малко от 30 секунди. И дори не зависи от размера, т.е. няма значение колко терабайта.

Днес можете да отидете на postgres.ai и се рови в нашите инструменти. Можете да се регистрирате и да видите какво има. Можете да инсталирате този бот за себе си. Безплатно е. Пишете.

Въпроси

Много често в реални ситуации се оказва, че данните, които трябва да останат в таблицата, са много по-малко от тези, които трябва да бъдат изтрити. Тоест, в такава ситуация често е по-лесно да се приложи този подход, когато е по-лесно да се създаде нов обект, да се копират само необходимите данни там и да се транскрибира старата таблица. Ясно е, че трябва софтуерен подход за този момент, докато превключвате. Как е този подход?

Това е много добър подход и много добра задача. Много е подобно на това, което прави pg_repack, много е подобно на това, което трябва да направите, когато идентифицирате хората, които са го направили 4 байта. Много рамки направиха това преди няколко години и плочите току-що станаха по-големи и трябва да бъдат преобразувани в 8 байта.

Тази задача е доста трудна. Успяхме. И трябва да сте много внимателни. Има ключалки и т.н. Но става. Тоест стандартният подход е да се използва pg_repack. Вие обявявате такъв знак. И преди да започнете да я попълвате с данни за моментна снимка, вие също декларирате една таблица, която проследява всички промени. Има един трик, че може дори да не проследите някои промени. Има тънкости. И след това превключвате, разгръщайки промените. Ще има кратка пауза, когато затворим всички, но като цяло това се прави.

Ако погледнете pg_repack в GitHub, тогава, когато имаше задача за преобразуване на ID от int 4 в int 8, тогава имаше идея да се използва самият pg_repack. Това също е възможно, но това е малко хакерски метод, но ще работи и за това. Можете да се намесите в тригера, който използва pg_repack и да кажете там: „Нямаме нужда от тези данни“, т.е. прехвърляме само това, от което се нуждаем. И тогава той просто превключва и това е.

С този подход получаваме и второ копие на таблицата, в която данните вече са индексирани и оформени много гладко с красиви индекси.

Подуване не, това е добър подход. Но знам, че има опити да се разработи автоматизация за това, т.е. да се направи универсално решение. Мога да ви запозная с тази автоматизация. Написано е на Python, добри неща.

Аз съм малко от света на MySQL, така че дойдох да слушам. И ние използваме този подход.

Но това е само ако имаме 90%. Ако имаме 5%, тогава не е много добре да ги използваме.

Благодаря за доклада! Ако няма ресурси за създаване на пълно копие на prod, има ли някакъв алгоритъм или формула за изчисляване на натоварването или размера?

Добър въпрос. Досега можем да намерим многотерабайтови бази данни. Дори там хардуерът да не е същият, например по-малко памет, по-малко процесор и дисковете да не са съвсем същите, пак го правим. Ако няма абсолютно никъде, тогава трябва да помислите за това. Нека да помисля за това до утре, ти дойде, ще поговорим, това е добър въпрос.

Благодаря за доклада! Първо започнахте да говорите за това, че има готин Postgres, който има такива и такива ограничения, но се развива. И всичко това като цяло е патерица. Всичко това не противоречи ли на самата разработка на Postgres, в която ще се появи някакъв вид DELETE deferent или нещо друго, което трябва да поддържа на ниско ниво това, което се опитваме да прикрием тук с някакви свои странни средства?

Ако в SQL казахме да изтрием или актуализираме много записи в една транзакция, тогава как може Postgres да разпространява това? Ние сме физически ограничени в операциите. Ще продължим да правим това още дълго време. И ние ще заключваме в този момент и т.н.

Те направиха същото с индексите.

Мога да предположа, че същата настройка на контролна точка може да бъде автоматизирана. Някой ден това може да се случи. Но тогава наистина не разбирам въпроса.

Въпросът е: има ли вектор на развитие, който да върви точно там и да върви успоредно на вашия тук? Тези. Още ли не мислят за това?

Говорих за принципите, които могат да се използват сега. Има още един бот хомосексуалист, с това можете да направите автоматизирана настройка на контролни точки. Ще се случи ли това някога в Postgres? Не знам, това дори не се обсъжда още. Още сме далеч от това. Но има учени, които правят нови системи. И ни набутват в автоматични индекси. Има развитие. Например, можете да разгледате автоматичната настройка. Избира параметри автоматично. Но той все още няма да направи настройка на контролни точки вместо вас. Тоест, ще избере за производителност, буфер на обвивката и т.н.

А за настройка на контролна точка можете да направите следното: ако имате хиляди клъстери и различни хардуерни части, различни виртуални машини в облака, можете да използвате нашия бот хомосексуалист направи автоматизация. И max_wal_size ще бъде избран автоматично според вашите целеви настройки. Но засега това дори не е близо до това да е в ядрото, за съжаление.

Добър ден Говорихте за опасностите от дългите сделки. Казахте, че автоматичното вакуумиране се блокира в случай на изтриване. Как иначе ни вреди това? Защото говорим повече за освобождаване на място и възможността да го използваме. Какво още имаме да губим?

Автовакуумът може да не е най-големият проблем тук. А фактът, че една дълга транзакция може да блокира други транзакции, е по-опасна възможност. Тя може или не може да се срещне. Ако се срещне, тогава нещата може да са много лоши. А при автовакуума това също е проблем. Има два проблема с дългите транзакции в OLTP: ключалки и автовакуум. И ако имате активирана обратна връзка в горещ режим на готовност на репликата, тогава автоматичното вакуумно блокиране ще пристигне и при главния, то ще пристигне от репликата. Но там поне няма да има ключалки. И тук ще има ключалки. Говорим за промени в данните, така че ключалките са важен момент тук. И ако това продължи дълго, дълго време, тогава все повече и повече транзакции се блокират. Те могат да хванат другите в капан. И се появяват ключалки. Дадох линк към фрагмента. И този проблем бързо става по-забележим от проблема с автовакуума, който може само да се натрупва.

Благодаря за доклада! Започнахте доклада си, като казахте, че сте тествали неправилно. Продължихме идеята си, че трябва да вземем същото оборудване, с абсолютно същата основа. Да кажем, че сме дали на разработчика база. И той изпълни молбата. И изглежда, че се справя добре. Но не се проверява на живо, но на живо например натоварването ни е 60-70%. И дори да използваме тази настройка, не се получава много добре

Важно е да имате експерт в екипа си и да използвате DBA експерти, които могат да предвидят какво ще се случи при реално фоново натоварване. Когато просто преминем през нашите чисти промени, виждаме картината. Но по-напредналият подход беше, когато направихме същото нещо отново, но със симулирано производствено натоварване. Това е напълно готино. Все още трябва да израснем до тази точка. Това е зряло. Гледахме чисто с какво разполагаме и дали имаме достатъчно ресурси. Това е добър въпрос.

Когато вече правим garbage select и имаме например изтрит флаг

Това е, което autovacuum прави автоматично в Postgres.

О, той прави това?

Автовакуумът е събирач на боклук.

Благодаря ви!

Благодаря за доклада! Има ли опция за незабавно проектиране на база данни с разделяне, така че целият боклук да бъде премахнат от главната таблица някъде отстрани?

Разбира се, че има.

Можем ли тогава да се защитим, ако сме заключили маса, която не трябва да се използва?

Разбира се, че има. Но това е въпрос за кокошка и яйце. Ако всички знаем какво ще се случи в бъдеще, тогава, разбира се, ще направим всичко страхотно. Но бизнесът се променя, появяват се нови колони и нови заявки. И тогава - опа, искаме да го изтрием. Но това е идеална ситуация, случва се в живота, но не винаги. Но като цяло е добра идея. Просто съкратете и това е.

Източник: www.habr.com