DBA bot Joe. Anatolij Stansler (Postgres.ai)

Kako backend programer razumije da će SQL upit dobro funkcionirati na "prod"? U velikim ili brzorastućim tvrtkama nema svatko pristup "proizvodu". A uz pristup, ne mogu se svi zahtjevi bezbolno provjeriti, a stvaranje kopije baze podataka često traje satima. Kako bismo riješili te probleme, stvorili smo umjetni DBA - Joe. Već je uspješno implementiran u nekoliko tvrtki i pomaže više od desetak programera.

Video:

Bok svima! Moje ime je Anatolij Stansler. Radim za tvrtku postgres.ai. Posvećeni smo ubrzanju procesa razvoja uklanjanjem kašnjenja povezanih s radom Postgresa od programera, DBA i QA-a.

Imamo sjajne klijente i danas ćemo dio reportaže posvetiti slučajevima s kojima smo se susreli radeći s njima. Govorit ću o tome kako smo im pomogli u rješavanju vrlo ozbiljnih problema.

Kada razvijamo i provodimo složene migracije s velikim opterećenjem, postavljamo si pitanje: "Hoće li ova migracija zaživjeti?". Koristimo recenziju, koristimo znanje iskusnijih kolega, DBA stručnjaka. I oni mogu reći hoće li letjeti ili ne.

Ali možda bi bilo bolje da ga sami možemo testirati na kopijama u punoj veličini. A danas ćemo samo razgovarati o tome koji su sada pristupi testiranju i kako se to može učiniti bolje i s kojim alatima. Također ćemo govoriti o prednostima i manama takvih pristupa, te o tome što ovdje možemo popraviti.

Tko je ikada napravio indekse izravno na proizvodu ili napravio bilo kakve promjene? Prilično malo. I za koga je to dovelo do gubitka podataka ili zastoja? Onda znaš ovu bol. Hvala Bogu da postoje rezervne kopije.

Prvi pristup je testiranje u prod. Ili, kada programer sjedi na lokalnom računalu, ima testne podatke, postoji neka vrsta ograničenog izbora. I izbacimo se na proizvod, i dobijemo ovu situaciju.

Boli, skupo je. Vjerojatno je najbolje ne raditi.

I koji je najbolji način za to?

Uzmimo inscenaciju i odaberimo tamo neki dio produkcije. Ili u najboljem slučaju, uzmimo pravi prod, sve podatke. A nakon što ga lokalno razvijemo, dodatno ćemo provjeriti ima li inscenacija.

To će nam omogućiti da uklonimo neke od grešaka, tj. spriječimo da budu na prod.

Koji su problemi?

• Problem je što tu inscenaciju dijelimo s kolegama. I vrlo često se dogodi da napravite neku promjenu, bam - a podataka nema, posao je propao. Inscenacija je bila višeterabajtna. I treba dugo čekati da ponovno ustane. I odlučili smo to finalizirati sutra. To je to, imamo razvoj.
• I, naravno, imamo mnogo kolega koji tamo rade, mnogo timova. I to se mora učiniti ručno. A ovo je nezgodno.

I vrijedi reći da imamo samo jedan pokušaj, jedan pokušaj, ako želimo napraviti neke promjene u bazi podataka, dodirnuti podatke, promijeniti strukturu. A ako je nešto pošlo po zlu, ako je došlo do greške u migraciji, nećemo se brzo vratiti.

Ovo je bolje od prethodnog pristupa, ali još uvijek postoji velika vjerojatnost da će neka vrsta greške otići u proizvodnju.

Što nas sprječava da svakom programeru damo testnu klupu, kopiju u punoj veličini? Mislim da je jasno što stoji na putu.

Tko ima bazu podataka veću od terabajta? Više od pola sobe.

I jasno je da je držanje strojeva za svakog razvijača, kada postoji tako velika proizvodnja, jako skupo, a osim toga i dugo traje.

