DBA-bot Joe. Anatoli Stansler (Postgres.ai)

Hoe begrijpt een backend-ontwikkelaar dat een SQL-query goed zal werken op een "prod"? In grote of snelgroeiende bedrijven heeft niet iedereen toegang tot het "product". En met toegang kunnen niet alle verzoeken pijnloos worden gecontroleerd, en het maken van een kopie van de database duurt vaak uren. Om deze problemen op te lossen, hebben we een kunstmatige DBA gemaakt - Joe. Het is al met succes geïmplementeerd in verschillende bedrijven en helpt meer dan een dozijn ontwikkelaars.

Video:

Dag Allemaal! Mijn naam is Anatoly Stansler. Ik werk voor een bedrijf postgres.ai. We zetten ons in om het ontwikkelingsproces te versnellen door de vertragingen die verband houden met het werk van Postgres weg te nemen bij ontwikkelaars, DBA's en QA's.

We hebben geweldige klanten en vandaag zal een deel van het rapport gewijd zijn aan zaken die we tegenkwamen tijdens het werken met hen. Ik zal het hebben over hoe we hen hebben geholpen bij het oplossen van vrij ernstige problemen.

Wanneer we complexe migraties met hoge belasting ontwikkelen en uitvoeren, stellen we onszelf de vraag: "Gaat deze migratie van start?". We gebruiken review, we gebruiken de kennis van meer ervaren collega's, DBA-experts. En ze kunnen vertellen of het zal vliegen of niet.

Maar misschien is het beter als we het zelf kunnen testen op full size exemplaren. En vandaag zullen we het alleen hebben over welke benaderingen van testen nu zijn en hoe het beter kan worden gedaan en met welke tools. We zullen ook praten over de voor- en nadelen van dergelijke benaderingen, en wat we hier kunnen oplossen.

Wie heeft er ooit rechtstreeks op prod geïndexeerd of wijzigingen aangebracht? Nogal wat. En bij wie leidde dit tot het verlies van data of downtime? Dan ken je deze pijn. Godzijdank zijn er back-ups.

De eerste benadering is testen in prod. Of, wanneer een ontwikkelaar op een lokale computer zit, hij testgegevens heeft, is er een soort beperkte selectie. En we rollen uit om te porren, en we krijgen deze situatie.

Het doet pijn, het is duur. Het is waarschijnlijk het beste om het niet te doen.

En wat is de beste manier om het te doen?

Laten we de enscenering nemen en daar een deel van de productie selecteren. Of in het beste geval, laten we een echte prik nemen, alle gegevens. En nadat we het lokaal hebben ontwikkeld, controleren we bovendien op staging.

Hierdoor kunnen we enkele fouten verwijderen, d.w.z. voorkomen dat ze op prod.

Wat zijn de problemen?

• Het probleem is dat we deze enscenering delen met collega's. En heel vaak gebeurt het dat je een soort wijziging aanbrengt, bam - en er zijn geen gegevens, het werk is in de put. Staging was multi-terabyte. En je moet lang wachten tot het weer opkomt. En we besluiten het morgen af ​​te ronden. Dat is het, we hebben een ontwikkeling.
• En natuurlijk werken er veel collega's, veel teams. En dat moet handmatig gebeuren. En dit is onhandig.

En het is de moeite waard om te zeggen dat we maar één poging hebben, één kans, als we enkele wijzigingen in de database willen aanbrengen, de gegevens willen aanraken, de structuur willen wijzigen. En als er iets mis is gegaan, als er een fout is opgetreden bij de migratie, dan draaien we niet snel terug.

Dit is beter dan de vorige aanpak, maar er is nog steeds een grote kans dat een of andere fout naar productie gaat.

Wat weerhoudt ons ervan om elke ontwikkelaar een testbank te geven, een kopie op ware grootte? Ik denk dat het duidelijk is wat er in de weg staat.

Wie heeft een database groter dan een terabyte? Meer dan de helft van de kamer.

En het is duidelijk dat het houden van machines voor elke ontwikkelaar, wanneer er zo'n grote productie is, erg duur is, en bovendien duurt het lang.

