DBA bot Joe. Anatolij Stansler (Postgres.ai)

Kako backend programer razumije da će SQL upit dobro funkcionirati na "produ"? U velikim ili brzo rastućim kompanijama, nemaju svi pristup „proizvodu“. A uz pristup, svi zahtjevi se ne mogu bezbolno provjeriti, a stvaranje kopije baze podataka često traje satima. Da bismo riješili ove probleme, kreirali smo umjetni DBA - Joe. Već je uspješno implementiran u nekoliko kompanija i pomaže više od desetak programera.

Video:

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

Imamo odlične klijente i danas će dio izvještaja biti posvećen slučajevima sa kojima smo se susreli radeći sa njima. Govoriću o tome kako smo im pomogli da reše prilično ozbiljne probleme.

Kada razvijamo i radimo složene migracije visokog opterećenja, postavljamo sebi pitanje: „Hoće li ova migracija krenuti?“. 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 testiramo na kopijama u punoj veličini. A danas ćemo samo govoriti o tome koji su pristupi testiranju sada i kako se to može učiniti bolje i s kojim alatima. Također ćemo govoriti o prednostima i nedostacima takvih pristupa, te o tome šta ovdje možemo popraviti.

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

Prvi pristup je testiranje u prod. Ili, kada programer sjedi na lokalnoj mašini, ima testne podatke, postoji neka vrsta ograničenog izbora. I krenemo da proizvodimo, i dobijemo ovu situaciju.

Boli, skupo je. Verovatno je najbolje da ne.

I koji je najbolji način da se to uradi?

Uzmimo inscenaciju i odaberite neki dio produkcije tamo. Ili u najboljem slučaju, uzmimo pravi proizvod, sve podatke. A nakon što ga razvijemo lokalno, dodatno ćemo provjeriti da li je uprizoreno.

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

koji su problemi?

• Problem je što ovu scenu dijelimo sa kolegama. I vrlo često se desi da napravite neku promjenu, bam - a nema podataka, posao je prazna. Staging je bio višeterabajtni. I morate dugo čekati da ponovo naraste. I mi odlučujemo da to finaliziramo sutra. To je to, imamo razvoj.
• I, naravno, imamo mnogo kolega koji rade tamo, mnogo timova. I to se mora uraditi ručno. A ovo je nezgodno.

I vrijedi reći da imamo samo jedan pokušaj, jedan udarac, 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 vraćati.

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

Šta nas sprečava da svakom programeru damo testnu ploču, kopiju u punoj veličini? Mislim da je jasno šta staje na put.

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

I jasno je da je čuvanje mašina za svakog programera, kada postoji tako velika proizvodnja, veoma skupo, a osim toga, dugo traje.

Imamo klijente koji su shvatili da je jako 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 testne klupe za svakog programera. Stoga, oni moraju lokalno preuzeti dumpove na svoju mašinu i testirati na ovaj način. Potrebno je puno vremena.

Čak i ako to radite unutar infrastrukture, tada je preuzimanje jednog terabajta podataka po satu već vrlo dobro. Ali oni koriste logičke dumpove, preuzimaju lokalno iz oblaka. Za njih je brzina oko 200 gigabajta na sat. I još uvijek treba vremena da se okrenemo od logičkog dump-a, umotamo indekse itd.

Ali oni koriste ovaj pristup jer im omogućava da održe pouzdanost proizvoda.

Šta možemo ovdje? Učinimo testne stolove jeftinim i dajmo svakom programeru svoj vlastiti testni stol.

I ovo je moguće.

I u ovom pristupu, kada napravimo tanke klonove za svakog programera, možemo ga podijeliti na jednoj mašini. Na primjer, ako imate bazu podataka od 10TB i želite je dati 10 programera, ne morate imati XNUMX x XNUMXTB baza podataka. Potrebna vam je samo jedna mašina da napravite tanke izolirane kopije za svakog programera koristeći jednu mašinu. 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 na probni štand i zavisiti od toga koliko je veliko. Možete ga dobiti za nekoliko sekundi. To će biti potpuno izolirana okruženja, ali koja međusobno dijele podatke.

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

U našem slučaju, ovo radi koristeći OpenZFS sistem.