Imamo klijente koji su shvatili da je vrlo važno testirati sve promjene na kopijama u punoj veličini, ali njihova baza podataka je manja od terabajta i nema resursa za održavanje testnog stola za svakog programera. Stoga moraju preuzeti deponije lokalno na svoje računalo i testirati na ovaj način. Potrebno je puno vremena.

Čak i ako to radite unutar infrastrukture, tada je preuzimanje jednog terabajta podataka na sat već vrlo dobro. Ali koriste logičke deponije, preuzimaju lokalno iz oblaka. Kod njih je brzina oko 200 gigabajta na sat. I dalje je potrebno vrijeme da se okrenete s logičkog dumpa, smotate indekse itd.

Ali oni koriste ovaj pristup jer im omogućuje da proizvod bude pouzdan.

Što možemo učiniti ovdje? Učinimo testne stolove jeftinijima i dajmo svakom programeru vlastitu testnu stolicu.

I ovo je moguće.

I u ovom pristupu, kada napravimo tanke klonove za svakog programera, možemo to podijeliti na jednom stroju. Na primjer, ako imate bazu podataka od 10TB i želite je dati 10 programera, ne morate imati baze podataka od XNUMX x XNUMXTB. Potreban vam je samo jedan stroj za izradu tankih izoliranih kopija za svakog programera pomoću jednog stroja. Reći ću vam kako to radi malo kasnije.

Pravi primjer:

• DB - 4,5 terabajta.

• Možemo dobiti nezavisne kopije za 30 sekundi.

Ne morate čekati testni stalak i ovisiti o tome koliko je velik. Možete ga dobiti za nekoliko sekundi. Bit će to potpuno izolirana okruženja, ali koja međusobno dijele podatke.

Ovo je super. Ovdje govorimo o magiji i paralelnom svemiru.

U našem slučaju to radi pomoću sustava OpenZFS.

OpenZFS je datotečni sustav kopiranja na pisanje koji podržava brze snimke i klonove. Pouzdan je i skalabilan. Njom se vrlo lako upravlja. Doslovno se može rasporediti u dva tima.

Postoje i druge opcije:

• lvm,

• Pohrana (na primjer, Pure Storage).

Database Lab o kojem govorim je modularan. Može se implementirati pomoću ovih opcija. Ali za sada smo se fokusirali na OpenZFS, jer je bilo problema konkretno s LVM-om.

Kako radi? Umjesto prepisivanja podataka svaki put kad ih promijenimo, spremamo ih jednostavnim označavanjem da su ti novi podaci iz nove vremenske točke, nove snimke.

I ubuduće, kada se želimo vratiti ili želimo napraviti novi klon od neke starije verzije, samo kažemo: "OK, daj nam ove blokove podataka koji su ovako označeni."

I ovaj će korisnik raditi s takvim skupom podataka. Postupno će ih mijenjati, napraviti vlastite snimke.

I mi ćemo granati. Svaki developer u našem slučaju imat će priliku imati svoj klon kojeg uređuje, a podaci koji se dijele dijelit će se između svih.

Da biste implementirali takav sustav kod kuće, morate riješiti dva problema:

• Prvi je izvor podataka, odakle ćete ih uzeti. Možete postaviti replikaciju s proizvodnjom. Nadam se da već možete koristiti sigurnosne kopije koje ste konfigurirali. WAL-E, WAL-G ili Barman. Čak i ako koristite neku vrstu Cloud rješenja kao što je RDS ili Cloud SQL, tada možete koristiti logičke ispise. Ali ipak vam savjetujemo da koristite sigurnosne kopije, jer ćete ovim pristupom također zadržati fizičku strukturu datoteka, što će vam omogućiti da budete još bliže metrici koju biste vidjeli u proizvodnji kako biste uhvatili te probleme koji postoje.

• Drugo je mjesto gdje želite smjestiti Database Lab. To može biti Cloud, može biti On-premise. Ovdje je važno reći da ZFS podržava kompresiju podataka. I čini to prilično dobro.