We hebben klanten die zich realiseerden dat het erg belangrijk is om alle wijzigingen op volledige grootte te testen, maar hun database is minder dan een terabyte en er zijn geen middelen om voor elke ontwikkelaar een testbank te houden. Daarom moeten ze de dumps lokaal naar hun machine downloaden en op deze manier testen. Het kost veel tijd.

Zelfs als je het binnen de infrastructuur doet, dan is het downloaden van één terabyte aan data per uur al erg goed. Maar ze gebruiken logische dumps, ze downloaden lokaal vanuit de cloud. Voor hen is de snelheid ongeveer 200 gigabyte per uur. En het kost nog steeds tijd om van de logische dump af te komen, de indexen op te rollen, enz.

Maar ze gebruiken deze aanpak omdat het hen in staat stelt de prikstok betrouwbaar te houden.

Wat kunnen we hier doen? Laten we testbanken goedkoop maken en elke ontwikkelaar zijn eigen testbank geven.

En dit is mogelijk.

En in deze benadering kunnen we, wanneer we dunne klonen maken voor elke ontwikkelaar, deze op één machine delen. Als u bijvoorbeeld een database van 10 TB heeft en deze aan 10 ontwikkelaars wilt geven, hoeft u geen databases van XNUMX x XNUMX TB te hebben. Je hebt maar één machine nodig om dunne geïsoleerde kopieën te maken voor elke ontwikkelaar die één machine gebruikt. Ik zal je later vertellen hoe het werkt.

Echt voorbeeld:

• DB - 4,5 terabyte.

• We kunnen binnen 30 seconden onafhankelijke kopieën krijgen.

U hoeft niet te wachten op een proefstand en bent afhankelijk van hoe groot deze is. Je kunt het binnen enkele seconden krijgen. Het worden volledig geïsoleerde omgevingen, maar die onderling wel data delen.

Dit is geweldig. Hier hebben we het over magie en een parallel universum.

In ons geval werkt dit met behulp van het OpenZFS-systeem.

OpenZFS is een copy-on-write bestandssysteem dat standaard snapshots en klonen ondersteunt. Het is betrouwbaar en schaalbaar. Ze is heel gemakkelijk te beheren. Het kan letterlijk in twee teams worden ingezet.

Er zijn andere opties:

• lvm,

• Opslag (bijvoorbeeld Pure Storage).

Het Database Lab waar ik het over heb is modulair. Kan worden geïmplementeerd met behulp van deze opties. Maar voor nu hebben we ons gericht op OpenZFS, omdat er specifiek problemen waren met LVM.

Hoe het werkt? In plaats van de gegevens elke keer dat we ze wijzigen te overschrijven, slaan we ze op door simpelweg te markeren dat deze nieuwe gegevens van een nieuw tijdstip komen, een nieuwe momentopname.

En als we in de toekomst willen terugdraaien of een nieuwe kloon willen maken van een oudere versie, zeggen we gewoon: "OK, geef ons deze gegevensblokken die zo zijn gemarkeerd."

En deze gebruiker gaat met zo'n dataset aan de slag. Hij zal ze geleidelijk veranderen, zijn eigen snapshots maken.

En we zullen vertakken. Elke ontwikkelaar krijgt in ons geval de mogelijkheid om zijn eigen kloon te hebben die hij bewerkt, en de gegevens die worden gedeeld, worden met iedereen gedeeld.

Om zo'n systeem thuis te implementeren, moet u twee problemen oplossen:

• De eerste is de bron van de gegevens, waar u deze vandaan haalt. U kunt replicatie instellen met productie. Je kunt de back-ups die je hebt geconfigureerd al gebruiken, hoop ik. WAL-E, WAL-G of Barman. En zelfs als u een soort cloudoplossing zoals RDS of Cloud SQL gebruikt, kunt u logische dumps gebruiken. Maar we raden u nog steeds aan om back-ups te gebruiken, omdat u met deze aanpak ook de fysieke structuur van de bestanden behoudt, waardoor u nog dichter bij de statistieken kunt komen die u in productie zou zien om de bestaande problemen op te vangen.

• De tweede is waar u het Database Lab wilt hosten. Het kan de cloud zijn, het kan lokaal zijn. Het is belangrijk om hier te zeggen dat ZFS datacompressie ondersteunt. En het doet het vrij goed.

