DBA bot Joe. Anatolij Stansler (Postgres.ai)

Kako zaledni razvijalec razume, da bo poizvedba SQL dobro delovala na "prod"? V velikih ali hitro rastočih podjetjih nimajo vsi dostopa do »izdelka«. In z dostopom vseh zahtev ni mogoče neboleče preveriti, ustvarjanje kopije baze podatkov pa pogosto traja ure. Za rešitev teh težav smo ustvarili umetnega DBA - Joe. Uspešno je bil implementiran že v več podjetjih in pomaga več kot ducatu razvijalcev.

Video:

Pozdravljeni vsi skupaj! Moje ime je Anatolij Stansler. Delam za podjetje postgres.ai. Zavezani smo k pospešitvi razvojnega procesa z odstranjevanjem zamud, povezanih z delom Postgresa pri razvijalcih, DBA in QA.

Imamo odlične stranke in danes bo del poročila namenjen primerom, s katerimi smo se srečali pri delu z njimi. Govoril bom o tem, kako smo jim pomagali rešiti precej resne težave.

Ko razvijamo in izvajamo kompleksne visokoobremenjene migracije, si zastavljamo vprašanje: "Ali bo ta migracija uspela?". Uporabljamo pregled, uporabljamo znanje izkušenejših sodelavcev, DBA strokovnjakov. In lahko povedo, ali bo letel ali ne.

Morda pa bi bilo bolje, če bi ga sami preizkusili na kopijah polne velikosti. In danes bomo govorili le o tem, kakšni so zdaj pristopi k testiranju in kako ga je mogoče narediti boljše ter s kakšnimi orodji. Govorili bomo tudi o prednostih in slabostih takih pristopov ter kaj lahko tu popravimo.

Kdo je že naredil indekse neposredno na produktu ali kaj spremenil? Kar malo. In za koga je to privedlo do izgube podatkov ali do izpadov? Potem poznaš to bolečino. Hvala bogu, da obstajajo rezervne kopije.

Prvi pristop je testiranje v izdelku. Ali pa, ko razvijalec sedi na lokalnem računalniku, ima testne podatke, obstaja nekakšna omejena izbira. In začnemo proizvajati in dobimo to situacijo.

Boli, drago je. Verjetno je najbolje, da ne.

In kakšen je najboljši način za to?

Vzemimo uprizoritev in tam izberimo del produkcije. Ali pa v najboljšem primeru vzemimo pravi izdelek, vse podatke. In potem, ko ga bomo razvili lokalno, bomo dodatno preverili uprizarjanje.

To nam bo omogočilo, da odstranimo nekatere napake, tj. preprečimo, da bi bile na prod.

Kakšne so težave?

• Problem je, da si to uprizoritev delimo s kolegi. In zelo pogosto se zgodi, da narediš kakšno spremembo, bam - in ni podatkov, delo je v vodo. Uprizoritev je bila večterabajtna. In dolgo je treba čakati, da spet vzhaja. In odločili smo se, da bomo jutri dokončali. To je to, imamo razvoj.
• In seveda imamo veliko kolegov, ki delajo tam, veliko ekip. In to je treba storiti ročno. In to je neprijetno.

In treba je povedati, da imamo samo en poskus, en strel, če želimo narediti nekaj sprememb v bazi podatkov, se dotakniti podatkov, spremeniti strukturo. In če je šlo kaj narobe, če je prišlo do napake pri selitvi, se ne bomo hitro vrnili nazaj.

To je boljše od prejšnjega pristopa, vendar je še vedno velika verjetnost, da bo kakšna napaka šla v proizvodnjo.

Kaj nam preprečuje, da bi vsakemu razvijalcu dali preskusno napravo, kopijo v polni velikosti? Mislim, da je jasno, kaj vas ovira.

Kdo ima bazo podatkov, večjo od terabajta? Več kot polovica sobe.

In jasno je, da je vzdrževanje strojev za vsakega razvijalca, ko je tako velika proizvodnja, zelo drago, poleg tega pa traja veliko časa.