Zamislite da će za svaki takav klon, ovisno o operacijama koje radimo s bazom, izrasti neka vrsta programera. Za ovo će dev također trebati prostor. Ali zbog činjenice da smo uzeli bazu od 4,5 terabajta, ZFS će je komprimirati na 3,5 terabajta. To može varirati ovisno o postavkama. I još uvijek imamo mjesta za programere.

Takav sustav može se koristiti za različite slučajeve.

• To su programeri, DBA za provjeru valjanosti upita, za optimizaciju.

• Ovo se može upotrijebiti u QA testiranju za testiranje određene migracije prije nego što je pustimo u proizvodnju. Također možemo podići posebna okruženja za QA sa stvarnim podacima, gdje mogu testirati nove funkcije. I to će trajati nekoliko sekundi umjesto sati čekanja, a možda i dani u nekim drugim slučajevima kada se ne koriste tanke kopije.

• I još jedan slučaj. Ako tvrtka nema postavljen analitički sustav, tada možemo izolirati tanki klon baze proizvoda i dati ga dugim upitima ili posebnim indeksima koji se mogu koristiti u analitici.

Ovim pristupom:

1. Mala vjerojatnost pogreške na "prod", jer smo testirali sve promjene na podacima u punoj veličini.

2. Imamo kulturu testiranja, jer sada ne morate čekati satima na vlastiti štand.

3. I nema prepreka, nema čekanja između testova. Zapravo možete otići i provjeriti. A ovako će biti bolje jer ubrzamo razvoj.

• Bit će manje refaktoriranja. Manje bugova će završiti u prod. Kasnije ćemo ih manje refaktorirati.

• Možemo poništiti nepovratne promjene. Ovo nije standardni pristup.

1. To je korisno jer dijelimo resurse ispitnih stolova.

Već dobro, ali što bi se još moglo ubrzati?

Zahvaljujući takvom sustavu možemo uvelike smanjiti prag za ulazak u takvo testiranje.

Sada postoji začarani krug, kada programer, kako bi dobio pristup pravim podacima u punoj veličini, mora postati stručnjak. Mora mu se povjeriti takav pristup.

Ali kako rasti ako ga nema. Ali što ako vam je dostupan samo vrlo mali skup testnih podataka? Tada nećete imati pravo iskustvo.

Kako izaći iz tog kruga? Kao prvo sučelje, pogodno za programere bilo koje razine, odabrali smo Slack bot. Ali to može biti bilo koje drugo sučelje.

Što vam omogućuje? Možete uzeti određeni upit i poslati ga na poseban kanal za bazu podataka. Automatski ćemo postaviti tanki klon za nekoliko sekundi. Pokrenimo ovaj zahtjev. Prikupljamo metriku i preporuke. Pokažimo vizualizaciju. I onda će ovaj klon ostati da se ovaj upit može nekako optimizirati, dodati indekse itd.

Također, Slack nam daje mogućnosti za suradnju izvan okvira. Budući da je ovo samo kanal, možete početi raspravljati o ovom zahtjevu upravo tamo u temi za takav zahtjev, pingati svoje kolege, DBA koji su unutar tvrtke.

Ali ima, naravno, problema. Budući da je ovo stvarni svijet, a mi koristimo poslužitelj koji ugošćuje mnogo klonova odjednom, moramo komprimirati količinu memorije i CPU snagu dostupnu klonovima.

Ali da bi ovi testovi bili uvjerljivi, morate nekako riješiti ovaj problem.

Jasno je da su važni isti podaci. Ali već ga imamo. I mi želimo postići istu konfiguraciju. I mi možemo dati takvu gotovo identičnu konfiguraciju.

Bilo bi cool imati isti hardver kao u proizvodnji, ali može se razlikovati.

Prisjetimo se kako Postgres radi s memorijom. Imamo dva spremišta. Jedan iz datotečnog sustava i jedan izvorni Postgres, tj. Shared Buffer Cache.