Stel je voor dat voor elke dergelijke kloon, afhankelijk van de bewerkingen die we met de basis uitvoeren, een soort ontwikkelaar zal groeien. Hiervoor heeft dev ook ruimte nodig. Maar vanwege het feit dat we een basis van 4,5 terabyte hebben genomen, zal ZFS deze comprimeren tot 3,5 terabyte. Dit kan variëren afhankelijk van de instellingen. En we hebben nog ruimte voor dev.

Een dergelijk systeem kan voor verschillende gevallen worden gebruikt.

• Dit zijn ontwikkelaars, DBA's voor queryvalidatie, voor optimalisatie.

• Dit kan worden gebruikt bij QA-testen om een ​​bepaalde migratie te testen voordat we deze uitrollen naar prod. En we kunnen ook speciale omgevingen voor QA opzetten met echte gegevens, waar ze nieuwe functionaliteit kunnen testen. En het zal seconden duren in plaats van uren wachten, en misschien dagen in sommige andere gevallen waar dunne kopieën niet worden gebruikt.

• En nog een geval. Als het bedrijf geen analysesysteem heeft opgezet, kunnen we een dunne kloon van de productbasis isoleren en deze aan lange zoekopdrachten of speciale indexen geven die in analyses kunnen worden gebruikt.

Met deze aanpak:

1. Lage kans op fouten op de "prod", omdat we alle wijzigingen op volledige gegevens hebben getest.

2. We hebben een testcultuur, want nu hoef je niet uren te wachten op je eigen stand.

3. En er is geen barrière, geen wachttijd tussen tests. Je kunt echt gaan kijken. En het zal op deze manier beter zijn naarmate we de ontwikkeling versnellen.

• Er zal minder refactoring plaatsvinden. Er zullen minder bugs in prod. We zullen ze later minder refactoren.

• We kunnen onomkeerbare veranderingen ongedaan maken. Dit is niet de standaard aanpak.

1. Dit is gunstig omdat we de middelen van de testbanken delen.

Al goed, maar wat kan er nog meer versneld worden?

Dankzij zo'n systeem kunnen we de drempel om aan zo'n toetsing mee te doen sterk verlagen.

Nu is er een vicieuze cirkel waarin een ontwikkelaar een expert moet worden om toegang te krijgen tot echte gegevens op ware grootte. Die toegang moet hem worden toevertrouwd.

Maar hoe te groeien als het er niet is. Maar wat als u maar een zeer kleine set testgegevens tot uw beschikking heeft? Dan krijg je geen echte ervaring.

Hoe kom je uit deze cirkel? Als eerste interface, handig voor ontwikkelaars van elk niveau, kozen we voor de Slack-bot. Maar het kan elke andere interface zijn.

Wat stelt het je in staat om te doen? U kunt een specifieke vraag nemen en deze naar een speciaal kanaal voor de database sturen. We zullen binnen enkele seconden automatisch een dunne kloon implementeren. Laten we dit verzoek uitvoeren. We verzamelen statistieken en aanbevelingen. Laten we een visualisatie laten zien. En dan blijft deze kloon staan, zodat deze query op de een of andere manier kan worden geoptimaliseerd, indexen kunnen worden toegevoegd, enz.

En ook Slack geeft ons mogelijkheden voor out-of-the-box samenwerking. Aangezien dit slechts een kanaal is, kunt u beginnen met het bespreken van dit verzoek daar in de thread voor een dergelijk verzoek, uw collega's pingen, DBA's binnen het bedrijf.

Maar er zijn natuurlijk problemen. Omdat dit de echte wereld is en we een server gebruiken die veel klonen tegelijk host, moeten we de hoeveelheid geheugen en CPU-kracht die beschikbaar is voor de klonen comprimeren.

Maar om deze tests aannemelijk te maken, moet u dit probleem op de een of andere manier oplossen.

Het is duidelijk dat het belangrijkste punt dezelfde gegevens zijn. Maar we hebben het al. En we willen dezelfde configuratie bereiken. En we kunnen zo'n bijna identieke configuratie geven.

Het zou cool zijn om dezelfde hardware te hebben als in productie, maar het kan verschillen.

Laten we onthouden hoe Postgres werkt met geheugen. We hebben twee caches. Een van het bestandssysteem en een native Postgres, d.w.z. Shared Buffer Cache.