Imamo stranke, ki so ugotovile, da je zelo pomembno preizkusiti vse spremembe na kopijah v polni velikosti, vendar je njihova baza podatkov manjša od terabajta in ni sredstev za vzdrževanje preskusne naprave za vsakega razvijalca. Zato morajo odlagališča prenesti lokalno na svoj stroj in testirati na ta način. Potrebuje veliko časa.

Tudi če to počnete znotraj infrastrukture, je prenos enega terabajta podatkov na uro že zelo dober. Uporabljajo pa logične odlagališča, prenašajo lokalno iz oblaka. Pri njih je hitrost približno 200 gigabajtov na uro. In še vedno je potreben čas, da se obrnete z logičnega odlagališča, zvijete indekse itd.

Toda ta pristop uporabljajo, ker jim omogoča, da ohranjajo izdelek zanesljiv.

Kaj lahko naredimo tukaj? Naredimo testne mize poceni in dajmo vsakemu razvijalcu lastno testno mizo.

In to je možno.

In pri tem pristopu, ko naredimo tanke klone za vsakega razvijalca, jih lahko delimo na enem računalniku. Na primer, če imate bazo podatkov 10TB in jo želite dati 10 razvijalcem, vam ni treba imeti baz podatkov XNUMX x XNUMXTB. Za izdelavo tankih izoliranih kopij za vsakega razvijalca z uporabo enega stroja potrebujete samo en stroj. Malo kasneje vam bom povedal, kako deluje.

Pravi primer:

• DB - 4,5 terabajtov.

• Neodvisne izvode lahko dobimo v 30 sekundah.

Ni vam treba čakati na testno stojalo in biti odvisen od tega, kako velik je. Lahko ga dobite v nekaj sekundah. Šlo bo za popolnoma izolirana okolja, ki pa bodo med seboj delila podatke.

To je odlično. Tu govorimo o magiji in vzporednem vesolju.

V našem primeru to deluje s sistemom OpenZFS.

OpenZFS je datotečni sistem za kopiranje ob pisanju, ki podpira posnetke in klone takoj po namestitvi. Je zanesljiv in razširljiv. Je zelo enostavna za upravljanje. Lahko se dobesedno razporedi v dve ekipi.

Obstajajo še druge možnosti:

• lvm,

• Shramba (na primer Pure Storage).

Database Lab, o katerem govorim, je modularen. Lahko se izvede s temi možnostmi. Toda za zdaj smo se osredotočili na OpenZFS, ker so bile težave posebej z LVM.

Kako deluje? Namesto da bi podatke prepisali vsakič, ko jih spremenimo, jih shranimo tako, da preprosto označimo, da so ti novi podatki iz nove časovne točke, novega posnetka.

In v prihodnosti, ko se želimo vrniti ali želimo narediti nov klon iz neke starejše različice, samo rečemo: "OK, daj nam te bloke podatkov, ki so označeni takole."

In ta uporabnik bo delal s takšnim naborom podatkov. Postopoma jih bo spreminjal, naredil svoje posnetke.

In vejali bomo. Vsak razvijalec v našem primeru bo imel možnost imeti svoj klon, ki ga bo urejal, podatki, ki bodo deljeni, pa bodo deljeni med vsemi.

Za namestitev takega sistema doma morate rešiti dve težavi:

• Prvi je vir podatkov, od koder jih boste vzeli. Podvajanje lahko nastavite s proizvodnjo. Upam, da že lahko uporabljate varnostne kopije, ki ste jih konfigurirali. WAL-E, WAL-G ali Barman. Tudi če uporabljate nekakšno rešitev v oblaku, kot je RDS ali Cloud SQL, lahko uporabite logične odlagališča. Vendar vam vseeno svetujemo, da uporabljate varnostne kopije, saj boste s tem pristopom ohranili tudi fizično strukturo datotek, kar vam bo omogočilo, da ste še bližje meritvam, ki bi jih videli v produkciji, da bi ujeli tiste težave, ki obstajajo.

• Drugo je mesto, kjer želite gostiti Database Lab. Lahko je Cloud, lahko je On-premise. Tukaj je pomembno povedati, da ZFS podpira stiskanje podatkov. In to počne zelo dobro.