OpenZFS je sistem datoteka za kopiranje na pisanje koji podržava brze snimke i klonove. Pouzdan je i skalabilan. Njom se veoma lako upravlja. Može se bukvalno rasporediti u dva tima.

Postoje i druge opcije:

• lvm,

• Skladištenje (na primjer, Pure Storage).

Laboratorija za baze podataka o kojoj govorim je modularna. Može se implementirati korištenjem ovih opcija. Ali za sada smo se fokusirali na OpenZFS, jer je bilo problema posebno sa LVM-om.

Kako radi? Umjesto da prepisujemo podatke svaki put kada ih promijenimo, mi ih spremamo jednostavnim označavanjem da su ti novi podaci iz nove tačke u vremenu, novi snimak.

A u budućnosti, kada želimo da se vratimo ili želimo da napravimo novi klon od neke starije verzije, samo kažemo: "OK, dajte nam ove blokove podataka koji su ovako označeni."

I ovaj korisnik će raditi s takvim skupom podataka. On će ih postepeno mijenjati, praviti vlastite snimke.

I mi ćemo se granati. Svaki programer u našem slučaju će imati priliku da ima svoj klon koji uređuje, a podaci koji se dijele će se dijeliti između svih.

Da biste postavili takav sistem kod kuće, morate riješiti dva problema:

• Prvi je izvor podataka, odakle ćete ih preuzeti. 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, onda možete koristiti logičke dumpove. Ali ipak vam savjetujemo da koristite sigurnosne kopije, jer ćete ovim pristupom zadržati i fizičku strukturu datoteka, što će vam omogućiti da budete još bliže metrikama koje biste vidjeli u produkciji kako biste uhvatili te probleme koji postoje.

• Drugi je mjesto gdje želite da ugostite Laboratoriju za baze podataka. To može biti Cloud, može biti On-premise. Ovdje je važno reći da ZFS podržava kompresiju podataka. I to radi prilično dobro.

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

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

• Ovo su programeri, DBA za validaciju upita, za optimizaciju.

• Ovo se može koristiti u QA testiranju za testiranje određene migracije prije nego što je uvedemo u prod. Takođe možemo podići posebna okruženja za QA sa stvarnim podacima, gde mogu da testiraju nove funkcionalnosti. I to će trajati nekoliko sekundi umjesto sati čekanja, a možda i dana u nekim drugim slučajevima kada se tanke kopije ne koriste.

• I još jedan slučaj. Ako kompanija nema postavljen sistem analize, onda možemo izolovati tanak klon baze proizvoda i dati ga dugim upitima ili posebnim indeksima koji se mogu koristiti u analitici.

Sa ovim pristupom:

1. Mala vjerovatnoća grešaka na "produ", jer smo sve promjene testirali na podacima u punoj veličini.

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

3. I nema barijere, nema čekanja između testova. Zapravo možete otići i provjeriti. I ovako će biti bolje kako budemo ubrzavali razvoj.

• Biće manje refaktoriranja. Manje grešaka će završiti u produkciji. Kasnije ćemo ih manje refaktorirati.

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

1. Ovo je korisno jer dijelimo resurse testnih stolova.

Već dobro, ali šta se još može ubrzati?

Zahvaljujući ovakvom sistemu možemo uveliko smanjiti prag za ulazak u takvo testiranje.

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

Ali kako rasti ako ga nema. Ali šta ako imate na raspolaganju samo vrlo mali skup test podataka? Tada nećete dobiti nikakvo pravo iskustvo.

Kako izaći iz ovog kruga? Kao prvi interfejs, pogodan za programere bilo kog nivoa, izabrali smo Slack bot. Ali to može biti bilo koji drugi interfejs.

Šta vam to omogućava? 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 metrike i preporuke. Pokažimo vizualizaciju. I onda će ovaj klon ostati tako da se ovaj upit može nekako optimizirati, dodati indeksi itd.

Takođe nam Slack daje prilike za saradnju izvan okvira. Pošto je ovo samo kanal, možete započeti diskusiju o ovom zahtjevu upravo tamo u niti za takav zahtjev, pingujte svoje kolege, DBA-ove koji su unutar kompanije.