Het is belangrijk op te merken dat de Shared Buffer Cache wordt toegewezen wanneer Postgres start, afhankelijk van de grootte die u opgeeft in de configuratie.

En de tweede cache gebruikt alle beschikbare ruimte.

En als we meerdere klonen op één machine maken, blijkt dat we geleidelijk aan het geheugen vullen. En op een goede manier is Shared Buffer Cache 25% van de totale hoeveelheid geheugen die beschikbaar is op de machine.

En het blijkt dat als we deze parameter niet wijzigen, we slechts 4 instanties op één machine kunnen uitvoeren, dat wil zeggen 4 van deze dunne klonen in totaal. En dit is natuurlijk slecht, want we willen er veel meer van hebben.

Maar aan de andere kant wordt Buffer Cache gebruikt om query's voor indexen uit te voeren, dat wil zeggen, het plan hangt af van hoe groot onze caches zijn. En als we deze parameter gewoon nemen en verminderen, dan kunnen onze plannen veel veranderen.

Als we bijvoorbeeld een grote cache op prod hebben, gebruikt Postgres liever een index. En zo niet, dan komt er SeqScan. En wat zou het voor zin hebben als onze plannen niet samenvielen?

Maar hier komen we tot de conclusie dat het plan in Postgres in feite niet afhankelijk is van de specifieke grootte die is opgegeven in de gedeelde buffer in het plan, maar van de effective_cache_size.

Effective_cache_size is de geschatte hoeveelheid cache die voor ons beschikbaar is, d.w.z. de som van Buffer Cache en bestandssysteemcache. Dit wordt ingesteld door de config. En dit geheugen is niet toegewezen.

En dankzij deze parameter kunnen we Postgres voor de gek houden door te zeggen dat we eigenlijk veel gegevens beschikbaar hebben, zelfs als we deze gegevens niet hebben. En zo zullen de plannen volledig samenvallen met de productie.

Maar dit kan de timing beïnvloeden. En we optimaliseren zoekopdrachten door timing, maar het is belangrijk dat timing van veel factoren afhangt:

• Het hangt af van de belasting die momenteel op prod.

• Het hangt af van de kenmerken van de machine zelf.

En dit is een indirecte parameter, maar in feite kunnen we precies optimaliseren door de hoeveelheid gegevens die deze query zal lezen om het resultaat te krijgen.

En als je wilt dat de timing in de buurt komt van wat we in prod zullen zien, dan moeten we de meest vergelijkbare hardware nemen en mogelijk zelfs meer zodat alle klonen passen. Maar dit is een compromis, d.w.z. u krijgt dezelfde plannen, u ziet hoeveel gegevens een bepaalde query zal lezen en u kunt concluderen of deze query goed (of migratie) of slecht is, deze moet nog worden geoptimaliseerd .

Laten we eens kijken hoe Joe specifiek is geoptimaliseerd.

Laten we een verzoek van een echt systeem nemen. In dit geval is de database 1 terabyte. En we willen het aantal nieuwe posts tellen dat meer dan 10 likes had.

We schrijven een bericht naar het kanaal, er is een kloon voor ons ingezet. En we zullen zien dat zo'n verzoek binnen 2,5 minuut rond is. Dit is het eerste wat ons opvalt.

B Joe laat je automatische aanbevelingen zien op basis van het plan en de statistieken.

We zullen zien dat de query te veel gegevens verwerkt om een ​​relatief klein aantal rijen te krijgen. En er is een soort gespecialiseerde index nodig, aangezien we hebben gemerkt dat er te veel gefilterde rijen in de query zijn.

Laten we eens nader bekijken wat er is gebeurd. We zien inderdaad dat we bijna anderhalve gigabyte aan gegevens uit de bestandscache of zelfs van schijf hebben gelezen. En dit is niet goed, want we hebben maar 142 regels.

En het lijkt erop dat we hier een indexscan hebben en dat het snel had moeten werken, maar omdat we te veel regels eruit hebben gefilterd (we moesten ze tellen), werkte de query langzaam.

En dit gebeurde in het plan vanwege het feit dat de voorwaarden in de query en de voorwaarden in de index gedeeltelijk niet overeenkomen.

Laten we proberen de index nauwkeuriger te maken en kijken hoe de uitvoering van de query daarna verandert.