Predstavljajte si, da bo za vsakega takega klona, ​​odvisno od operacij, ki jih izvajamo z bazo, zrasel nekakšen razvijalec. Za to bo dev potreboval tudi prostor. Toda glede na to, da smo vzeli osnovo 4,5 terabajtov, jo bo ZFS stisnil na 3,5 terabajtov. To se lahko razlikuje glede na nastavitve. In še vedno imamo prostor za razvijalce.

Tak sistem se lahko uporablja za različne primere.

• To so razvijalci, DBA za validacijo poizvedb, za optimizacijo.

• To lahko uporabimo pri testiranju zagotavljanja kakovosti, da preizkusimo določeno migracijo, preden jo uvedemo v izdelku. Prav tako lahko vzpostavimo posebna okolja za QA z resničnimi podatki, kjer lahko testirajo nove funkcionalnosti. Namesto ur čakanja bo trajalo nekaj sekund, v nekaterih drugih primerih, ko se tanke kopije ne uporabljajo, pa morda tudi dnevi.

• In še en primer. Če podjetje nima vzpostavljenega analitičnega sistema, potem lahko izoliramo tanek klon produktne baze in ga damo dolgim ​​poizvedbam ali posebnim indeksom, ki se lahko uporabljajo v analitiki.

S tem pristopom:

1. Majhna verjetnost napak na "produ", saj smo vse spremembe testirali na podatkih v polni velikosti.

2. Imamo kulturo testiranja, saj vam sedaj ni treba več ur čakati na lastno stojalo.

3. In ni ovir, ni čakanja med testi. Pravzaprav lahko greš in preveriš. In tako bo bolje, saj bomo pospešili razvoj.

• Manj bo refaktoriranja. Manj hroščev bo končalo v izdelku. Kasneje jih bomo manj predelali.

• Lahko obrnemo nepopravljive spremembe. To ni standardni pristop.

1. To je koristno, ker si delimo vire preskusnih miz.

Že dobro, a kaj bi še lahko pospešili?

Zahvaljujoč takšnemu sistemu lahko močno znižamo prag za vstop v takšno testiranje.

Zdaj obstaja začaran krog, ko mora razvijalec, da bi dobil dostop do resničnih podatkov v polni velikosti, postati strokovnjak. Tak dostop mu je treba zaupati.

Toda kako rasti, če ga ni. Kaj pa, če imate na voljo le zelo majhen nabor testnih podatkov? Potem ne boš dobil prave izkušnje.

Kako priti iz tega kroga? Kot prvi vmesnik, primeren za razvijalce vseh stopenj, smo izbrali bota Slack. Lahko pa je katerikoli drug vmesnik.

Kaj vam omogoča? Lahko vzamete določeno poizvedbo in jo pošljete na poseben kanal za bazo podatkov. V nekaj sekundah bomo samodejno namestili tanek klon. Zaženimo to zahtevo. Zbiramo meritve in priporočila. Pokažimo vizualizacijo. In potem bo ta klon ostal, da bo mogoče to poizvedbo nekako optimizirati, dodati indekse itd.

In tudi Slack nam ponuja priložnosti za sodelovanje takoj po začetku. Ker je to le kanal, lahko začnete razpravljati o tej zahtevi kar tam v niti za takšno zahtevo, opravite ping svojim kolegom, upraviteljem baze podatkov, ki so znotraj podjetja.

So pa seveda težave. Ker je to resnični svet in uporabljamo strežnik, ki gosti veliko klonov hkrati, moramo stisniti količino pomnilnika in moči procesorja, ki je na voljo klonom.

Toda da bi bili ti testi verjetni, morate nekako rešiti ta problem.

Jasno je, da so pomembni isti podatki. Ampak ga že imamo. In želimo doseči enako konfiguracijo. In lahko damo tako skoraj enako konfiguracijo.

Super bi bilo imeti isto strojno opremo kot v proizvodnji, vendar se lahko razlikuje.