Važno je napomenuti da se Shared Buffer Cache dodjeljuje kada se Postgres pokrene, ovisno o veličini koju navedete u konfiguraciji.

A druga predmemorija koristi sav raspoloživi prostor.

A kada napravimo nekoliko klonova na jednom stroju, ispada da postupno punimo memoriju. I na dobar način, Shared Buffer Cache čini 25% ukupne količine memorije koja je dostupna na stroju.

I ispada da ćemo, ako ne promijenimo ovaj parametar, moći pokrenuti samo 4 instance na jednom stroju, odnosno ukupno 4 ova tanka klona. A to je, naravno, loše, jer želimo da ih bude puno više.

No, s druge strane, Buffer Cache se koristi za izvršavanje upita za indekse, odnosno plan ovisi o tome koliki su nam predmemorije. A ako samo uzmemo ovaj parametar i smanjimo ga, tada se naši planovi mogu puno promijeniti.

Na primjer, ako imamo veliku predmemoriju na prod-u, tada će Postgres radije koristiti indeks. A ako ne, onda će biti SeqScan. A što bi bilo smisla da nam se planovi ne poklapaju?

Ali ovdje dolazimo do zaključka da zapravo plan u Postgresu ne ovisi o specifičnoj veličini navedenoj u dijeljenom međuspremniku u planu, ovisi o efektivnoj_veličini_cache_size.

Effective_cache_size je procijenjena količina predmemorije koja nam je dostupna, tj. zbroj predmemorije međuspremnika i predmemorije sustava datoteka. Ovo je postavljeno konfiguracijom. I ova memorija nije dodijeljena.

I zahvaljujući ovom parametru, možemo na neki način prevariti Postgres, govoreći da zapravo imamo mnogo dostupnih podataka, čak i ako ih nemamo. Dakle, planovi će se u potpunosti poklopiti s proizvodnjom.

Ali to može utjecati na vrijeme. I optimiziramo upite prema vremenu, ali važno je da vrijeme ovisi o mnogim čimbenicima:

• Ovisi o opterećenju koje je trenutno na prod.

• Ovisi o karakteristikama samog stroja.

I ovo je neizravni parametar, ali zapravo možemo optimizirati točno prema količini podataka koje će ovaj upit pročitati da bismo dobili rezultat.

A ako želite da vrijeme bude blizu onoga što ćemo vidjeti u prod-u, onda moramo uzeti najsličniji hardver i, moguće, čak i više, tako da svi klonovi odgovaraju. Ali ovo je kompromis, tj. dobit ćete iste planove, vidjet ćete koliko podataka će određeni upit pročitati i moći ćete zaključiti je li taj upit dobar (ili migracija) ili loš, još ga treba optimizirati .

Pogledajmo kako je Joe konkretno optimiziran.

Uzmimo zahtjev iz stvarnog sustava. U ovom slučaju baza podataka ima 1 terabajt. I želimo prebrojati broj svježih objava koje su imale više od 10 lajkova.

Pišemo poruku kanalu, klon je raspoređen za nas. I vidjet ćemo da će takav zahtjev završiti za 2,5 minute. To je prvo što primjećujemo.

B Joe će vam pokazati automatske preporuke na temelju plana i metrike.

Vidjet ćemo da upit obrađuje previše podataka da bi dobio relativno mali broj redaka. Potrebna je i neka vrsta specijaliziranog indeksa, budući da smo primijetili da postoji previše filtriranih redaka u upitu.

Pogledajmo pobliže što se dogodilo. Doista, vidimo da smo pročitali gotovo jedan i pol gigabajt podataka iz predmemorije datoteka ili čak s diska. A to nije dobro, jer smo dobili samo 142 retka.

I, čini se, ovdje imamo skeniranje indeksa i trebalo je brzo uspjeti, ali budući da smo filtrirali previše redaka (morali smo ih prebrojati), upit je polako funkcionirao.

A to se dogodilo u planu zbog činjenice da se uvjeti u upitu i uvjeti u indeksu djelomično ne podudaraju.