Het maken van de index duurde behoorlijk lang, maar nu controleren we de query en zien we dat de tijd in plaats van 2,5 minuut slechts 156 milliseconden is, wat goed genoeg is. En we lezen slechts 6 megabyte aan gegevens.

En nu gebruiken we alleen indexscan.

Een ander belangrijk verhaal is dat we het plan op een begrijpelijkere manier willen presenteren. We hebben visualisatie geïmplementeerd met behulp van Flame Graphs.

Dit is een ander verzoek, intenser. En we bouwen Flame Graphs volgens twee parameters: dit is de hoeveelheid data die een bepaald knooppunt telde in het plan en de timing, d.w.z. de uitvoeringstijd van het knooppunt.

Hier kunnen we specifieke knooppunten met elkaar vergelijken. En het zal duidelijk zijn wie van hen meer of minder nodig heeft, wat meestal moeilijk is bij andere weergavemethoden.

Iedereen kent natuurlijk explain.depesz.com. Een goede eigenschap van deze visualisatie is dat we het tekstplan opslaan en ook enkele basisparameters in een tabel zetten zodat we kunnen sorteren.

En ontwikkelaars die zich nog niet in dit onderwerp hebben verdiept, gebruiken ook explain.depesz.com, omdat het voor hen gemakkelijker is om erachter te komen welke statistieken belangrijk zijn en welke niet.

Er is een nieuwe benadering van visualisatie - dit is explain.dalibo.com. Ze doen een boomvisualisatie, maar het is erg moeilijk om knooppunten met elkaar te vergelijken. Hier kun je de structuur goed begrijpen, echter als er een grote aanvraag is, dan zul je heen en weer moeten scrollen, maar ook een optie.

оллаборация

En, zoals ik al zei, Slack geeft ons de mogelijkheid om samen te werken. Als we bijvoorbeeld een complexe query tegenkomen waarvan niet duidelijk is hoe we deze moeten optimaliseren, kunnen we dit probleem met onze collega's verduidelijken in een thread in Slack.

Het lijkt ons belangrijk om te testen op full-size data. Hiervoor hebben we de tool Update Database Lab gemaakt, die beschikbaar is in open source. Je kunt ook de Joe-bot gebruiken. U kunt het nu meteen doen en het bij u thuis implementeren. Alle gidsen zijn daar verkrijgbaar.

Het is ook belangrijk op te merken dat de oplossing zelf niet revolutionair is, want er is Delphix, maar het is een enterprise-oplossing. Het is volledig gesloten, het is erg duur. Wij zijn specifiek gespecialiseerd in Postgres. Dit zijn allemaal open source producten. Doe met ons mee!

Hier eindig ik. Bedankt!

vragen

Hallo! Bedankt voor het verslag! Heel interessant, vooral voor mij, omdat ik enige tijd geleden ongeveer hetzelfde probleem heb opgelost. En dus heb ik een aantal vragen. Hopelijk krijg ik er in ieder geval een deel van.

Ik vraag me af hoe je de plaats voor deze omgeving berekent? De technologie zorgt ervoor dat je klonen onder bepaalde omstandigheden tot de maximale grootte kunnen groeien. Grof gezegd, als je een database van tien terabyte en 10 klonen hebt, dan is het gemakkelijk om een ​​situatie te simuleren waarin elke kloon 10 unieke gegevens weegt. Hoe bereken je deze plek, dat wil zeggen, die delta waar je het over had, waarin deze klonen zullen leven?

Goede vraag. Het is belangrijk om hier specifieke klonen bij te houden. En als een kloon een te grote verandering heeft, begint hij te groeien, dan kunnen we de gebruiker daar eerst een waarschuwing over geven, of deze kloon direct stoppen zodat we geen faalsituatie krijgen.

Ja, ik heb een geneste vraag. Dat wil zeggen, hoe borg je de levenscyclus van deze modules? We hebben dit probleem en een heel apart verhaal. Hoe gebeurde dit?

Er is wat ttl voor elke kloon. In principe hebben we een vaste ttl.

Wat, zo niet een geheim?

1 uur, d.w.z. inactief - 1 uur. Als het niet wordt gebruikt, slaan we het. Maar dat is geen verrassing, aangezien we de kloon binnen enkele seconden kunnen opvoeden. En als je het weer nodig hebt, graag.