Spomnimo se, kako Postgres deluje s pomnilnikom. Imamo dva zaklada. Ena iz datotečnega sistema in ena izvorni Postgres, tj. Shared Buffer Cache.

Pomembno je upoštevati, da se predpomnilnik v skupni rabi dodeli ob zagonu Postgresa, odvisno od velikosti, ki jo določite v konfiguraciji.

In drugi predpomnilnik uporablja ves razpoložljivi prostor.

In ko naredimo več klonov na enem stroju, se izkaže, da postopoma polnimo pomnilnik. In v dobrem smislu, predpomnilnik v skupni rabi predstavlja 25 % celotne količine pomnilnika, ki je na voljo na napravi.

In izkazalo se je, da če tega parametra ne spremenimo, bomo lahko na enem stroju izvajali le 4 primerke, torej 4 od vseh takih tankih klonov. In to je seveda slabo, saj si jih želimo imeti veliko več.

Toda po drugi strani se Buffer Cache uporablja za izvajanje poizvedb za indekse, to pomeni, da je načrt odvisen od tega, kako veliki so naši predpomnilniki. In če samo vzamemo ta parameter in ga zmanjšamo, se lahko naši načrti zelo spremenijo.

Na primer, če imamo na prod velik predpomnilnik, bo Postgres raje uporabil indeks. In če ne, potem bo SeqScan. In kakšen bi bil smisel, če se najini načrti ne bi ujemali?

Toda tu pridemo do zaključka, da načrt v Postgresu dejansko ni odvisen od specifične velikosti, določene v skupnem medpomnilniku v načrtu, odvisen je od efektivne_cache_size.

Effective_cache_size je ocenjena količina predpomnilnika, ki nam je na voljo, tj. vsota medpomnilnika in predpomnilnika datotečnega sistema. To je nastavljeno s konfiguracijo. In ta pomnilnik ni dodeljen.

In zaradi tega parametra lahko nekako pretentamo Postgres, češ da imamo dejansko na voljo veliko podatkov, tudi če teh podatkov nimamo. In tako bodo načrti popolnoma sovpadali s proizvodnjo.

Toda to lahko vpliva na čas. Poizvedbe optimiziramo glede na čas, vendar je pomembno, da je čas odvisen od številnih dejavnikov:

• Odvisno od obremenitve, ki je trenutno na prod.

• Odvisno je od lastnosti samega stroja.

In to je posredni parameter, a dejansko lahko optimiziramo natančno glede na količino podatkov, ki jih bo ta poizvedba prebrala, da bi dobili rezultat.

In če želite, da je čas blizu tistemu, kar bomo videli v izdelavi, potem moramo vzeti najbolj podobno strojno opremo in po možnosti še več, da bodo vsi kloni ustrezali. Ampak to je kompromis, tj. dobili boste enake načrte, videli boste, koliko podatkov bo prebrala določena poizvedba in lahko sklepali, ali je ta poizvedba dobra (ali migracija) ali slaba, treba jo je še optimizirati .

Oglejmo si, kako je Joe posebej optimiziran.

Vzemimo zahtevo iz realnega sistema. V tem primeru je baza podatkov 1 terabajt. In želimo prešteti število svežih objav, ki so imele več kot 10 všečkov.

Pišemo sporočilo kanalu, za nas je bil nameščen klon. In videli bomo, da bo taka zahteva dokončana v 2,5 minutah. To je prva stvar, ki jo opazimo.

B Joe vam bo prikazal samodejna priporočila na podlagi načrta in meritev.

Videli bomo, da poizvedba obdela preveč podatkov, da bi dobila relativno majhno število vrstic. Potreben je tudi nekakšen specializiran indeks, saj smo opazili, da je v poizvedbi preveč filtriranih vrstic.

Poglejmo si pobližje, kaj se je zgodilo. Dejansko vidimo, da smo prebrali skoraj gigabajt in pol podatkov iz predpomnilnika datotek ali celo z diska. In to ni dobro, saj smo dobili samo 142 vrstic.

Zdi se, da imamo tukaj skeniranje indeksa in bi moralo delovati hitro, toda ker smo izločili preveč vrstic (morali smo jih prešteti), je zahteva počasi uspela.