Ali postoje, naravno, problemi. Budući da je ovo stvarni svijet, a mi pokrećemo server koji ugošćuje mnogo klonova odjednom, moramo komprimirati količinu memorije i CPU snage dostupne klonovima.

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

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

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

Prisjetimo se kako Postgres radi sa memorijom. Imamo dva keša. Jedan iz sistema datoteka i jedan izvorni Postgres, tj. Shared Buffer Cache.

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

A druga keš memorija koristi sav raspoloživi prostor.

A kada napravimo nekoliko klonova na jednoj mašini, ispada da postepeno popunjavamo memoriju. I na dobar način, Shared Buffer Cache je 25% ukupne količine memorije koja je dostupna na mašini.

I ispada da ako ne promijenimo ovaj parametar, onda ćemo moći pokrenuti samo 4 instance na jednoj mašini, odnosno ukupno 4 ova tanka klona. A to je, naravno, loše, jer želimo da ih imamo mnogo više.

Ali s druge strane, Buffer Cache se koristi za izvršavanje upita za indekse, odnosno plan ovisi o tome koliko su naši kešovi veliki. A ako samo uzmemo ovaj parametar i smanjimo ga, onda se naši planovi mogu mnogo promijeniti.

Na primjer, ako imamo veliku keš memoriju na prod, onda će Postgres radije koristiti indeks. A ako ne, onda će postojati SeqScan. I koja bi bila svrha da nam se planovi ne poklope?

Ali ovdje dolazimo do zaključka da u stvari plan u Postgresu ne ovisi o specifičnoj veličini navedenoj u Shared Bufferu u planu, već o efektivnoj_cache_size.

Effective_cache_size je procijenjena količina keš memorije koja nam je dostupna, tj. zbir keša bafera i keša sistema datoteka. Ovo je postavljeno konfiguracijom. I ova memorija nije dodijeljena.

A zbog ovog parametra možemo nekako prevariti Postgres, govoreći da zapravo imamo puno dostupnih podataka, čak i ako ih nemamo. I tako će se planovi u potpunosti poklopiti sa proizvodnjom.

Ali to može uticati na tajming. I mi optimiziramo upite prema vremenu, ali je važno da tajming ovisi o mnogim faktorima:

• Zavisi od opterećenja koje je trenutno na prod.

• Zavisi od karakteristika same mašine.

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

A ako želite da tajming bude blizak onome što ćemo vidjeti u produkciji, onda trebamo uzeti najsličniji hardver i, moguće, čak i više 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 da li je ovaj upit dobar (ili migracija) ili loš, još ga treba optimizirati .

Pogledajmo kako je Joe posebno optimiziran.

Uzmimo zahtjev iz stvarnog sistema. U ovom slučaju, baza podataka je 1 terabajt. I želimo da izbrojimo broj svježih objava koje su imale više od 10 lajkova.

Pišemo poruku kanalu, klon nam je raspoređen. I vidjet ćemo da će se takav zahtjev završiti za 2,5 minuta. Ovo je prva stvar koju primjećujemo.

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

Vidjet ćemo da upit obrađuje previše podataka da bi dobio relativno mali broj redova. I neka vrsta specijalizovanog indeksa je potrebna, pošto smo primetili da ima previše filtriranih redova u upitu.

Pogledajmo bliže šta se dogodilo. Zaista, vidimo da smo pročitali skoro jedan i po gigabajta podataka iz keša datoteka ili čak sa diska. A to nije dobro, jer imamo samo 142 reda.

I, čini se, ovdje imamo skeniranje indeksa i trebalo je brzo da prođe, ali pošto smo filtrirali previše redova (morali smo ih prebrojati), zahtjev je polako prošao.

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

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

Kreiranje indeksa je trajalo dosta vremena, ali sada provjeravamo upit i vidimo da je vrijeme umjesto 2,5 minuta samo 156 milisekundi, što je dovoljno dobro. I čitamo samo 6 megabajta podataka.

A sada koristimo samo indeksno skeniranje.

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

Ovo je drugačiji zahtjev, intenzivniji. I gradimo Flame Graphove prema dva parametra: ovo je količina podataka koju je određeni čvor brojio u planu i vremenu, tj. vrijeme izvršenja čvora.