Ik ben ook geïnteresseerd in de keuze van technologieën, omdat we bijvoorbeeld om de een of andere reden meerdere methoden naast elkaar gebruiken. Waarom ZFS? Waarom heb je geen LVM gebruikt? U zei dat er problemen waren met LVM. Wat waren de problemen? Naar mijn mening is de meest optimale optie met opslag, qua prestaties.

Wat is het grootste probleem met ZFS? Het feit dat u op dezelfde host moet draaien, d.w.z. dat alle instanties binnen hetzelfde besturingssysteem zullen leven. En in het geval van opslag kun je verschillende apparaten aansluiten. En het knelpunt zijn alleen die blokken die op het opslagsysteem staan. En de kwestie van de keuze van technologieën is interessant. Waarom niet LVM?

Concreet kunnen we LVM bespreken tijdens meetup. Over opslag - het is gewoon duur. We kunnen het ZFS-systeem overal implementeren. U kunt het op uw machine implementeren. U kunt de repository eenvoudig downloaden en implementeren. ZFS is bijna overal geïnstalleerd als we het over Linux hebben. Dat wil zeggen, we krijgen een zeer flexibele oplossing. En uit de doos geeft ZFS veel. U kunt zoveel gegevens uploaden als u wilt, een groot aantal schijven aansluiten, er zijn snapshots. En, zoals ik al zei, het is gemakkelijk te beheren. Dat wil zeggen, het lijkt erg prettig in gebruik. Hij is getest, hij is vele jaren oud. Hij heeft een zeer grote gemeenschap die groeit. ZFS is een zeer betrouwbare oplossing.

Nikolai Samokhvalov: Mag ik verder reageren? Mijn naam is Nikolay, we werken samen met Anatoly. Ik ben het ermee eens dat opslag geweldig is. En sommige van onze klanten hebben Pure Storage enz.

Anatoly merkte terecht op dat we gefocust zijn op modulariteit. En in de toekomst kunt u één interface implementeren - een momentopname maken, een kloon maken, de kloon vernietigen. Het is allemaal makkelijk. En opslag is cool, als dat zo is.

Maar ZFS is voor iedereen beschikbaar. DelPhix is ​​al genoeg, ze hebben 300 klanten. Hiervan heeft Fortune 100 50 klanten, d.w.z. ze zijn gericht op NASA, enz. Het wordt tijd dat iedereen deze technologie krijgt. En daarom hebben we een open source Core. We hebben een interfacegedeelte dat niet open source is. Dit is het platform dat we zullen laten zien. Maar we willen dat het voor iedereen toegankelijk is. We willen een revolutie teweegbrengen zodat alle testers stoppen met gissen op laptops. We moeten SELECT schrijven en zien meteen dat het traag is. Stop met wachten tot de DBA u erover vertelt. Hier is het hoofddoel. En ik denk dat we hier allemaal naartoe zullen komen. En we maken dit ding voor iedereen om te hebben. Daarom ZFS, want dat zal overal beschikbaar zijn. Dank aan de gemeenschap voor het oplossen van problemen en voor het hebben van een open source-licentie, etc.*

Groeten! Bedankt voor het verslag! Mijn naam is Maxim. We hebben met dezelfde problemen te maken gehad. Ze hebben zelf besloten. Hoe deel je bronnen tussen deze klonen? Elke kloon kan op elk moment zijn eigen ding doen: de een test het een, de ander het ander, iemand bouwt een index op, iemand heeft een zware baan. En als je nog steeds kunt delen door CPU, dan door IO, hoe deel je dan? Dit is de eerste vraag.

En de tweede vraag gaat over de ongelijkheid van de tribunes. Laten we zeggen dat ik hier ZFS heb en alles is cool, maar de client op prod heeft geen ZFS, maar bijvoorbeeld ext4. Hoe in dit geval?