In to se je zgodilo v načrtu zaradi dejstva, da se pogoji v poizvedbi in pogoji v indeksu delno ne ujemajo.

Poskusimo narediti indeks bolj natančen in poglejmo, kako se po tem spremeni izvedba poizvedbe.

Ustvarjanje indeksa je trajalo precej dolgo, zdaj pa preverimo poizvedbo in vidimo, da je čas namesto 2,5 minute le 156 milisekund, kar je dovolj dobro. In preberemo samo 6 megabajtov podatkov.

In zdaj uporabljamo samo skeniranje indeksa.

Druga pomembna zgodba je, da želimo načrt predstaviti na nek bolj razumljiv način. Izvedli smo vizualizacijo s pomočjo Flame Graphs.

To je drugačna zahteva, bolj intenzivna. Grafe Flame gradimo glede na dva parametra: to je količina podatkov, ki jih je določeno vozlišče štelo v načrtu, in časovni razpored, tj. čas izvajanja vozlišča.

Tukaj lahko primerjamo posamezna vozlišča med seboj. In jasno bo, kateri od njih potrebuje več ali manj, kar je običajno težko storiti pri drugih načinih upodabljanja.

Seveda vsi poznajo expand.depesz.com. Dobra lastnost te vizualizacije je, da shranimo načrt besedila in damo nekaj osnovnih parametrov v tabelo, da lahko razvrstimo.

In razvijalci, ki se še niso poglobili v to tematiko, uporabljajo tudi expand.depesz.com, saj tako lažje ugotovijo, katere metrike so pomembne in katere ne.

Obstaja nov pristop k vizualizaciji - to je expand.dalibo.com. Naredijo vizualizacijo drevesa, vendar je zelo težko primerjati vozlišča med seboj. Tukaj lahko dobro razumete strukturo, če pa obstaja velika zahteva, se boste morali pomikati naprej in nazaj, pa tudi možnost.

sodelovanje

In kot sem rekel, Slack nam daje priložnost za sodelovanje. Če na primer naletimo na zapleteno poizvedbo, pri kateri ni jasno, kako optimizirati, lahko to težavo razjasnimo s svojimi kolegi v niti v Slacku.

Zdi se nam, da je pomembno testirati podatke v polni velikosti. Za to smo naredili orodje Update Database Lab, ki je na voljo v odprti kodi. Uporabite lahko tudi bota Joe. Lahko ga vzamete takoj in ga implementirate pri vas. Tam so na voljo vsi vodniki.

Pomembno je tudi omeniti, da rešitev sama po sebi ni revolucionarna, saj obstaja Delphix, ampak gre za poslovno rešitev. Je popolnoma zaprt, zelo drag. Posebej smo specializirani za Postgres. Vse to so odprtokodni izdelki. Pridruži se nam!

Tukaj končujem. Hvala vam!

vprašanja

Zdravo! Hvala za poročilo! Zelo zanimivo, sploh zame, ker sem pred časom reševal približno isto težavo. In zato imam številna vprašanja. Upam, da bom dobil vsaj del.

Zanima me, kako izračunate mesto za to okolje? Tehnologija pomeni, da lahko pod določenimi pogoji vaši kloni zrastejo do največje velikosti. Grobo povedano, če imate deset terabajtno bazo podatkov in 10 klonov, je enostavno simulirati situacijo, kjer vsak klon tehta 10 edinstvenih podatkov. Kako izračunate ta kraj, torej tisto delto, o kateri ste govorili, v kateri bodo živeli ti kloni?

Dobro vprašanje. Tukaj je pomembno slediti specifičnim klonom. In če ima klon kakšno preveliko spremembo, začne rasti, potem lahko uporabnika najprej opozorimo na to ali pa takoj zaustavimo ta klon, da ne pride do fail situacije.

Da, imam ugnezdeno vprašanje. Se pravi, kako zagotovite življenjski cikel teh modulov? Imamo ta problem in čisto ločeno zgodbo. Kako se to zgodi?