Ovdje možemo međusobno upoređivati ​​određene čvorove. I biće jasno kome od njih treba više ili manje, što je obično teško izvesti u drugim metodama renderovanja.

Naravno, svi znaju objasni.depesz.com. Dobra karakteristika ove vizualizacije je da spremamo tekstualni plan i takođe stavljamo neke osnovne parametre u tabelu kako bismo mogli da sortiramo.

A programeri koji se još nisu udubili u ovu temu također koriste objasni.depesz.com, jer im je lakše shvatiti koje su metrike važne, a koje nisu.

Postoji novi pristup vizualizaciji - to je objasniti.dalibo.com. Oni rade vizualizaciju stabla, ali je vrlo teško upoređivati ​​čvorove jedni s drugima. Ovdje možete dobro razumjeti strukturu, međutim, ako postoji veliki zahtjev, onda ćete morati skrolovati naprijed-nazad, ali i opciju.

saradnja

I, kao što sam rekao, Slack nam daje priliku da sarađujemo. Na primjer, ako naiđemo na složen upit za koji nije jasno kako ga optimizirati, možemo razjasniti ovaj problem sa našim kolegama u niti u Slack-u.

Čini nam se da je važno testirati na podacima u punoj veličini. Da bismo to učinili, napravili smo alat za ažuriranje baze podataka Lab, koji je dostupan u otvorenom kodu. Možete koristiti i Joe bota. Možete ga odmah uzeti 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 je rješenje za preduzeća. Potpuno je zatvoren, veoma je skup. Posebno smo specijalizovani za Postgres. Sve su to proizvodi otvorenog koda. Pridruži nam se!

Ovdje završavam. Hvala ti!

Vaša pitanja

Zdravo! Hvala na izvještaju! Vrlo zanimljivo, posebno meni, jer sam prije nekog vremena riješio otprilike isti problem. I tako imam niz pitanja. Nadam se da ću dobiti barem dio toga.

Pitam se kako izračunavate mjesto za ovu sredinu? 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 izračunate ovo mjesto, odnosno onu deltu o kojoj ste govorili, u kojoj će ovi klonovi živjeti?

Dobro pitanje. Ovdje je važno pratiti određene klonove. A ako klon ima neku preveliku promjenu, počne rasti, onda možemo prvo upozoriti korisnika o tome, ili odmah zaustaviti ovaj klon da ne dođe do kvara.

Da, imam jedno pitanje. Odnosno, kako osiguravate životni ciklus ovih modula? Imamo ovaj problem i jednu posebnu priču. Kako se to događa?

Postoji neki ttl za svaki klon. U osnovi, imamo fiksni ttl.

Šta ako nije tajna?

1 sat, tj. mirovanje - 1 sat. Ako se ne koristi, onda ga lupamo. Ali tu nema iznenađenja, jer možemo podići klon za nekoliko sekundi. A ako vam ponovo zatreba, molim vas.

Zanima me i izbor tehnologija, jer, na primjer, iz ovih ili onih razloga koristimo nekoliko metoda paralelno. Zašto ZFS? Zašto niste koristili LVM? Spomenuli ste da je bilo problema sa LVM-om. Šta su bili problemi? Po mom mišljenju, najoptimalnija opcija je sa skladištem, u smislu performansi.

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

Konkretno, o LVM-u možemo razgovarati na sastanku. Što se tiče skladištenja - jednostavno je skupo. ZFS sistem možemo implementirati bilo gdje. Možete ga postaviti na svoju mašinu. Možete jednostavno preuzeti spremište i implementirati ga. ZFS je instaliran skoro svuda ako govorimo o Linuxu. Odnosno, dobijamo veoma fleksibilno rešenje. I sam ZFS daje mnogo izvan okvira. Možete uploadati koliko god želite podataka, povezati veliki broj diskova, postoje snimci. I, kao što sam rekao, lako se upravlja. To jest, čini se vrlo ugodnim za korištenje. Testiran je, ima mnogo godina. On ima veoma veliku zajednicu koja raste. ZFS je vrlo pouzdano rješenje.