De vragen zijn erg goed. Ik noemde dit probleem een ​​beetje met het feit dat we middelen delen. En de oplossing is deze. Stel je voor dat je aan het testen bent op enscenering. Je kunt ook tegelijkertijd zo'n situatie hebben dat iemand de ene lading geeft, iemand anders. En als resultaat zie je onbegrijpelijke statistieken. Zelfs hetzelfde probleem kan zijn met prod. Als je een verzoek wilt controleren en wilt zien dat er een probleem mee is - het werkt langzaam, dan zat het probleem in feite niet in het verzoek, maar in het feit dat er een soort parallelle belasting is.

En daarom is het belangrijk om hier stil te staan ​​bij wat het plan gaat worden, welke stappen we gaan zetten in het plan en hoeveel data we hiervoor gaan verzamelen. Het feit dat onze schijven bijvoorbeeld met iets worden geladen, heeft met name invloed op de timing. Maar we kunnen inschatten hoe geladen dit verzoek is aan de hand van de hoeveelheid gegevens. Het is niet zo belangrijk dat er tegelijkertijd een soort executie zal zijn.

Ik heb twee vragen. Dit is erg cool spul. Zijn er gevallen geweest waarin productiegegevens cruciaal zijn, zoals creditcardnummers? Staat er al iets klaar of is het een aparte taak? En de tweede vraag - is er zoiets voor MySQL?

Over de gegevens. We zullen obfuscatie doen totdat we dat doen. Maar als je precies Joe inzet, als je ontwikkelaars geen toegang geeft, dan is er geen toegang tot de data. Waarom? Omdat Joe geen gegevens laat zien. Het toont alleen statistieken, plannen en dat is alles. Dit is met opzet gedaan, omdat dit een van de eisen van onze klant is. Ze wilden kunnen optimaliseren zonder iedereen toegang te geven.

Over MySQL. Dit systeem kan worden gebruikt voor alles wat status op schijf opslaat. En aangezien we Postgres doen, doen we nu eerst alle automatisering voor Postgres. We willen het ophalen van gegevens uit een back-up automatiseren. We configureren Postgres correct. We weten hoe we plannen moeten laten matchen, enz.

Maar aangezien het systeem uitbreidbaar is, kan het ook voor MySQL worden gebruikt. En zulke voorbeelden zijn er. Yandex heeft iets soortgelijks, maar ze publiceren het nergens. Ze gebruiken het binnen Yandex.Metrica. En er is gewoon een verhaal over MySQL. Maar de technologieën zijn hetzelfde, ZFS.

Bedankt voor het verslag! Ik heb ook een paar vragen. U zei dat klonen kan worden gebruikt voor analyse, bijvoorbeeld om daar extra indexen te bouwen. Kun je iets meer vertellen over hoe het werkt?

En ik zal meteen de tweede vraag stellen over de gelijkenis van de stands, de gelijkenis van de plannen. Het plan is ook afhankelijk van de statistieken die door Postgres worden verzameld. Hoe lost u dit probleem op?

Volgens de analyses zijn er geen specifieke gevallen, omdat we het nog niet hebben gebruikt, maar er is zo'n kans. Als we het hebben over indexen, stel je dan voor dat een query een tabel achtervolgt met honderden miljoenen records en een kolom die meestal niet is geïndexeerd in prod. En we willen daar wat gegevens berekenen. Als dit verzoek naar prod wordt gestuurd, bestaat de mogelijkheid dat het op prod eenvoudig is, omdat het verzoek daar een minuut wordt verwerkt.

Oké, laten we een dunne kloon maken die niet erg is om een ​​paar minuten te stoppen. En om het lezen van de analyses comfortabeler te maken, zullen we indices toevoegen voor de kolommen waarin we geïnteresseerd zijn in gegevens.

De index wordt elke keer gemaakt?

U kunt ervoor zorgen dat we de gegevens aanraken, momentopnamen maken, waarna we deze momentopname herstellen en nieuwe verzoeken genereren. Dat wil zeggen, je kunt het zo maken dat je nieuwe klonen kunt kweken met reeds aangebrachte indices.

Wat betreft de vraag over statistieken, als we herstellen vanaf een back-up, als we replicatie uitvoeren, dan zullen onze statistieken precies hetzelfde zijn. Omdat we de volledige fysieke gegevensstructuur hebben, dat wil zeggen, we zullen de gegevens brengen zoals ze zijn met alle statistische statistieken.

Hier is nog een probleem. Gebruik je een cloudoplossing, dan zijn daar alleen logische dumps beschikbaar, want Google, Amazon staat niet toe dat je een fysieke kopie maakt. Er zal een probleem zijn.