Za vsak klon je nekaj ttl. V bistvu imamo fiksen ttl.

Kaj, če ni skrivnost?

1 ura, tj. mirovanje - 1 ura. Če se ne uporablja, potem ga udarimo. A tu ni presenečenja, saj lahko klon dvignemo v nekaj sekundah. In če ga ponovno potrebujete, prosim.

Zanima me tudi izbira tehnologij, saj na primer iz takšnih ali drugačnih razlogov uporabljamo več metod vzporedno. Zakaj ZFS? Zakaj nisi uporabil LVM? Omenili ste, da so bile težave z LVM. Kakšne so bile težave? Po mojem mnenju je najbolj optimalna možnost s shranjevanjem, glede zmogljivosti.

Kaj je glavna težava ZFS? Dejstvo, da morate delovati na istem gostitelju, kar pomeni, da bodo vsi primerki živeli v istem OS. In v primeru shranjevanja lahko povežete različno opremo. In ozko grlo so samo tisti bloki, ki so v sistemu za shranjevanje. In zanimivo je vprašanje izbire tehnologij. Zakaj ne LVM?

Natančneje, o LVM lahko razpravljamo na srečanju. O shranjevanju - samo drago je. Sistem ZFS lahko implementiramo kjerkoli. Lahko ga namestite na svoj računalnik. Lahko preprosto prenesete repozitorij in ga namestite. ZFS je nameščen skoraj povsod, če govorimo o Linuxu. To pomeni, da dobimo zelo prilagodljivo rešitev. In ZFS sam daje veliko iz škatlice. Naložite lahko poljubno količino podatkov, povežete veliko število diskov, na voljo so posnetki. In kot sem rekel, upravljanje je enostavno. To pomeni, da se zdi zelo prijeten za uporabo. Je preizkušen, star je veliko let. Ima zelo veliko skupnost, ki raste. ZFS je zelo zanesljiva rešitev.

Nikolaj Samohvalov: Lahko še komentiram? Moje ime je Nikolay, delava skupaj z Anatolijem. Strinjam se, da je shranjevanje super. In nekatere naše stranke imajo Pure Storage itd.

Anatolij je pravilno ugotovil, da smo osredotočeni na modularnost. In v prihodnosti lahko implementirate en vmesnik - naredite posnetek, naredite klon, uničite klon. Vse je enostavno. In shranjevanje je kul, če je.

Toda ZFS je na voljo vsem. DelPhix je že dovolj, imajo 300 strank. Od tega ima Fortune 100 50 klientov, torej ciljajo na Naso itd. Čas je, da vsi dobijo to tehnologijo. In zato imamo odprtokodno jedro. Imamo del vmesnika, ki ni odprtokoden. To je platforma, ki jo bomo pokazali. Želimo pa, da je dostopen vsem. Želimo narediti revolucijo, da bi vsi preizkuševalci nehali ugibati na prenosnikih. Napisati moramo SELECT in takoj vidimo, da je počasen. Nehajte čakati, da vam DBA pove o tem. Tukaj je glavni cilj. In mislim, da bomo vsi prišli do tega. In to stvar naredimo za vsakogar. Zato ZFS, ker bo na voljo povsod. Hvala skupnosti za reševanje težav in za odprtokodno licenco itd.*

Pozdravi! Hvala za poročilo! Moje ime je Maxim. Ukvarjali smo se z istimi vprašanji. Odločili so se sami. Kako delite vire med temi kloni? Vsak klon lahko v danem trenutku naredi svoje: eden testira eno, drugi drugo, nekdo gradi indeks, nekdo ima težko delo. In če še vedno lahko delite po CPU, potem pa po IO, kako delite? To je prvo vprašanje.

In drugo vprašanje je o različnosti stojnic. Tukaj imam recimo ZFS in je vse kul, odjemalec na produ pa nima ZFS, ampak ext4 npr. Kako v tem primeru?