Nikolaj Samokhvalov: Mogu li dalje komentarisati? Moje ime je Nikolay, radimo zajedno sa Anatolijem. Slažem se da je skladištenje odlično. A neki od naših kupaca imaju Pure Storage itd.

Anatolij je tačno primetio da smo fokusirani na modularnost. I u budućnosti možete implementirati jedan interfejs - napraviti snimak, napraviti klon, uništiti klon. Sve je lako. A skladište je cool, ako jeste.

Ali ZFS je dostupan svima. DelPhix-a je već dovoljno, imaju 300 klijenata. Od toga, Fortune 100 ima 50 klijenata, tj. usmjereni su na NASA-u itd. Vrijeme je da svi nabave ovu tehnologiju. I zato imamo otvoreno jezgro. Imamo dio interfejsa koji nije otvorenog koda. Ovo je platforma koju ćemo pokazati. Ali želimo da bude dostupno svima. Želimo da napravimo revoluciju kako bi svi testeri prestali da pogađaju na laptopovima. 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 pravimo ovu stvar za svakoga. Stoga ZFS, jer će biti dostupan svuda. Hvala zajednici na rješavanju problema i licenci otvorenog koda, itd.*

Pozdrav! Hvala na izvještaju! Moje ime je Maxim. Bavili smo se istim pitanjima. Odlučili su sami. Kako dijelite resurse između ovih klonova? Svaki klon može da radi svoje stvari u bilo kom trenutku: jedan testira jedno, drugi drugo, neko pravi indeks, neko ima težak posao. I ako još uvijek možete podijeliti po CPU-u, zatim po IO-u, kako dijelite? Ovo je prvo pitanje.

A drugo pitanje se odnosi na različitost tribina. Recimo da imam ZFS ovdje i sve je cool, ali klijent na prod nema ZFS, već ext4, na primjer. Kako u ovom slučaju?

Pitanja su veoma dobra. Malo sam spomenuo ovaj problem sa činjenicom da dijelimo resurse. A rješenje je ovo. Zamislite da se testirate na inscenaciji. Može se desiti i takva situacija u isto vrijeme da neko daje jedno opterećenje, neko drugi. I kao rezultat, vidite nerazumljive metrike. Čak isti problem može biti i sa prod. Kada želite da proverite neki zahtev i vidite da postoji neki problem sa njim - radi sporo, onda zapravo problem nije bio u zahtevu, već u tome što postoji neka vrsta paralelnog opterećenja.

Stoga je ovdje važno da se fokusiramo na to kakav će biti plan, koje ćemo korake poduzeti u planu i koliko podataka ćemo prikupiti za to. Činjenica da će naši diskovi, na primjer, biti učitani nečim, to će posebno utjecati na tajming. Ali možemo procijeniti koliko je ovaj zahtjev opterećen po količini podataka. Nije toliko važno da će u isto vrijeme doći do neke vrste egzekucije.

Imam dva pitanja. Ovo je jako cool stvar. Da li je bilo slučajeva da su podaci o proizvodnji kritični, kao što su brojevi kreditnih kartica? Da li je već nešto spremno ili je to poseban zadatak? I drugo pitanje - postoji li ovako nešto za MySQL?

O podacima. Radićemo zamagljivanje dok to ne učinimo. Ali ako implementirate upravo Joe, ako ne date pristup programerima, onda nema pristupa podacima. Zašto? Jer Joe ne prikazuje podatke. Prikazuje samo metriku, planove i to je to. To je urađeno namjerno, jer je to jedan od zahtjeva našeg klijenta. Željeli su da mogu optimizirati bez davanja pristupa svima.

O MySQL-u. Ovaj sistem se može koristiti za sve što pohranjuje stanje na disku. A pošto radimo Postgres, sada prvo radimo svu automatizaciju za Postgres. Želimo automatizirati dobivanje podataka iz sigurnosne kopije. Postgres konfigurišemo ispravno. Znamo kako uskladiti planove itd.

Ali pošto je sistem 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 postoji samo priča o MySQL-u. Ali tehnologije su iste, ZFS.

Hvala na izvještaju! Imam i par pitanja. Spomenuli ste da se kloniranje može koristiti za analitiku, na primjer za izgradnju dodatnih indeksa tamo. 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 takođe zavisi od statistike koju prikuplja Postgres. Kako rješavate ovaj problem?