Pokušajmo napraviti indeks preciznijim i vidjeti kako se nakon toga mijenja izvršenje upita.

Izrada indeksa je trajala prilično dugo, ali sada smo provjerili upit i vidjeli da je vrijeme umjesto 2,5 minuta samo 156 milisekundi, što je dovoljno dobro. A mi čitamo samo 6 megabajta podataka.

Sada koristimo skeniranje samo indeksa.

Druga bitna priča je da plan želimo predstaviti na neki razumljiviji način. Implementirali smo vizualizaciju koristeći Flame Graphs.

Ovo je drugačiji zahtjev, intenzivniji. A Flame Graphove gradimo prema dva parametra: to je količina podataka koju je određeni čvor ubrojio u plan i tajming, tj. vrijeme izvršenja čvora.

Ovdje možemo međusobno usporediti određene čvorove. I bit će jasno koji od njih uzima više ili manje, što je obično teško učiniti u drugim metodama renderiranja.

Naravno, svi znaju expand.depesz.com. Dobra značajka ove vizualizacije je što spremamo plan teksta i također stavljamo neke osnovne parametre u tablicu kako bismo mogli sortirati.

I developeri koji se još nisu zadubili u ovu tematiku također koriste expand.depesz.com, jer im je lakše dokučiti koja je metrika bitna, a koja ne.

Postoji novi pristup vizualizaciji - ovo je expand.dalibo.com. Oni rade vizualizaciju stabla, ali je vrlo teško međusobno usporediti čvorove. Ovdje možete dobro razumjeti strukturu, međutim, ako postoji veliki zahtjev, tada ćete morati skrolati naprijed-natrag, ali i opciju.

suradnja

I, kao što sam rekao, Slack nam daje priliku za suradnju. Na primjer, ako naiđemo na složeni upit za koji nije jasno kako optimizirati, možemo razjasniti ovo pitanje s našim kolegama u niti u Slacku.

Čini nam se da je važno testirati podatke u punoj veličini. Da bismo to učinili, napravili smo alat Update Database Lab, koji je dostupan u otvorenom kodu. Možete koristiti i Joe bot. Možete ga odmah preuzeti i implementirati kod sebe. Svi vodiči su dostupni tamo.

Također je važno napomenuti da samo rješenje nije revolucionarno, jer postoji Delphix, ali se radi o enterprise rješenju. Potpuno je zatvoren, jako je skup. Posebno smo specijalizirani za Postgres. Sve su to proizvodi otvorenog koda. Pridruži nam se!

Ovdje završavam. Hvala vam!

pitanja

Zdravo! Hvala na izvješću! Vrlo zanimljivo, pogotovo meni, jer sam prije nekog vremena rješavao otprilike isti problem. I zato imam nekoliko pitanja. Nadam se da ću dobiti barem dio toga.

Pitam se kako izračunavate mjesto za ovaj okoliš? Tehnologija znači da pod određenim okolnostima vaši klonovi mogu narasti do maksimalne veličine. Grubo govoreći, ako imate bazu podataka od deset terabajta i 10 klonova, onda je lako simulirati situaciju u kojoj svaki klon teži 10 jedinstvenih podataka. Kako računate ovo mjesto, odnosno tu deltu o kojoj ste govorili, u kojoj će ti klonovi živjeti?

Dobro pitanje. Ovdje je važno pratiti specifične klonove. I ako klon ima neku preveliku promjenu, počne rasti, onda možemo prvo izdati upozorenje korisniku o tome, ili odmah zaustaviti ovaj klon kako ne bismo imali fail situaciju.

Da, imam postavljeno pitanje. Odnosno, kako osigurati životni ciklus ovih modula? Mi imamo taj problem i sasvim zasebnu priču. Kako se to događa?

Postoji neki ttl za svaki klon. Uglavnom, imamo fiksni ttl.

Što, ako nije tajna?