Vprašanja so zelo dobra. Ta problem sem malo omenil z dejstvom, da si delimo vire. In rešitev je ta. Predstavljajte si, da preizkušate uprizoritev. Lahko imaš istočasno tudi takšno situacijo, da nekdo da eno obremenitev, nekdo drugo. In posledično vidite meritve, ki so nerazumljive. Celo ista težava je lahko pri prod. Ko hočeš preveriti neko zahtevo in vidiš, da je z njo neka težava - deluje počasi, potem dejansko ni bila težava v zahtevi, ampak v tem, da obstaja nekakšna vzporedna obremenitev.

Zato je tukaj pomembno, da se osredotočimo na to, kakšen bo načrt, katere korake bomo naredili v načrtu in koliko podatkov bomo za to zbrali. Dejstvo, da bodo naši diski, na primer, naloženi z nečim, bo posebej vplivalo na čas. Lahko pa ocenimo, kako obremenjena je ta zahteva po količini podatkov. Ni tako pomembno, da bo hkrati prišlo do neke vrste usmrtitve.

Imam dve vprašanji. To je zelo kul stvar. Ali so bili primeri, ko so proizvodni podatki kritični, kot so številke kreditnih kartic? Je že kaj pripravljeno ali je to ločena naloga? In drugo vprašanje - ali obstaja kaj takega za MySQL?

O podatkih. Zakrivali bomo, dokler tega ne storimo. Če pa namestiš točno Joeja, če razvijalcem ne daš dostopa, potem ni dostopa do podatkov. Zakaj? Ker Joe ne prikazuje podatkov. Prikazuje samo metrike, načrte in to je to. To je bilo narejeno namenoma, saj je to ena od zahtev naše stranke. Želeli so imeti možnost optimizacije, ne da bi vsem omogočili dostop.

O MySQL. Ta sistem se lahko uporablja za vse, kar shranjuje stanje na disku. In ker delamo Postgres, zdaj najprej izvajamo vso avtomatizacijo za Postgres. Želimo avtomatizirati pridobivanje podatkov iz varnostne kopije. Postgres pravilno konfiguriramo. Znamo uskladiti načrte itd.

Ker pa je sistem razširljiv, ga je mogoče uporabiti tudi za MySQL. In takih primerov je. Yandex ima podobno stvar, vendar je nikjer ne objavijo. Uporabljajo ga znotraj Yandex.Metrice. In o MySQL je samo zgodba. Toda tehnologije so enake, ZFS.

Hvala za poročilo! Tudi jaz imam par vprašanj. Omenili ste, da se kloniranje lahko uporablja za analitiko, na primer za izdelavo dodatnih indeksov. Lahko poveš kaj več o tem, kako deluje?

In takoj bom postavil drugo vprašanje o podobnosti stojnic, podobnosti načrtov. Načrt je odvisen tudi od statističnih podatkov, ki jih zbira Postgres. Kako rešujete ta problem?

Glede na analitiko ni posebnih primerov, ker je še nismo uporabili, vendar obstaja takšna priložnost. Če govorimo o indeksih, potem si predstavljajte, da poizvedba lovi tabelo s stotinami milijonov zapisov in stolpcem, ki običajno ni indeksiran v prod. In tam želimo izračunati nekaj podatkov. Če je ta zahteva poslana na prod, potem obstaja možnost, da bo preprosto na prod, ker bo tam zahteva obdelana minuto.

Ok, naredimo tanek klon, ki ga ni grozno ustaviti za nekaj minut. In da bi bilo branje analitike udobnejše, bomo dodali indekse za tiste stolpce, v katerih nas zanimajo podatki.

Bo indeks ustvarjen vsakič?

Lahko naredite tako, da se dotaknemo podatkov, naredimo posnetke, nato pa si bomo iz tega posnetka opomogli in spodbudili nove zahteve. To pomeni, da lahko naredite tako, da lahko vzgajate nove klone z že pritrjenimi indeksi.

Glede vprašanja o statistiki, če obnovimo iz varnostne kopije, če naredimo replikacijo, bo naša statistika popolnoma enaka. Ker imamo celotno fizično strukturo podatkov, bomo podatke prinesli takšne, kot so, tudi z vsemi statističnimi meritvami.

