Некаде во далечна иднина, автоматското отстранување на непотребните податоци ќе биде една од важните задачи на DBMS [1]. Во меѓувреме, ние самите треба да се погрижиме за бришење или преместување на непотребните податоци во поевтини системи за складирање. Да речеме дека одлучивте да избришете неколку милиони редови. Прилично едноставна задача, особено ако состојбата е позната и постои соодветен индекс. „ИЗБРИШИ ОД табела1 WHERE col1 = :value“ - што може да биде поедноставно, нели?
Видео:
-
Во програмскиот комитет на Хајлоуд сум од првата година, односно од 2007 година.
-
И јас сум во Postgres од 2005 година. Го користеше во многу проекти.
-
Група со RuPostges, исто така, од 2007 година.
-
Пораснавме на 2100+ учесници на Meetup. Тој е втор во светот по Њујорк, претекнат од Сан Франциско долго време.
-
Јас живеам во Калифорнија неколку години. Повеќе се занимавам со американски компании, вклучително и големи. Тие се активни корисници на Postgres. И има секакви интересни работи.
е моја компанија. Ние сме во бизнисот со автоматизирање на задачите кои го елиминираат забавувањето на развојот.
Ако правите нешто, тогаш понекогаш има некакви приклучоци околу Postgres. Да речеме дека треба да почекате администраторот да ви постави штанд за тестирање или треба да почекате DBA да ви одговори. А таквите тесни грла наоѓаме во процесот на развој, тестирање и администрација и се обидуваме да ги елиминираме со помош на автоматизација и нови пристапи.
Неодамна бев во VLDB во Лос Анџелес. Ова е најголемата конференција за бази на податоци. И имаше извештај дека во иднина DBMS не само што ќе складира, туку и автоматски ќе ги брише податоците. Ова е нова тема.
Има се повеќе податоци во светот на зетабајти - тоа се 1 петабајти. И сега веќе се проценува дека имаме повеќе од 000 зетабајти складирани податоци во светот. И ги има се повеќе и повеќе.
И што да се прави со тоа? Очигледно треба да се отстрани. Еве линк до овој интересен извештај. Но, досега ова не е имплементирано во DBMS.
Тие што знаат да бројат пари сакаат две работи. Сакаат да избришеме, па технички би требало да можеме да го направиме тоа.
Она што ќе го кажам понатаму е некоја апстрактна ситуација која вклучува еден куп реални ситуации, односно еден вид компилација на она што всушност ми се случило со мене и околните бази на податоци многу пати, многу години. Греблите се насекаде и сите постојано газат на нив.
Да речеме дека имаме база или неколку бази кои растат. А некои записи се очигледно ѓубре. На пример, корисникот почна да прави нешто таму, но не го заврши. И по некое време знаеме дека ова недовршено повеќе не може да се складира. Односно, би сакале да исчистиме некои работи за ѓубре за да заштедиме простор, да ги подобриме перформансите итн.
Во принцип, задачата е да се автоматизира отстранувањето на одредени работи, специфични линии во некоја табела.
И ние имаме такво барање, за кое ќе зборуваме денеска, односно за отстранување на сметот.
Побаравме искусен програмер да го направи тоа. Тој го зеде ова барање, го провери сам - сè функционира. Тестирано на постановка - сè е во ред. Излезено - сè работи. Еднаш дневно го работиме - сè е во ред.
Базата на податоци расте и расте. Дневното бришење почнува да работи малку побавно.
Тогаш разбираме дека сега имаме маркетинг компанија и сообраќајот ќе биде неколкукратно поголем, па затоа одлучуваме привремено да ги паузираме непотребните работи. И заборави да се вратиш.
Неколку месеци подоцна се сетија. И тој развивач се откажа или е зафатен со нешто друго, му наложи на друг да го врати.
Проверуваше на dev, на инсценирање - се е во ред. Секако, сè уште треба да го исчистите она што се акумулирало. Тој провери дека сè работи.
Што ќе се случи следно? Тогаш сè ни се распаѓа. Паѓа така што во одреден момент сè паѓа. Сите се во шок, никој не разбира што се случува. И тогаш излегува дека работата била во овој БРИШИ.
Нешто тргна наопаку? Еве листа на она што би можело да тргне наопаку. Кое од овие е најважно?
-
На пример, немаше преглед, т.е експертот за ДБА не го погледна. Веднаш би го пронашол проблемот со искусно око, а освен тоа, има пристап и до прод, каде што се насобрале неколку милиони линии.
-
Можеби провериле нешто погрешно.
-
Можеби хардверот е застарен и треба да ја надградите оваа база.
-
Или нешто не е во ред со самата база на податоци и треба да се префрлиме од Postgres во MySQL.
-
Или можеби нешто не е во ред со операцијата.
-
Можеби има некои грешки во организацијата на работата и треба да отпуштите некого и да ги вработите најдобрите луѓе?
Немаше проверка на ДБА. Да има DBA, тој би ги видел овие неколку милиони линии и дури и без никакви експерименти би рекол: „Тие не го прават тоа“. Да претпоставиме дека ако овој код беше во GitLab, GitHub и ќе имаше процес на прегледување на кодот и не беше таков што без одобрение на DBA оваа операција ќе се одвива на прод, тогаш очигледно DBA ќе рече: „Ова не може да се направи. ”
И тој би рекол дека ќе имаш проблеми со IO на дискот и сите процеси ќе полудат, може да има брави, а исто така ќе блокираш автовакуум за еден куп минути, така што ова не е добро.
Втората грешка - провериле на погрешно место. Видовме после фактот дека многу непотребни податоци се акумулираа на прод, но развивачот немаше акумулирани податоци во оваа база на податоци и никој не го создаде овој ѓубре за време на поставувањето. Соодветно на тоа, имаше 1 линии кои брзо успеаја.
Ние разбираме дека нашите тестови се слаби, односно процесот што е изграден не фаќа проблеми. Не беше изведен соодветен DB експеримент.
Идеален експеримент е пожелно да се спроведе на истата опрема. Не е секогаш можно ова да се направи на иста опрема, но многу е важно тоа да биде копија од базата на податоци со целосна големина. Ова е она што го проповедам веќе неколку години. И пред една година зборував за ова, можете сето тоа да го гледате на YouTube.
Можеби нашата опрема е лоша? Ако погледнете, тогаш латентноста скокна. Видовме дека искористеноста е 100%. Се разбира, ако ова беа модерни NVMe дискови, тогаш веројатно ќе ни беше многу полесно. И можеби не би отстапиле од тоа.
Ако имате облаци, тогаш надградбата лесно се прави таму. Подигна нови копии на новиот хардвер. префрлување. И се е добро. Прилично лесно.
Дали е можно некако да се допираат помалите дискови? И тука, само со помош на DBA, се нурнуваме во одредена тема наречена подесување на контролни точки. Излегува дека немавме подесување на контролен пункт.
Што е контролен пункт? Тоа е во било кој DBMS. Кога имате податоци во меморијата што се менуваат, тие не се запишуваат веднаш на дискот. Информациите дека податоците се променети прво се запишуваат во дневникот за однапред запишување. И во одреден момент, DBMS одлучува дека е време да се исфрлат вистинските страници на дискот, за ако имаме дефект, да можеме да правиме помалку ПОВТОРУВАЊЕ. Тоа е како играчка. Ако бидеме убиени, ќе ја започнеме играта од последниот контролен пункт. И сите DBMS го имплементираат.
Поставките во Postgres заостануваат. Тие се дизајнирани за 10-15 години стари томови на податоци и трансакции. И контролниот пункт не е исклучок.
Еве ги информациите од нашиот извештај за проверка на Postgres, односно автоматска здравствена проверка. И еве некоја база на податоци од неколку терабајти. И добро се гледа дека форсирани контролни пунктови во речиси 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.
И на овој начин ќе го размениме нашиот систем, и знаеме како ќе се однесува DBMS во случај на лошо масовно DELETE, како ќе го контролира пунктот.
Контролниот пункт на руски се контролни пунктови.
Пример: ИЗБРИШЕТЕ неколку милиони редови по индекс, редовите се „расфрлани“ по страниците.
Еве еден пример. Ова е некоја основа. И со стандардната поставка од 1 гигабајт за max_wal_size, многу е јасно дека нашите дискови одат на полицата за снимање. Оваа слика е типичен симптом на многу болен пациент, односно тој навистина се чувствувал лошо. И имаше една операција, имаше само БРИШЕЊЕ од неколку милиони линии.
Ако е дозволена таква операција во прод, тогаш само ќе легнеме, бидејќи јасно е дека едно БРИШЕЊЕ не убива на полицата.
Понатаму, каде што 16 гигабајти, јасно е дека забите веќе поминале. Забите се веќе подобри, односно тропаме на таван, но не толку лошо. Имаше одредена слобода таму. На десната страна е рекордот. И бројот на операции - вториот графикон. И јасно е дека веќе дишеме малку полесно кога 16 гигабајти.
И каде 64 гигабајти се гледа дека стана сосема подобро. Веќе забите се изговараат, има повеќе можности да се преживеат други операции и да се направи нешто со дискот.
Зошто така?
Малку ќе нурнам во деталите, но оваа тема, како да се спроведе подесување на контролната точка, може да резултира со цел извештај, така што нема да вчитам многу, но малку ќе наведам какви потешкотии има.
Ако контролниот пункт се случува премногу често, а ние ги ажурираме нашите линии не последователно, туку наоѓаме по индекс, што е добро, бидејќи не ја бришеме целата табела, тогаш може да се случи прво да ја допреме првата страница, потоа илјадитата, а потоа се врати на првиот . И ако помеѓу овие посети на првата страница, контролната точка веќе ја зачувала на дискот, тогаш повторно ќе ја зачува, бидејќи ја извалкавме по втор пат.
И ние ќе го принудиме контролниот пункт да го зачува многу пати. Како би имало вишок операции за него.
Но, тоа не е се. Страниците се 8 килобајти во Postgres и 4 килобајти во Linux. И има поставка full_page_writes. Стандардно е овозможено. И ова е точно, бидејќи ако го исклучиме, тогаш постои опасност да се зачува само половина од страницата ако падне.
Однесувањето на пишување во WAL на дневникот напред е такво што кога имаме контролен пункт и ја менуваме страницата за прв пат, целата страница, т.е. сите 8 килобајти, влегува во дневникот напред, иако го сменивме само линија, која тежи 100 бајти. И ние треба да ја запишеме целата страница.
Во следните промени ќе има само одредена торка, но за прв пат запишуваме сè.
И, соодветно, ако контролниот пункт се случи повторно, тогаш треба повторно да започнеме сè од нула и да ја туркаме целата страница. Со чести контролни точки, кога одиме низ истите страници, full_page_writes = on ќе биде повеќе отколку што би можело да биде, т.е. генерираме повеќе WAL. Повеќе се испраќаат на реплики, во архива, на диск.
И, соодветно, имаме два технолошки вишок.
Ако ја зголемиме max_wal_size, излегува дека им олеснуваме и на контролната точка и на wal writer-от. И тоа е одлично.
Ајде да ставиме терабајт и да живееме со него. Што е лошо во тоа? Ова е лошо, затоа што во случај на неуспех ќе се качуваме со часови, бидејќи контролниот пункт беше одамна и веќе многу се сменија. И ние треба да го направиме сето ова ПОВТОРУВАЊЕ. И така ја правиме втората серија на експерименти.
Правиме операција и гледаме кога контролниот пункт ќе заврши, намерно го убиваме -9 Постгрес.
И после тоа го започнуваме повторно, па ќе видиме колку долго ќе се крева на оваа опрема, т.е. колку ќе ПОВТОРИ во оваа лоша ситуација.
Двапати ќе забележам дека ситуацијата е лоша. Прво, удривме непосредно пред да заврши контролниот пункт, така што имаме многу да изгубиме. И второ, имавме масовна операција. И ако контролните пунктови беа на тајмаут, тогаш, најверојатно, ќе се генерира помалку WAL од последниот контролен пункт. Односно, тоа е двоен губитник.
Ние ја мериме таквата ситуација за различни големини max_wal_size и разбираме дека ако max_wal_size е 64 гигабајти, тогаш во двојно најлош случај ќе се искачиме 10 минути. И размислуваме дали ни одговара или не. Ова е деловно прашање. Треба да им ја покажеме оваа слика на одговорните за деловни одлуки и да прашаме: „Колку долго можеме да лежиме најмногу во случај на проблем? Можеме ли да лежиме во најлошата ситуација 3-5 минути? И вие донесете одлука.
И еве една интересна точка. Имаме неколку извештаи за Патрони на конференцијата. И можеби го користите. Ова е автоматско откажување за Postgres. GitLab и Data Egret зборуваа за ова.
И ако имате автоматско откажување што доаѓа за 30 секунди, тогаш можеби можеме да лежиме 10 минути? Затоа што до овој момент ќе се префрлиме на репликата и сè ќе биде во ред. Ова е спорна точка. Не знам јасен одговор. Само чувствувам дека темава не е само околу crash recovery.
Ако имаме долго закрепнување по неуспех, тогаш ќе ни биде непријатно во многу други ситуации. На пример, во истите експерименти, кога правиме нешто и понекогаш треба да чекаме 10 минути.
Сè уште не би отишол предалеку, дури и ако имаме автоматско откажување. Како по правило, вредностите како што се 64, 100 гигабајти се добри вредности. Понекогаш дури вреди да се избере помалку. Во принцип, ова е суптилна наука.
За да направите повторувања, на пример, max_wal_size =1, 8, треба да ја повторите операцијата за маса многу пати. Успеа. И на истата основа сакате да го направите тоа повторно, но веќе сте избришале сè. Што да се прави?
Подоцна ќе зборувам за нашето решение, што правиме за да повторуваме во такви ситуации. И ова е најправилниот пристап.
Но, во овој случај, имавме среќа. Ако, како што пишува овде „ПОЧЕТЕ, ИЗБРИШИ, ВРАЌАЈ“, тогаш можеме да повториме ИЗБРИШИ. Односно, ако самите сме го откажале, тогаш можеме да го повториме. И физички кај вас податоците ќе лежат на истото место. Не добивате ни надуеност. Можете да повторувате над таквите DELETE.
Ова БРИШЕЊЕ со ВРАЌАЊЕ е идеално за подесување на контролната точка, дури и ако немате правилно распоредени лаборатории за бази на податоци.
Направивме чинија со една колона „i“. Postgres има комунални колони. Тие се невидливи освен ако конкретно не се побарани. Тоа се: ctid, xmid, xmax.
Ctid е физичка адреса. Нулта страница, првата торка на страницата.
Се гледа дека по ROOLBACK торката останала на истото место. Тоа е, можеме да се обидеме повторно, ќе се однесува на ист начин. Ова е главната работа.
Xmax е времето на смртта на торката. Имаше печат, но Postgres знае дека оваа трансакција е вратена назад, така што не е важно дали е 0 или е превртена трансакција. Ова сугерира дека можете да повторувате преку DELETE и да ги проверите масовните операции на однесувањето на системот. Можете да направите лаборатории за бази на податоци за сиромашните.
Станува збор за програмери. За DBA, исто така, тие секогаш ги караат програмерите за ова: „Зошто правите толку долги и тешки операции?“. Ова е сосема друга перпендикуларна тема. Порано имаше администрација, а сега ќе има развој.
Очигледно не сме се скршиле на парчиња. Тоа е јасно. Невозможно е да не се скрши такво БРИШЕЊЕ за куп од милиони линии на делови. Ќе се прави 20 минути, и се ќе легне. Но, за жал, дури и искусните програмери прават грешки, дури и во многу големи компании.
Зошто е важно да се скрши?
-
Ако видиме дека дискот е тврд, тогаш да го успориме. И ако сме скршени, тогаш можеме да додадеме паузи, можеме да го забавиме пригушувањето.
-
И нема да ги блокираме другите долго време. Во некои случаи не е важно, ако бришете вистинско ѓубре на кое никој не работи, тогаш најверојатно нема да блокирате никого освен работата со автовакуум, бидејќи ќе чека да заврши трансакцијата. Но, ако отстраните нешто што некој друг може да го побара, тогаш тие ќе бидат блокирани, ќе има некаква верижна реакција. Треба да се избегнуваат долги трансакции на веб-локации и мобилни апликации.
Ова е интересно. Често гледам дека програмерите прашуваат: „Каква големина на пакувањето да изберам?“.
Јасно е дека колку е поголема големината на пакетот, толку се помали трошоците за трансакцијата, т.е. дополнителните трошоци од трансакциите. Но, во исто време, времето за оваа трансакција се зголемува.
Имам многу едноставно правило: земете колку што можете повеќе, но не префрлајте ги извршните датотеки во секунда.
Зошто секунда? Објаснувањето е многу едноставно и разбирливо за секого, дури и за нетехничките луѓе. Гледаме реакција. Да земеме 50 милисекунди. Ако нешто се сменило, тогаш нашето око ќе реагира. Ако помалку, тогаш потешко. Ако нешто реагира по 100 милисекунди, на пример, сте кликнале на глувчето, а тој ви одговори по 100 милисекунди, веќе го чувствувате ова мало доцнење. Втората веќе се перцепира како сопирачки.
Според тоа, ако ги скршиме нашите масовни операции на рафали од 10 секунди, тогаш имаме ризик да блокираме некого. И ќе работи неколку секунди, а луѓето веќе ќе го забележат тоа. Затоа, претпочитам да не правам повеќе од една секунда. Но, во исто време, не го раскинувајте многу фино, бидејќи трансакцијата ќе биде забележлива. Основата ќе биде потешка и може да се појават други различни проблеми.
Ја избираме големината на пакувањето. Во секој случај, можеме да го направиме тоа поинаку. Може да се автоматизира. И ние сме убедени во ефикасноста на обработката на едно пакување. Односно, правиме БРИШЕЊЕ на еден пакет или Ажурирање.
Инаку, се што зборувам не е само за БРИШИЊЕ. Како што претпоставувате, ова се сите масовни операции на податоци.
И гледаме дека планот е одличен. Можете да го видите скенирањето на индексите, скенирањето само со индекс е уште подобро. И имаме мал број податоци вклучени. И помалку од секунда исполнува. Супер.
И уште треба да се погрижиме да нема деградација. Се случува првите пакувања брзо да функционираат, а потоа станува полошо, полошо и полошо. Процесот е таков што треба многу да тестирате. Токму за ова служат лабораториите за бази на податоци.
И уште треба да подготвиме нешто за да ни овозможи правилно да го следиме ова во производството. На пример, можеме да го запишеме времето во дневникот, можеме да напишеме каде сме сега и кој сме го избришале сега. И ова ќе ни овозможи да разбереме што се случува подоцна. И во случај нешто да тргне наопаку, брзо пронајдете го проблемот.
Ако треба да ја провериме ефикасноста на барањата и треба да повторуваме многу пати, тогаш постои такво нешто како колега бот. Тој е веќе подготвен. Секојдневно го користат десетици програмери. И тој знае како да даде огромна база на податоци од терабајти на барање за 30 секунди, ваша сопствена копија. И таму можеш да избришеш нешто и да кажеш RESET, и пак да го избришеш. Можете да експериментирате со него на овој начин. Гледам иднина за оваа работа. И ние веќе го правиме тоа.
Кои се стратегиите за партиционирање? Гледам 3 различни стратегии за партиционирање што ги користат програмерите на пакетот.
Првиот е многу едноставен. Имаме нумеричка лична карта. Ајде да го разложиме на различни интервали и да работиме со тоа. Негативната страна е јасна. Во првиот сегмент може да имаме 100 линии вистинско ѓубре, во вториот 5 реда или воопшто да немаме или сите 1 линии ќе испаднат ѓубре. Многу нерамномерна работа, но лесно се крши. Ја зедоа максималната лична карта и ја искршија. Ова е наивен пристап.
Втората стратегија е балансиран пристап. Се користи во Gitlab. Ја зедоа и ја скенираа масата. Ги најдовме границите на пакетите со лични карти така што секој пакет имаше точно 10 записи. И ставете ги во редица. И потоа обработуваме. Можете да го направите ова во повеќе нишки.
И во првата стратегија, патем, можете да го направите ова во неколку нишки. Не е тешко.
Но, постои поладен и подобар пристап. Ова е трета стратегија. И кога е можно, подобро е да го изберете. Ова го правиме врз основа на посебен индекс. Во овој случај, најверојатно ќе биде индекс според нашата состојба на ѓубре и лична карта. Ќе го вклучиме идентификаторот за да биде само индексно скенирање за да не одиме на купот.
Општо земено, скенирањето само индекс е побрзо од скенирањето индекси.
И брзо ги наоѓаме нашите лични карти што сакаме да ги отстраниме. BATCH_SIZE го избираме однапред. И ние не само што ги добиваме, туку ги добиваме на посебен начин и веднаш ги хакираме. Но, ние заклучуваме за ако веќе се заклучени, да не ги заклучиме, туку да продолжиме и да ги земеме следните. Ова е за ажурирање, прескокнувањето е заклучено. Оваа супер карактеристика на Postgres ни овозможува да работиме во неколку нишки ако сакаме. Можно е во еден поток. И тука има CTE - ова е едно барање. И имаме вистинско бришење што се случува на вториот кат на овој CTE - returning *. Можеш да вратиш ид, но подобро е *ако немате многу податоци за секоја линија.
Зошто ни е потребно? Ова е она што треба да го пријавиме. Сега всушност избришавме толку многу линии. И ние имаме граници по ID или со create_at вака. Можете да направите мин, макс. Може да се направи нешто друго. Овде можеш да работиш многу. И тоа е многу погодно за следење.
Има уште една забелешка за индексот. Ако одлучиме дека ни е потребен посебен индекс за оваа задача, тогаш треба да се погрижиме да не ги расипе ажурирањата само на купчињата. Односно, Postgres има таква статистика. Ова може да се види во pg_stat_user_tables за вашата табела. Може да видите дали се користат топли ажурирања или не.
Има ситуации кога вашиот нов индекс може едноставно да ги отсече. И ги имате сите други ажурирања што веќе работат, успорете. Не само затоа што се појави индексот (секој индекс ги успорува ажурирањата по малку, но малку), туку овде сепак го уништува. И невозможно е да се направи посебна оптимизација за оваа табела. Ова се случува понекогаш. Ова е толку суптилност што малку луѓе се сеќаваат. И ова гребло е лесно да се нагази. Понекогаш се случува да треба да најдете пристап од другата страна, а сепак да го направите без овој нов индекс, или да направите друг индекс, или на некој друг начин, на пример, да го користите вториот метод.
Но, ова е најоптималната стратегија, како да се поделите на серии и да пукате во серии со едно барање, да избришете малку итн.
Долги трансакции
Блокиран автовакуум -
проблем со блокирање -
Грешката број 5 е голема. Николај од Окметар зборуваше за мониторингот на Postgres. Идеален Postgres мониторинг, за жал, не постои. Некои се поблиску, некои се подалеку. Okmeter е доволно блиску до совршенство, но многу недостасува и треба да се додаде. Треба да бидете подготвени за ова.
На пример, мртвите торки најдобро се следат. Ако имате многу мртви работи на табелата, тогаш нешто не е во ред. Подобро сега да се реагира, инаку може да дојде до деградација, па да си легнеме. Се случува.
Ако има голем IO, тогаш јасно е дека ова не е добро.
Долги трансакции исто така. Не треба да се дозволуваат долги трансакции на OLTP. И еве линк до фрагмент кој ви овозможува да го земете овој фрагмент и веќе да направите одредено следење на долгите трансакции.
Зошто долгите трансакции се лоши? Затоа што сите брави ќе бидат ослободени само на крајот. И ги заебаме сите. Плус, блокираме автовакуум за сите маси. Воопшто не е добро. Дури и ако имате овозможено hot standby на репликата, сепак е лошо. Во принцип, никаде не е подобро да се избегнат долгите трансакции.
Ако имаме многу табели кои не се вакумирани, тогаш треба да имаме предупредување. Тука е можна таква ситуација. Можеме индиректно да влијаеме на работата на автовакуумот. Ова е фрагмент од Avito, кој малку го подобрив. И се покажа како интересна алатка за да видиме што имаме со автовакуумот. На пример, некои маси чекаат таму и нема да го чекаат својот ред. Исто така, треба да го ставите во мониторинг и да имате предупредување.
И издава блокови. Шума од блок дрвја. Сакам да земам нешто од некого и да го подобрувам. Овде зедов кул рекурзивен CTE од Data Egret што покажува шума од заклучени дрвја. Ова е добра дијагностичка алатка. И врз основа на тоа, можете исто така да изградите мониторинг. Но, ова мора да се направи внимателно. Треба да направите мал statement_timeout за себе. И lock_timeout е пожелно.
Понекогаш сите овие грешки се случуваат во сума.
Според мене, главната грешка овде е организационата. Организациско е, бидејќи техниката не влече. Ова е број 2 - провериле на погрешно место.
Проверивме на погрешно место, бидејќи немавме производствен клон, што е лесно да се провери. Програмер може воопшто да нема пристап до производството.
И ние проверивме не таму. Да проверевме таму, ќе го видиме и самите. Програмерот го виде сето тоа дури и без DBA ако го провери во добра средина, каде што има иста количина на податоци и идентична локација. Ќе ја видеше целата оваа деградација и ќе се засрамеше.
Повеќе за автовакуум. Откако направивме масовно чистење од неколку милиони линии, сè уште треба да направиме REPACK. Ова е особено важно за индексите. Ќе им биде лошо откако ќе исчистиме се таму.
И ако сакате да ја вратите секојдневното чистење, тогаш би ви предложил да го правите тоа почесто, но помало. Може да биде еднаш во минута или уште почесто малку. И треба да следите две работи: дека оваа работа нема грешки и дека не заостанува. Трикот што го покажав само ќе го реши ова.
Она што го правиме е со отворен код. Објавено е на GitLab. И го правиме тоа така што луѓето можат да проверуваат дури и без DBA. Правиме лабораторија за бази на податоци, односно ја нарекуваме основната компонента на која моментално работи Џо. И можете да земете копија од производството. Сега постои имплементација на Joe for Slack, можете да кажете таму: „објасни такво и такво барање“ и веднаш да го добиеш резултатот за вашата копија од базата на податоци. Таму можете дури и да БРИШИ, и никој нема да го забележи.
Да речеме дека имате 10 терабајти, ние правиме лабораторија за бази на податоци исто така 10 терабајти. И со симултани бази на податоци од 10 терабајти, 10 програмери можат да работат истовремено. Секој може да прави што сака. Може да брише, испушти итн. Тоа е таква фантазија. За ова ќе разговараме утре.
Ова се нарекува тенко обезбедување. Ова е суптилно обезбедување. Ова е некаква фантазија која во голема мера ги отстранува одложувањата во развојот, тестирањето и го прави светот подобро место во овој поглед. Тоа е, тоа само ви овозможува да избегнете проблеми со масовните операции.
Пример: база на податоци од 5 терабајти, добивање копија за помалку од 30 секунди. И тоа дури и не зависи од големината, односно не е важно колку терабајти.
Денес можете да одите на и копаат во нашите алатки. Можете да се регистрирате за да видите што има таму. Можете да го инсталирате овој бот. Бесплатно е. Напиши.
прашања
Многу често во реални ситуации излегува дека податоците што треба да останат во табелата се многу помалку од оние што треба да се избришат. Односно, во таква ситуација, често е полесно да се имплементира таков пристап, кога е полесно да се создаде нов објект, да се копираат само потребните податоци таму и да се склопи старата табела. Јасно е дека за овој момент е потребен програмски пристап додека вие ќе се префрлите. Како е овој пристап?
Ова е многу добар пристап и многу добра задача. Тоа е многу слично на она што го прави pg_repack, многу е слично на она што треба да го направите кога правите ID 4 бајти. Многу рамки го направија ова пред неколку години, а само плочите пораснаа и тие треба да се претворат во 8 бајти.
Оваа задача е доста тешка. Ние го направивме тоа. И треба да бидете многу внимателни. Има брави итн. Но, тоа се прави. Тоа е, стандардниот пристап е да се оди со pg_repack. Вие изјавувате таква етикета. И пред да започнете да поставувате податоци од снимката во неа, вие исто така пријавувате една плоча што ги следи сите промени. Постои трик со кој можеби нема ни да следите некои промени. Постојат суптилности. А потоа се префрлате со превртување на промените. Ќе има кратка пауза кога ќе ги затвориме сите, но генерално ова се прави.
Ако го погледнете pg_repack на GitHub, тогаш таму, кога имаше задача да се конвертира ID од int 4 во int 8, тогаш имаше идеја да се користи самиот pg_repack. Ова е исто така можно, но тоа е малку пробивање, но ќе работи и за ова. Можете да интервенирате во активирањето што го користи pg_repack и таму да кажете: „Не ни требаат овие податоци“, односно го пренесуваме само она што ни треба. И тогаш само се префрла и тоа е тоа.
Со овој пристап, сепак добиваме втора копија од табелата, во која податоците се веќе индексирани и наредени многу рамномерно со прекрасни индекси.
Блат не е присутен, тоа е добар пристап. Но, знам дека има обиди да се развие автоматизација за ова, односно да се направи универзално решение. Можам да ве контактирам со оваа автоматизација. Напишано е во Python, што е добра работа.
Јас сум само малку од светот на MySQL, па дојдов да слушам. И ние го користиме овој пристап.
Но, тоа е само ако имаме 90%. Ако имаме 5%, тогаш не е многу добро да го користиме.
Ви благодариме за извештајот! Ако нема ресурси за да се направи целосна копија од прод, дали постои алгоритам или формула за пресметување на оптоварувањето или големината?
Добро прашање. Досега, можеме да најдеме бази на податоци од повеќе терабајти. Дури и ако хардверот таму не е ист, на пример, помалку меморија, помалку процесор и дискови не се сосема исти, но сепак ние го правиме тоа. Ако нема апсолутно никаде, тогаш треба да размислите. Да размислам до утре, дојдовте, ќе разговараме, ова е добро прашање.
Ви благодариме за извештајот! Прво почнавте за тоа дека постои кул Postgres, кој има такви и такви ограничувања, но се развива. И сето ова е патерица во голема мера. Зарем сето ова не е во конфликт со самиот развој на Postgres, во кој ќе се појави некој DELETE deferent или нешто друго што треба да го држи на ниско ниво она што се обидуваме да го замачкаме со некои наши чудни средства овде?
Ако рековме во SQL да избришете или ажурирате многу записи во една трансакција, тогаш како Postgres може да го дистрибуира таму? Физички сме ограничени во работењето. Уште долго ќе го правиме тоа. И ќе заклучиме во ова време итн.
Завршено со индекси.
Можам да претпоставам дека истото подесување на контролната точка може да биде автоматизирано. Еден ден може да биде. Но, тогаш навистина не го разбирам прашањето.
Прашањето е дали постои таков вектор на развој што оди ваму-таму, а овде вашиот оди паралелно? Оние. Уште не размислувале за тоа?
Зборував за принципите што можат да се користат сега. Има уште еден бот , со ова можете да направите автоматско подесување на контролната точка. Дали некогаш ќе биде во Постгрес? Не знам, сè уште не е ни разговарано. Сè уште сме далеку од тоа. Но, постојат научници кои прават нови системи. И нè туркаат во автоматски индекси. Има случувања. На пример, можете да погледнете автоматско подесување. Автоматски ги избира параметрите. Но, тој сè уште нема да ви направи подесување на контролната точка. Тоа е, ќе се подигне за перформанси, тампон на школка, итн.
И за подесување на контролната точка, можете да го направите ова: ако имате илјада кластери и различен хардвер, различни виртуелни машини во облакот, можете да го користите нашиот бот направи автоматизација. И max_wal_size ќе се избере автоматски според вашите целни поставки. Но, досега ова не е ни блиску во суштината, за жал.
Добар ден Зборувавте за опасностите од долгите трансакции. Рековте дека автовакуумот е блокиран во случај на бришења. Како инаку ни штети? Затоа што повеќе зборуваме за ослободување простор и можност за користење. Што друго ни недостасува?
Автовакуумот можеби не е најголемиот проблем овде. И фактот дека долга трансакција може да ги заклучи другите трансакции, оваа можност е поопасна. Таа може да се сретне или не. Ако се запознала, тогаш може да биде многу лошо. И со автовакуум - ова е исто така проблем. Има два проблеми со долгите трансакции во OLTP: брави и автовакуум. И ако имате овозможено топла повратна информација на репликата, тогаш сепак ќе добиете автовакуумско заклучување на главниот, тоа ќе пристигне од репликата. Но, барем нема да има брави. И ќе има лопови. Зборуваме за промени на податоците, така што бравите се важна точка овде. И ако сето ова е долго, долго, тогаш се повеќе и повеќе трансакции се заклучуваат. Можат да украдат други. И се појавуваат лок дрвја. Дадов линк до фрагментот. И овој проблем станува позабележителен побрзо од проблемот со автовакуумот, кој може само да се акумулира.
Ви благодариме за извештајот! Го започнавте вашиот извештај велејќи дека сте тестирале погрешно. Ја продолживме нашата идеја дека треба да ја земеме истата опрема, со основата на ист начин. Да речеме дека му дадовме база на развивачот. И тој го исполни барањето. И се чини дека е добро. Ама не проверува за во живо, туку за во живо на пример имаме оптоварување од 60-70%. И дури и ако го користиме ова подесување, тоа не функционира многу добро.
Важно е да имате експерт во тимот и да користите експерти за DBA кои можат да предвидат што ќе се случи со вистинско оптоварување во позадина. Кога само ги возевме нашите чисти промени, ја гледаме сликата. Но, понапреден пристап, кога повторно го направивме истото, но со оптоварување симулирано со производство. Тоа е сосема кул. Дотогаш треба да пораснеш. Тоа е како возрасен човек. Само погледнавме што имаме и исто така погледнавме дали имаме доволно ресурси. Тоа е добро прашање.
Кога веќе правиме ѓубре изберете и имаме, на пример, избришано знаменце
Ова е она што автовакуумот го прави автоматски во Postgres.
О, дали го прави тоа?
Автовакуумот е собирач на ѓубре.
Ви благодариме!
Ви благодариме за извештајот! Дали постои опција веднаш да се дизајнира база на податоци со партиција на таков начин што целото ѓубре ќе се извалка од главната маса некаде на страна?
Секако дека има.
Дали е можно тогаш да се заштитиме ако сме заклучиле маса што не треба да се користи?
Секако дека има. Но, тоа е како прашање на пилешко и јајце. Ако сите знаеме што ќе се случи во иднина, тогаш, се разбира, ќе сториме сè што е кул. Но, бизнисот се менува, има нови колумни, нови барања. А потоа – упс, сакаме да го отстраниме. Но, оваа идеална ситуација, во животот се случува, но не секогаш. Но, генерално, тоа е добра идеја. Само скрати и толку.
Извор: www.habr.com