Prema analitici, konkretnih slučajeva nema, jer to još nismo iskoristili, ali takva prilika postoji. Ako govorimo o indeksima, onda zamislite da upit juri tabelu sa stotinama miliona zapisa i kolonu koja se obično ne indeksira u prod. I želimo da izračunamo neke podatke tamo. Ako se ovaj zahtjev pošalje na prod, onda postoji mogućnost da će on biti jednostavan na prod-u, jer će zahtjev tamo biti obrađen minut.

Ok, napravimo tanak klon kojeg nije strašno zaustaviti na nekoliko minuta. A kako bismo olakšali čitanje analitike, dodaćemo indekse za one kolone u kojima nas podaci zanimaju.

Indeks će biti kreiran svaki put?

Možete napraviti tako da dodirnemo podatke, napravimo snimke, a zatim ćemo se oporaviti od ovog snimka i pokrenuti nove zahtjeve. Odnosno, možete napraviti tako da možete podizati nove klonove sa već pričvršćenim indeksima.

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

Evo još jednog problema. Ako koristite cloud rješenje, tada su tamo dostupni samo logički dumpi, jer Google, Amazon ne dozvoljavaju da uzmete fizičku kopiju. Biće problema.

Hvala na izvještaju. Ovdje su bila dva dobra pitanja o MySQL-u i dijeljenju resursa. Ali, zapravo, sve se svodi na to da to nije tema konkretnog DBMS-a, već datotečnog sistema u cjelini. I, shodno tome, odatle treba rešavati i pitanja deljenja resursa, ne na kraju da je to Postgres, već u sistemu datoteka, na serveru, na primer.

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. I mi posebno koristimo ovo rješenje za baze podataka. Replikacija je u toku, podaci se ažuriraju. Ovdje paralelno radi 100 zaposlenika koji neprestano lansiraju ove različite snimke. sta da radim? Kako se uvjeriti da nema sukoba, da su pokrenuli jedan, a onda se promijenio sistem datoteka i sve ove slike su otišle?

Neće ići jer tako funkcioniše ZFS. Možemo odvojeno držati u jednoj niti promjene sistema datoteka koje dolaze zbog replikacije. I zadržite klonove koje programeri koriste na starijim verzijama podataka. I to nam radi, sa ovim je sve u redu.

Ispostavilo se da će se ažuriranje odvijati kao dodatni sloj, a sve nove slike će ići već, na osnovu 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 posljednjeg sloja koji je primljen u ažuriranju?

Generalno, da.

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

Da, sve je tačno. Ima neki prozor. Čuvamo sedmične snimke. Zavisi kojim resursom raspolažete. Ako imate mogućnost pohranjivanja puno podataka, snimke možete pohraniti dugo vremena. Oni neće otići sami. Neće biti oštećenja podataka. Ako su snimci zastarjeli, kako nam se čini, odnosno zavisi od politike u kompaniji, onda ih jednostavno možemo izbrisati i osloboditi prostor.

Zdravo, hvala na izvještaju! Pitanje o Joeu. Rekli ste da korisnik nije želio svima dati pristup podacima. Strogo govoreći, ako osoba ima rezultat Explain Analyze, onda može zaviriti u podatke.

Tako je. Na primjer, možemo napisati: "SELECT FROM WHERE email = to that". Odnosno, nećemo vidjeti same podatke, ali možemo vidjeti neke indirektne znakove. Ovo se mora razumjeti. Ali s druge strane, sve je tu. Imamo reviziju dnevnika, imamo kontrolu nad drugim kolegama koji takođe vide šta programeri rade. A ako neko to pokuša, onda će mu doći služba sigurnosti i poraditi na ovom pitanju.

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

Sada postoji veza sa Slackom, tj. ne postoji drugi messenger, ali zaista želim da napravim podršku i za druge glasnike. Šta 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 kreirati klonove i povezati se sa PSQL-om. Ali to se može učiniti ako ste spremni da svojim programerima date pristup podacima, jer više neće biti ekrana.

Ne treba mi ovaj sloj, ali mi treba takva prilika.

Onda da, to se može uraditi.

izvor: www.habr.com