1 sat, tj. mirovanje - 1 sat. Ako se ne koristi, onda ga lupimo. Ali tu nema nikakvog iznenađenja, budući da možemo podići klona za nekoliko sekundi. A ako ti opet zatreba, molim te.

Zanima me i izbor tehnologija jer, primjerice, iz ovih ili onih razloga paralelno koristimo nekoliko metoda. Zašto ZFS? Zašto nisi koristio LVM? Spomenuli ste da je bilo problema s LVM-om. Koji su bili problemi? Po mom mišljenju, najoptimalnija opcija je sa pohranom, u smislu performansi.

Koji je glavni problem sa ZFS-om? Činjenica da morate raditi na istom hostu, tj. sve će instance živjeti unutar istog OS-a. A u slučaju skladištenja, možete spojiti različitu opremu. A usko grlo su samo oni blokovi koji se nalaze na sustavu za pohranu. A zanimljivo je i pitanje izbora tehnologija. Zašto ne LVM?

Konkretno, možemo razgovarati o LVM-u na susretu. O skladištenju - samo je skupo. ZFS sustav možemo implementirati bilo gdje. Možete ga implementirati na svom računalu. Možete jednostavno preuzeti repozitorij i implementirati ga. ZFS je instaliran gotovo svugdje ako govorimo o Linuxu. Odnosno, dobivamo vrlo fleksibilno rješenje. I sam ZFS daje puno out of the box. Možete uploadati koliko god želite podataka, spojiti veliki broj diskova, postoje snimke. I, kao što sam rekao, lako ga je administrirati. Odnosno, čini se vrlo ugodnim za korištenje. Provjeren je, ima mnogo godina. Ima vrlo veliku zajednicu koja raste. ZFS je vrlo pouzdano rješenje.

Nikolaj Samohvalov: Mogu li dalje komentirati? Moje ime je Nikolay, radimo zajedno s Anatolijem. Slažem se da je pohrana odlična. A neki od naših kupaca imaju Pure Storage itd.

Anatolij je ispravno primijetio da smo fokusirani na modularnost. A u budućnosti možete implementirati jedno sučelje - snimite snimku, napravite klon, uništite klon. Sve je lako. A skladištenje je cool, ako jest.

Ali ZFS je dostupan svima. DelPhix je već dovoljan, imaju 300 klijenata. Od toga Fortune 100 ima 50 klijenata, tj. usmjereni su na NASA-u itd. Vrijeme je da svi dobiju ovu tehnologiju. I zato imamo Core otvorenog koda. Imamo dio sučelja koji nije otvorenog koda. Ovo je platforma koju ćemo pokazati. Ali želimo da bude dostupno svima. Želimo napraviti revoluciju da svi testeri prestanu pogađati na laptopima. Moramo napisati SELECT i odmah vidjeti da je spor. Prestanite čekati da vam DBA kaže o tome. Ovdje je glavni cilj. I mislim da ćemo svi doći do ovoga. I izrađujemo ovu stvar za svakoga. Stoga ZFS, jer će biti dostupan svugdje. Hvala zajednici na rješavanju problema i na licenci otvorenog koda itd.*

Lijep pozdrav! Hvala na izvješću! Moje ime je Maxim. Bavili smo se istim problemima. Odlučili su sami. Kako dijelite resurse između ovih klonova? Svaki klon može raditi svoje u bilo kojem trenutku: jedan testira jedno, drugi drugo, netko gradi indeks, netko ima težak posao. I ako još uvijek možete dijeliti prema CPU-u, zatim prema IO-u, kako dijelite? Ovo je prvo pitanje.

A drugo pitanje je o različitosti tribina. Ja recimo ovdje imam ZFS i sve mi je cool, ali klijent na produ nema ZFS, nego ext4 npr. Kako u ovom slučaju?