Bedankt voor het verslag. Er waren hier twee goede vragen over MySQL en het delen van bronnen. Maar in feite komt het er allemaal op neer dat dit geen onderwerp is van een specifiek DBMS, maar van het bestandssysteem als geheel. En dienovereenkomstig moeten de problemen met het delen van bronnen ook van daaruit worden opgelost, niet aan het einde dat het Postgres is, maar in het bestandssysteem, bijvoorbeeld op de server.

Mijn vraag is een beetje anders. Het ligt dichter bij de meerlagige database, waar er meerdere lagen zijn. We hebben bijvoorbeeld een beeldupdate van tien terabyte opgezet, we repliceren. En we gebruiken deze oplossing specifiek voor databases. Replicatie is bezig, gegevens worden bijgewerkt. Er werken 100 medewerkers parallel, die constant deze verschillende shots lanceren. Wat moeten we doen? Hoe zorg je ervoor dat er geen conflict is, dat ze er een hebben gelanceerd en dat het bestandssysteem is gewijzigd en dat deze foto's allemaal zijn verdwenen?

Ze gaan niet, want zo werkt ZFS. We kunnen de wijzigingen in het bestandssysteem die het gevolg zijn van replicatie afzonderlijk in één thread houden. En bewaar de klonen die ontwikkelaars gebruiken op oudere versies van de gegevens. En het werkt voor ons, hiermee is alles in orde.

Het blijkt dat de update zal plaatsvinden als een extra laag, en alle nieuwe foto's zullen al gaan, gebaseerd op deze laag, toch?

Van eerdere lagen die afkomstig waren van eerdere replicaties.

De vorige lagen vallen eraf, maar ze verwijzen naar de oude laag en nemen ze nieuwe afbeeldingen van de laatste laag die in de update is ontvangen?

Over het algemeen wel.

Dan hebben we als gevolg daarvan tot een vijg lagen. En na verloop van tijd zullen ze moeten worden gecomprimeerd?

Ja alles klopt. Er is een raam. We houden wekelijks snapshots bij. Het hangt af van welke bron je hebt. Als u de mogelijkheid heeft om veel gegevens op te slaan, kunt u snapshots voor een lange tijd bewaren. Ze gaan niet vanzelf weg. Er zal geen gegevenscorruptie zijn. Als de snapshots verouderd zijn, zoals het ons lijkt, d.w.z. het hangt af van het beleid in het bedrijf, dan kunnen we ze eenvoudig verwijderen en ruimte vrijmaken.

Hallo, bedankt voor het melden! Vraag over Jo. U zei dat de klant niet iedereen toegang tot de data wilde geven. Strikt genomen, als iemand het resultaat van Explain Analyse heeft, kan hij de gegevens bekijken.

Zo is het. We kunnen bijvoorbeeld schrijven: "SELECTEER VAN WAAR e-mail = naar dat". Dat wil zeggen, we zullen de gegevens zelf niet zien, maar we kunnen enkele indirecte signalen zien. Dit moet begrepen worden. Maar aan de andere kant, het is er allemaal. We hebben een log-audit, we hebben controle over andere collega's die ook zien wat de ontwikkelaars doen. En als iemand dit probeert te doen, zal de veiligheidsdienst naar hen toe komen om aan dit probleem te werken.

Goedemiddag Bedankt voor het verslag! Ik heb een korte vraag. Als het bedrijf Slack niet gebruikt, is er dan nu enige binding aan, of is het mogelijk voor ontwikkelaars om instances in te zetten om een ​​testapplicatie aan de databases te koppelen?

Nu is er een link naar Slack, d.w.z. er is geen andere messenger, maar ik wil echt ook andere messengers ondersteunen. Wat kan je doen? U kunt DB Lab implementeren zonder Joe, met behulp van de REST API of met behulp van ons platform en klonen maken en verbinding maken met PSQL. Maar dit kan worden gedaan als u klaar bent om uw ontwikkelaars toegang tot de gegevens te geven, omdat er geen scherm meer is.

Ik heb deze laag niet nodig, maar ik heb zo'n kans nodig.

Dan ja, dan kan het.

Bron: www.habr.com