Tukaj je še en problem. Če uporabljate rešitev v oblaku, potem so tam na voljo samo logični dump-i, saj Google, Amazon ne dovolita narediti fizične kopije. Težava bo.

Hvala za poročilo. Tu sta bili dve dobri vprašanji o MySQL in skupni rabi virov. Toda v resnici se vse zmanjša na dejstvo, da to ni tema določenega DBMS, ampak datotečnega sistema kot celote. In v skladu s tem je treba tudi vprašanja souporabe virov rešiti od tam, ne na koncu, da je to Postgres, ampak v datotečnem sistemu, na primer v strežniku.

Moje vprašanje je malo drugačno. Bližje je večplastni bazi podatkov, kjer je več plasti. Na primer, nastavimo posodobitev desetterabajtne slike, repliciramo. In to rešitev posebej uporabljamo za baze podatkov. Replikacija je v teku, podatki se posodabljajo. Tukaj vzporedno dela 100 zaposlenih, ki nenehno lansirajo te različne posnetke. Kaj storiti? Kako zagotoviti, da ni konflikta, da so ga zagnali, nato pa se je datotečni sistem spremenil in te slike so vse izginile?

Ne bodo šli, ker tako deluje ZFS. V eni niti lahko ločeno hranimo spremembe datotečnega sistema, ki nastanejo zaradi replikacije. In ohranite klone, ki jih razvijalci uporabljajo na starejših različicah podatkov. In pri nas deluje, s tem je vse v redu.

Izkazalo se je, da bo posodobitev potekala kot dodatna plast in vse nove slike bodo že šle na podlagi te plasti, kajne?

Iz prejšnjih plasti, ki so bile iz prejšnjih replikacij.

Prejšnje plasti bodo odpadle, vendar se bodo nanašale na staro plast in ali bodo vzele nove slike iz zadnje plasti, ki je bila prejeta v posodobitvi?

Na splošno ja.

Potem bomo imeli kot posledico do figo plasti. In čez čas jih bo treba stisniti?

Da, vse je pravilno. Obstaja nekaj okna. Vodimo tedenske utrinke. Odvisno od tega, kakšen vir imate. Če imate možnost shraniti veliko podatkov, lahko posnetke shranjujete dolgo časa. Ne bodo odšli sami od sebe. Ne bo poškodovanih podatkov. Če so posnetki zastareli, kot se nam zdi, torej odvisno od politike v podjetju, jih lahko preprosto izbrišemo in sprostimo prostor.

Pozdravljeni, hvala za poročilo! Vprašanje o Joeju. Rekli ste, da stranka ni želela vsem omogočiti dostopa do podatkov. Strogo gledano, če ima oseba rezultat Explain Analyze, potem lahko pokuka v podatke.

Tako je. Na primer, lahko napišemo: "SELECT FROM WHERE email = to that". To pomeni, da samih podatkov ne bomo videli, lahko pa vidimo nekaj posrednih znakov. To je treba razumeti. A po drugi strani je vse tam. Imamo log audit, imamo nadzor nad drugimi sodelavci, ki tudi vidijo, kaj delajo razvijalci. In če nekdo poskuša to storiti, potem bo varnostna služba prišla k njim in delala na tem vprašanju.

Dober večer Hvala za poročilo! Imam kratko vprašanje. Če podjetje ne uporablja Slacka, ali obstaja kakšna vezava nanj zdaj ali je mogoče, da razvijalci uvedejo primerke, da bi testno aplikacijo povezali z bazami podatkov?

Zdaj obstaja povezava do Slacka, tj. ni nobenega drugega messengerja, vendar si resnično želim omogočiti podporo tudi za druge messengerje. Kaj lahko narediš? DB Lab lahko namestite brez Joeja, uporabite REST API ali našo platformo in ustvarite klone ter se povežete s PSQL. Toda to je mogoče storiti, če ste pripravljeni svojim razvijalcem omogočiti dostop do podatkov, ker ne bo več nobenega zaslona.

Ne potrebujem te plasti, potrebujem pa takšno priložnost.

Potem ja, to je mogoče storiti.

Vir: www.habr.com