Pitanja su jako dobra. Malo sam spomenuo taj problem s činjenicom da dijelimo resurse. A rješenje je ovo. Zamislite da testirate na inscenaciji. Isto tako možete imati i takvu situaciju da netko daje jedan teret, netko drugi. I kao rezultat toga, vidite nerazumljive metrike. Čak isti problem može biti i s prod. Kada želite provjeriti neki zahtjev i vidite da postoji neki problem s njim - radi sporo, onda zapravo nije problem bio u zahtjevu, nego u tome što postoji nekakvo paralelno opterećenje.

Stoga je ovdje važno usredotočiti se na to kakav će plan biti, koje korake ćemo poduzeti u planu i koliko ćemo podataka prikupiti za to. Činjenica da će naši diskovi, na primjer, biti napunjeni nečim, to će posebno utjecati na tajming. Ali možemo procijeniti koliko je ovaj zahtjev opterećen prema količini podataka. Nije toliko važno da će u isto vrijeme biti i neka vrsta ovrhe.

Imam dva pitanja. Ovo je jako cool stvar. Je li bilo slučajeva kada su proizvodni podaci kritični, poput brojeva kreditnih kartica? Ima li već nešto spremno ili je to zaseban zadatak? I drugo pitanje - postoji li ovako nešto za MySQL?

O podacima. Zamagljivat ćemo sve dok to ne učinimo. Ali ako implementirate točno Joea, ako ne date pristup programerima, tada nema pristupa podacima. Zašto? Jer Joe ne prikazuje podatke. Prikazuje samo metriku, planove i to je to. To je napravljeno namjerno, jer je to jedan od zahtjeva našeg klijenta. Htjeli su biti u mogućnosti optimizirati bez davanja pristupa svima.

O MySQL-u. Ovaj sustav se može koristiti za sve što pohranjuje stanje na disk. A budući da radimo Postgres, sada prvo radimo svu automatizaciju za Postgres. Želimo automatizirati dobivanje podataka iz sigurnosne kopije. Ispravno konfiguriramo Postgres. Znamo uskladiti planove itd.

Ali budući da je sustav proširiv, može se koristiti i za MySQL. A takvih primjera ima. Yandex ima sličnu stvar, ali to nigdje ne objavljuju. Koriste ga unutar Yandex.Metrice. A tu je samo priča o MySQL-u. Ali tehnologije su iste, ZFS.

Hvala na izvješću! Imam i ja par pitanja. Spomenuli ste da se kloniranje može koristiti za analitiku, na primjer za izgradnju dodatnih indeksa. Možete li reći nešto više o tome kako funkcionira?

I odmah ću postaviti drugo pitanje o sličnosti tribina, sličnosti planova. Plan ovisi i o statistici koju prikuplja Postgres. Kako rješavate ovaj problem?

Prema analitici, nema posebnih slučajeva, jer to još nismo iskoristili, ali postoji takva prilika. Ako govorimo o indeksima, onda zamislite da upit juri za tablicom sa stotinama milijuna zapisa i stupcem koji obično nije indeksiran u prod. I tu želimo izračunati neke podatke. Ako se ovaj zahtjev pošalje na prod, onda postoji mogućnost da će to biti jednostavno na prod-u, jer će se tamo zahtjev obrađivati ​​minutu.

Ok, napravimo tanki klon koji nije strašno zaustaviti se na nekoliko minuta. A kako bi čitanje analitike bilo ugodnije, dodat ćemo indekse za one stupce u kojima nas zanimaju podaci.

Indeks će se kreirati svaki put?

Možete napraviti tako da dotaknemo podatke, napravimo snimke, zatim ćemo se oporaviti od ove snimke i pokrenuti nove zahtjeve. Odnosno, možete napraviti tako da možete uzgajati nove klonove s već pričvršćenim indeksima.

Što se tiče pitanja o statistici, ako vratimo iz sigurnosne kopije, ako napravimo replikaciju, onda će naša statistika biti potpuno ista. Budući da imamo cjelokupnu fizičku strukturu podataka, to jest, dovest ćemo podatke onakvima kakvi jesu sa svim statističkim metrikama.

Evo još jednog problema. Ako koristite cloud rješenje, onda su tamo dostupni samo logički dumpovi, jer Google, Amazon ne dopuštaju da napravite fizičku kopiju. Bit će problema.

Hvala na izvješću. Ovdje su bila dva dobra pitanja o MySQL-u i dijeljenju resursa. Ali, zapravo, sve se svodi na činjenicu da ovo nije tema konkretnog DBMS-a, već datotečnog sustava u cjelini. I, sukladno tome, pitanja dijeljenja resursa bi također trebala biti riješena odatle, ne na kraju što je to Postgres, već u datotečnom sustavu, na poslužitelju, na primjer.

Moje pitanje je malo drugačije. Bliži je višeslojnoj bazi podataka, gdje postoji nekoliko slojeva. Na primjer, postavili smo ažuriranje slike od deset terabajta, repliciramo. Ovo rješenje posebno koristimo za baze podataka. Replikacija je u tijeku, podaci se ažuriraju. Ovdje paralelno radi 100 zaposlenika koji stalno lansiraju te različite snimke. Što uraditi? Kako se uvjeriti da nema sukoba, da su pokrenuli jedan, a onda se promijenio datotečni sustav i sve su ove slike nestale?

Neće ići jer tako radi ZFS. Promjene datotečnog sustava koje dolaze uslijed replikacije možemo odvojeno čuvati u jednoj niti. I zadržite klonove koje programeri koriste na starijim verzijama podataka. I radi nam, s ovim je sve u redu.

Ispada da će se ažuriranje odvijati kao dodatni sloj, a sve nove slike već će ići na temelju ovog sloja, zar ne?

Iz prethodnih slojeva koji su bili iz prethodnih replikacija.

Prethodni slojevi će otpasti, ali će se odnositi na stari sloj i hoće li uzeti nove slike sa zadnjeg sloja koji je primljen u ažuriranju?

Općenito, da.

Tada ćemo kao posljedicu imati do figu slojeva. I s vremenom će ih trebati komprimirati?

Da sve je točno. Postoji neki prozor. Čuvamo tjedne snimke. Ovisi o resursima koje imate. Ako imate mogućnost pohranjivanja puno podataka, snimke možete pohraniti dugo vremena. Neće otići sami od sebe. Neće biti oštećenja podataka. Ako su snimke zastarjele, kako nam se čini, odnosno ovisi o politici u tvrtki, onda ih jednostavno možemo obrisati i osloboditi prostor.

Pozdrav, hvala na izvješću! Pitanje o Joeu. Rekli ste da kupac nije htio svima dati pristup podacima. Strogo govoreći, ako osoba ima rezultat Explain Analyze, onda može proviriti u podatke.

To je tako. Na primjer, možemo napisati: "SELECT FROM WHERE email = to that". Odnosno, nećemo vidjeti same podatke, ali možemo vidjeti neke neizravne znakove. Ovo se mora razumjeti. Ali s druge strane, sve je tu. Imamo log audit, imamo kontrolu ostalih kolega koji također vide što programeri rade. A ako netko to pokuša, onda će zaštitarska služba doći do njih i poraditi na ovom pitanju.

Dobar dan Hvala na izvješću! Imam kratko pitanje. Ako tvrtka ne koristi Slack, postoji li veza za njega sada ili je moguće da programeri implementiraju instance kako bi povezali testnu aplikaciju s bazama podataka?

Sada postoji poveznica na Slack, tj. nema drugog glasnika, ali stvarno želim napraviti podršku i za druge glasnike. Što možeš učiniti? Možete implementirati DB Lab bez Joea, ići uz pomoć REST API-ja ili uz pomoć naše platforme i stvoriti klonove i povezati se s PSQL-om. Ali to se može učiniti ako ste spremni svojim programerima dati pristup podacima, jer više neće biti nikakvog zaslona.

Ne trebam ovaj sloj, ali trebam takvu priliku.

Onda da, može se.

Izvor: www.habr.com