DBA bot Joe. Anatoly Stansler (Postgres.ai)

Hur förstår en backend-utvecklare att en SQL-fråga kommer att fungera bra på en "prod"? I stora eller snabbt växande företag har inte alla tillgång till "produkten". Och med åtkomst kan inte alla förfrågningar kontrolleras smärtfritt, och att skapa en kopia av databasen tar ofta timmar. För att lösa dessa problem skapade vi en konstgjord DBA - Joe. Det har redan framgångsrikt implementerats i flera företag och hjälper mer än ett dussin utvecklare.

videor:

Hej alla! Jag heter Anatoly Stansler. Jag jobbar på ett företag postgres.ai. Vi är fast beslutna att påskynda utvecklingsprocessen genom att ta bort förseningarna som är förknippade med Postgres arbete från utvecklare, DBA:er och QA:er.

Vi har fantastiska kunder och idag kommer en del av rapporten att ägnas åt de fall som vi träffade under arbetet med dem. Jag kommer att prata om hur vi hjälpte dem att lösa ganska allvarliga problem.

När vi utvecklar och gör komplexa högbelastningsmigreringar ställer vi oss frågan: "Kommer den här migreringen att ta fart?". Vi använder oss av recension, vi använder oss av kunskapen hos mer erfarna kollegor, DBA-experter. Och de kan säga om den kommer att flyga eller inte.

Men det kanske vore bättre om vi kunde testa det själva på fullstora kopior. Och idag ska vi bara prata om vilka metoder för testning som finns nu och hur det kan göras bättre och med vilka verktyg. Vi kommer också att prata om för- och nackdelar med sådana tillvägagångssätt och vad vi kan fixa här.

Vem har någonsin gjort index direkt på prod eller gjort några ändringar? Ganska lite av. Och för vem ledde detta till att data gick förlorade eller att det blev stillestånd? Då vet du denna smärta. Tack gode gud att det finns backuper.

Det första tillvägagångssättet är testning i prod. Eller, när en utvecklare sitter på en lokal maskin har han testdata, det finns något slags begränsat urval. Och vi rullar ut för att driva, och vi får den här situationen.

Det gör ont, det är dyrt. Det är nog bäst att låta bli.

Och vad är det bästa sättet att göra det?

Låt oss ta iscensättning och välja någon del av prod där. Eller i bästa fall, låt oss ta en riktig prod, all data. Och efter att vi har utvecklat det lokalt kommer vi dessutom att kontrollera om det finns iscensättning.

Detta gör att vi kan ta bort några av felen, dvs förhindra att de finns på prod.

Vilka är problemen?

• Problemet är att vi delar denna iscensättning med kollegor. Och väldigt ofta händer det att du gör någon form av förändring, bam - och det finns inga data, arbetet är nere i avloppet. Staging var flera terabyte. Och man får vänta länge på att den ska stiga igen. Och vi bestämmer oss för att slutföra det imorgon. Det är det, vi har en utveckling.
• Och naturligtvis har vi många kollegor som jobbar där, många team. Och det måste göras manuellt. Och detta är obekvämt.

Och det är värt att säga att vi bara har ett försök, ett skott, om vi vill göra några ändringar i databasen, tryck på data, ändra strukturen. Och om något gick fel, om det fanns ett fel i migreringen, så kommer vi inte snabbt att rulla tillbaka.

Detta är bättre än det tidigare tillvägagångssättet, men det är fortfarande stor sannolikhet att något slags fel kommer att gå till produktion.

Vad hindrar oss från att ge varje utvecklare en testbänk, en kopia i full storlek? Jag tycker att det är tydligt vad som kommer i vägen.

Vem har en databas som är större än en terabyte? Mer än halva rummet.

Och det är klart att det är väldigt dyrt att behålla maskiner för varje utvecklare, när det är så stor produktion, och dessutom tar det lång tid.

Vi har kunder som har insett att det är väldigt viktigt att testa alla ändringar på kopior i full storlek, men deras databas är mindre än en terabyte, och det finns inga resurser för att hålla en testbänk för varje utvecklare. Därför måste de ladda ner dumparna lokalt till sin maskin och testa på detta sätt. Det tar mycket tid.

Även om du gör det inom infrastrukturen är det redan mycket bra att ladda ner en terabyte data per timme. Men de använder logiska dumpar, de laddar ner lokalt från molnet. För dem är hastigheten cirka 200 gigabyte per timme. Och det tar fortfarande tid att vända från den logiska soptippen, rulla upp indexen osv.

Men de använder detta tillvägagångssätt eftersom det tillåter dem att hålla proden pålitlig.

Vad kan vi göra här? Låt oss göra testbänkar billiga och ge varje utvecklare sin egen testbänk.

Och detta är möjligt.

Och i detta tillvägagångssätt, när vi gör tunna kloner för varje utvecklare, kan vi dela det på en maskin. Till exempel, om du har en 10TB-databas och vill ge den till 10 utvecklare, behöver du inte ha XNUMX x XNUMXTB-databaser. Du behöver bara en maskin för att göra tunna isolerade kopior för varje utvecklare som använder en maskin. Jag ska berätta hur det fungerar lite senare.

Verkligt exempel:

• DB - 4,5 terabyte.

• Vi kan få oberoende kopior på 30 sekunder.

Du behöver inte vänta på ett provställ och beror på hur stort det är. Du kan få det på några sekunder. Det blir helt isolerade miljöer, men som delar data sinsemellan.

Det här är bra. Här pratar vi om magi och ett parallellt universum.

I vårt fall fungerar detta med OpenZFS-systemet.

OpenZFS är ett kopiera-på-skriv-filsystem som stöder ögonblicksbilder och kloner direkt. Det är pålitligt och skalbart. Hon är väldigt lätt att hantera. Det kan bokstavligen distribueras i två lag.

Det finns andra alternativ:

• lvm,

• Förvaring (till exempel Pure Storage).

Databaslabbet jag pratar om är modulärt. Kan implementeras med dessa alternativ. Men för tillfället har vi fokuserat på OpenZFS, eftersom det var problem med LVM specifikt.

Hur det fungerar? Istället för att skriva över data varje gång vi ändrar den, sparar vi den genom att helt enkelt markera att denna nya data kommer från en ny tidpunkt, en ny ögonblicksbild.

Och i framtiden, när vi vill återställa eller vi vill göra en ny klon från någon äldre version, säger vi bara: "OK, ge oss dessa datablock som är markerade så här."

Och den här användaren kommer att arbeta med en sådan datamängd. Han kommer gradvis att ändra dem, göra sina egna ögonblicksbilder.

Och vi kommer att förgrena oss. Varje utvecklare i vårt fall kommer att ha möjlighet att ha sin egen klon som han redigerar, och den data som delas kommer att delas mellan alla.

För att distribuera ett sådant system hemma måste du lösa två problem:

• Den första är källan till data, varifrån du kommer att ta den. Du kan ställa in replikering med produktion. Du kan redan använda säkerhetskopiorna som du har konfigurerat, hoppas jag. WAL-E, WAL-G eller Barman. Och även om du använder någon form av molnlösning som RDS eller Cloud SQL, så kan du använda logiska dumpar. Men vi råder dig fortfarande att använda säkerhetskopior, för med detta tillvägagångssätt kommer du också att behålla den fysiska strukturen för filerna, vilket gör att du kan komma ännu närmare de mätvärden som du skulle se i produktionen för att fånga upp de problem som finns.

• Det andra är där du vill vara värd för databaslabbet. Det kan vara Cloud, det kan vara On-premise. Det är viktigt att säga här att ZFS stöder datakomprimering. Och det gör det ganska bra.

Föreställ dig att för varje sådan klon, beroende på operationerna som vi gör med basen, kommer någon form av dev att växa. För detta behöver dev också utrymme. Men på grund av att vi tog en bas på 4,5 terabyte kommer ZFS att komprimera den till 3,5 terabyte. Detta kan variera beroende på inställningarna. Och vi har fortfarande plats för dev.

Ett sådant system kan användas för olika fall.

• Dessa är utvecklare, DBA:er för frågevalidering, för optimering.

• Detta kan användas i QA-testning för att testa en viss migration innan vi rullar ut den till prod. Och vi kan också lyfta speciella miljöer för QA med riktiga data, där de kan testa ny funktionalitet. Och det kommer att ta sekunder istället för att vänta timmar, och kanske dagar i vissa andra fall där tunna kopior inte används.

• Och ett annat fall. Om företaget inte har ett analyssystem inrättat kan vi isolera en tunn klon av produktbasen och ge den till långa frågor eller speciella index som kan användas i analys.

Med detta tillvägagångssätt:

1. Låg sannolikhet för fel på "prod", eftersom vi testade alla ändringar på data i full storlek.

2. Vi har en testkultur, för nu behöver du inte vänta i timmar på din egen monter.

3. Och det finns ingen barriär, ingen väntan mellan proven. Du kan faktiskt gå och kolla. Och det blir bättre på det här sättet när vi snabbar på utvecklingen.

• Det blir mindre refaktorering. Färre buggar kommer att hamna i prod. Vi kommer att refaktorera dem mindre senare.

• Vi kan vända oåterkalleliga förändringar. Detta är inte standardmetoden.

1. Detta är fördelaktigt eftersom vi delar på testbänkarnas resurser.

Redan bra, men vad mer skulle kunna påskyndas?

Tack vare ett sådant system kan vi kraftigt minska tröskeln för att gå in i sådana tester.

Nu finns det en ond cirkel där en utvecklare måste bli expert för att få tillgång till riktig fullstor data. Han måste anförtros sådan tillgång.

Men hur man växer om det inte finns där. Men vad händer om du bara har en mycket liten uppsättning testdata tillgänglig för dig? Då får du ingen riktig upplevelse.

Hur tar man sig ur denna cirkel? Som det första gränssnittet, bekvämt för utvecklare på alla nivåer, valde vi Slack-boten. Men det kan vara vilket annat gränssnitt som helst.

Vad tillåter det dig att göra? Du kan ta en specifik fråga och skicka den till en speciell kanal för databasen. Vi kommer automatiskt att distribuera en tunn klon på några sekunder. Låt oss köra denna begäran. Vi samlar in mätvärden och rekommendationer. Låt oss visa en visualisering. Och då kommer den här klonen att finnas kvar så att den här frågan kan optimeras på något sätt, lägga till index, etc.

Och även Slack ger oss möjligheter till samarbete utanför boxen. Eftersom detta bara är en kanal kan du börja diskutera denna begäran direkt i tråden för en sådan begäran, pinga dina kollegor, DBA:er som finns inne i företaget.

Men det finns naturligtvis problem. Eftersom detta är den verkliga världen, och vi använder en server som är värd för många kloner samtidigt, måste vi komprimera mängden minne och CPU-kraft som är tillgänglig för klonerna.

Men för att dessa tester ska vara rimliga måste du på något sätt lösa det här problemet.

Det är tydligt att den viktiga punkten är samma data. Men vi har det redan. Och vi vill uppnå samma konfiguration. Och vi kan ge en sådan nästan identisk konfiguration.

Det skulle vara coolt att ha samma hårdvara som i produktionen, men det kan skilja sig åt.

Låt oss komma ihåg hur Postgres arbetar med minne. Vi har två cacher. En från filsystemet och en inbyggd Postgres, det vill säga Shared Buffer Cache.

Det är viktigt att notera att den delade buffertcachen tilldelas när Postgres startar, beroende på vilken storlek du anger i konfigurationen.

Och den andra cachen använder allt tillgängligt utrymme.

Och när vi gör flera kloner på en maskin visar det sig att vi gradvis fyller minnet. Och på ett bra sätt är Shared Buffer Cache 25 % av den totala mängden minne som är tillgängligt på maskinen.

Och det visar sig att om vi inte ändrar denna parameter kommer vi att kunna köra endast 4 instanser på en maskin, dvs 4 av alla sådana tunna kloner. Och detta är förstås dåligt, eftersom vi vill ha mycket fler av dem.

Men å andra sidan används Buffer Cache för att exekvera frågor för index, det vill säga planen beror på hur stora våra cacher är. Och om vi bara tar den här parametern och minskar den, kan våra planer förändras mycket.

Till exempel, om vi har en stor cache på prod, så kommer Postgres att föredra att använda ett index. Och om inte, så kommer det att finnas SeqScan. Och vad vore poängen om våra planer inte sammanföll?

Men här kommer vi till slutsatsen att planen i Postgres faktiskt inte beror på den specifika storleken som anges i den delade bufferten i planen, den beror på effektiv_cache_storlek.

Effective_cache_size är den uppskattade mängden cache som är tillgänglig för oss, dvs summan av buffertcache och filsystemcache. Detta ställs in av konfigurationen. Och detta minne är inte tilldelat.

Och på grund av denna parameter kan vi på ett sätt lura Postgres och säga att vi faktiskt har mycket data tillgänglig, även om vi inte har dessa data. Och därmed kommer planerna helt att sammanfalla med produktionen.

Men detta kan påverka timingen. Och vi optimerar frågor efter timing, men det är viktigt att timing beror på många faktorer:

• Det beror på belastningen som för närvarande är på prod.

• Det beror på själva maskinens egenskaper.

Och detta är en indirekt parameter, men i själva verket kan vi optimera exakt efter mängden data som den här frågan kommer att läsa för att få resultatet.

Och om du vill att timingen ska vara nära vad vi kommer att se i prod, då måste vi ta den mest liknande hårdvaran och, möjligen, ännu mer så att alla kloner passar. Men det här är en kompromiss, det vill säga du kommer att få samma planer, du kommer att se hur mycket data en viss fråga kommer att läsa och du kommer att kunna dra slutsatsen om den här frågan är bra (eller migrering) eller dålig, den behöver fortfarande optimeras .

Låt oss ta en titt på hur Joe är specifikt optimerad.

Låt oss ta en förfrågan från ett riktigt system. I det här fallet är databasen 1 terabyte. Och vi vill räkna antalet färska inlägg som haft fler än 10 likes.

Vi skriver ett meddelande till kanalen, en klon har distribuerats åt oss. Och vi kommer att se att en sådan begäran kommer att slutföras på 2,5 minuter. Det här är det första vi lägger märke till.

B Joe kommer att visa dig automatiska rekommendationer baserat på planen och mätvärdena.

Vi kommer att se att frågan bearbetar för mycket data för att få ett relativt litet antal rader. Och något slags specialiserat index behövs, eftersom vi märkte att det finns för många filtrerade rader i frågan.

Låt oss ta en närmare titt på vad som hände. Vi ser faktiskt att vi har läst nästan en och en halv gigabyte data från filcachen eller till och med från disken. Och det här är inte bra, eftersom vi bara fick 142 rader.

Och, det verkar som, vi har en indexskanning här och borde ha fungerat snabbt, men eftersom vi filtrerade bort för många rader (vi var tvungna att räkna dem) löste sig begäran långsamt.

Och detta hände i planen på grund av att villkoren i frågan och villkoren i indexet delvis inte stämmer överens.

Låt oss försöka göra indexet mer exakt och se hur frågekörningen ändras efter det.

Skapandet av indexet tog ganska lång tid, men nu kollar vi frågan och ser att tiden istället för 2,5 minuter bara är 156 millisekunder, vilket är bra nog. Och vi läser bara 6 megabyte data.

Och nu använder vi endast indexskanning.

En annan viktig historia är att vi vill presentera planen på något mer begripligt sätt. Vi har implementerat visualisering med Flame Graphs.

Detta är en annan begäran, mer intensiv. Och vi bygger Flame Graphs enligt två parametrar: det här är mängden data som en viss nod räknade i planen och timingen, det vill säga nodens exekveringstid.

Här kan vi jämföra specifika noder med varandra. Och det blir tydligt vilken av dem som tar mer eller mindre, vilket vanligtvis är svårt att göra i andra renderingsmetoder.

Naturligtvis vet alla explain.depesz.com. En bra egenskap med denna visualisering är att vi sparar textplanen och även lägger in några grundläggande parametrar i en tabell så att vi kan sortera.

Och utvecklare som ännu inte har fördjupat sig i det här ämnet använder också explain.depesz.com, eftersom det är lättare för dem att ta reda på vilka mätvärden som är viktiga och vilka som inte är det.

Det finns ett nytt tillvägagångssätt för visualisering - det här är explain.dalibo.com. De gör en trädvisualisering, men det är väldigt svårt att jämföra noder med varandra. Här kan du förstå strukturen väl, men om det finns en stor förfrågan måste du bläddra fram och tillbaka, men också ett alternativ.

samarbete

Och som sagt, Slack ger oss möjlighet att samarbeta. Till exempel, om vi stöter på en komplex fråga som inte är tydlig hur vi ska optimera, kan vi klargöra denna fråga med våra kollegor i en tråd i Slack.

Det verkar för oss som att det är viktigt att testa på data i full storlek. För att göra detta gjorde vi verktyget Update Database Lab, som är tillgängligt i öppen källkod. Du kan också använda Joe-boten. Du kan ta det redan nu och implementera det på din plats. Alla guider finns där.

Det är också viktigt att notera att lösningen i sig inte är revolutionerande, eftersom det finns Delphix, utan det är en företagslösning. Det är helt stängt, det är väldigt dyrt. Vi är speciellt specialiserade på Postgres. Dessa är alla produkter med öppen källkod. Gå med oss!

Det är här jag slutar. Tack!

frågor

Hallå! Tack för rapporten! Mycket intressant, speciellt för mig, eftersom jag löste ungefär samma problem för en tid sedan. Och så har jag ett antal frågor. Förhoppningsvis får jag åtminstone en del av det.

Jag undrar hur du beräknar platsen för den här miljön? Tekniken innebär att dina kloner under vissa omständigheter kan växa till maximal storlek. Grovt sett, om du har en tio terabyte databas och 10 kloner, så är det lätt att simulera en situation där varje klon väger 10 unika data. Hur beräknar du denna plats, det vill säga deltat som du talade om, där dessa kloner kommer att leva?

Bra fråga. Det är viktigt att hålla reda på specifika kloner här. Och om en klon har en för stor förändring börjar den växa, då kan vi först utfärda en varning till användaren om detta, eller omedelbart stoppa denna klon så att vi inte har en misslyckad situation.

Ja, jag har en kapslad fråga. Det vill säga, hur säkerställer man livscykeln för dessa moduler? Vi har det här problemet och en hel separat historia. Hur går det till?

Det finns någon ttl för varje klon. I grund och botten har vi en fast ttl.

Vad, om inte en hemlighet?

1 timme, dvs tomgång - 1 timme. Om den inte används, då slår vi den. Men det är ingen överraskning här, eftersom vi kan höja klonen på några sekunder. Och om du behöver det igen, snälla.

Jag är också intresserad av valet av teknologier, eftersom vi till exempel använder flera metoder parallellt av en eller annan anledning. Varför ZFS? Varför använde du inte LVM? Du nämnde att det fanns problem med LVM. Vilka var problemen? Enligt min mening är det mest optimala alternativet med lagring, sett till prestanda.

Vad är huvudproblemet med ZFS? Det faktum att du måste köra på samma värd, dvs alla instanser kommer att leva inom samma OS. Och vid förvaring kan du ansluta olika utrustningar. Och flaskhalsen är bara de block som finns på lagringssystemet. Och frågan om valet av teknologier är intressant. Varför inte LVM?

Specifikt kan vi diskutera LVM på meetup. Om förvaring - det är bara dyrt. Vi kan implementera ZFS-systemet var som helst. Du kan distribuera den på din maskin. Du kan helt enkelt ladda ner förvaret och distribuera det. ZFS är installerat nästan överallt om vi pratar om Linux. Det vill säga att vi får en väldigt flexibel lösning. Och ZFS själv ger mycket ur lådan. Du kan ladda upp hur mycket data du vill, ansluta ett stort antal diskar, det finns ögonblicksbilder. Och det är som sagt lätt att administrera. Det vill säga, den verkar väldigt trevlig att använda. Han är testad, han är många år gammal. Han har ett väldigt stort samhälle som växer. ZFS är en mycket pålitlig lösning.

Nikolai Samokhvalov: Får jag kommentera ytterligare? Jag heter Nikolay, vi arbetar tillsammans med Anatoly. Jag håller med om att förvaring är bra. Och några av våra kunder har Pure Storage mm.

Anatoly noterade korrekt att vi är fokuserade på modularitet. Och i framtiden kan du implementera ett gränssnitt - ta en ögonblicksbild, skapa en klon, förstör klonen. Allt är enkelt. Och förvaring är cool, om den är det.

Men ZFS är tillgängligt för alla. DelPhix räcker redan, de har 300 kunder. Av dessa har Fortune 100 50 klienter, det vill säga de är riktade till NASA etc. Det är dags för alla att skaffa sig denna teknik. Och det är därför vi har en öppen källkodskärna. Vi har en gränssnittsdel som inte är öppen källkod. Det här är plattformen som vi kommer att visa. Men vi vill att det ska vara tillgängligt för alla. Vi vill göra en revolution så att alla testare slutar gissa på bärbara datorer. Vi måste skriva SELECT och se direkt att det går långsamt. Sluta vänta på att DBA ska berätta om det. Här är huvudmålet. Och jag tror att vi alla kommer att komma fram till detta. Och vi gör denna sak för alla att ha. Därför ZFS, eftersom det kommer att vara tillgängligt överallt. Tack till communityn för att ha löst problem och för att det finns en öppen källkodslicens etc. *

Hälsningar! Tack för rapporten! Jag heter Maxim. Vi har hanterat samma frågor. De bestämde sig själva. Hur delar du resurser mellan dessa kloner? Varje klon kan göra sin egen sak vid varje given tidpunkt: en testar en sak, en annan en annan, någon bygger ett index, någon har ett tungt jobb. Och om du fortfarande kan dividera med CPU, sedan med IO, hur delar du? Detta är den första frågan.

Och den andra frågan handlar om läktarnas olikheter. Låt oss säga att jag har ZFS här och allt är coolt, men klienten på prod har inte ZFS, utan ext4 till exempel. Hur i det här fallet?

Frågorna är mycket bra. Jag nämnde det här problemet lite med det faktum att vi delar resurser. Och lösningen är denna. Föreställ dig att du testar på iscensättning. Man kan också ha en sådan situation samtidigt som någon ger ett lass, någon annan. Och som ett resultat ser du obegripliga mätvärden. Även samma problem kan vara med prod. När du vill kontrollera någon begäran och se att det är något problem med det - det fungerar långsamt, då låg faktiskt problemet inte i förfrågan, utan i det faktum att det finns någon form av parallell belastning.

Och därför är det här viktigt att fokusera på vad planen kommer att vara, vilka steg vi kommer att ta i planen och hur mycket data vi kommer att samla in för detta. Det faktum att våra diskar till exempel kommer att laddas med något, det kommer specifikt att påverka timingen. Men vi kan uppskatta hur laddad denna begäran är utifrån mängden data. Det är inte så viktigt att det samtidigt blir någon form av avrättning.

Jag har två frågor. Det här är väldigt coola grejer. Har det förekommit fall där produktionsdata är kritiska, till exempel kreditkortsnummer? Finns det redan något klart eller är det en separat uppgift? Och den andra frågan - finns det något liknande för MySQL?

Om uppgifterna. Vi kommer att göra förvirring tills vi gör det. Men om du distribuerar exakt Joe, om du inte ger åtkomst till utvecklare, så finns det ingen tillgång till data. Varför? För att Joe inte visar data. Det visar bara mätvärden, planer och det är allt. Detta gjordes med flit, eftersom detta är ett av kraven från vår kund. De ville kunna optimera utan att ge alla tillgång.

Om MySQL. Detta system kan användas för allt som lagrar tillstånd på disk. Och eftersom vi håller på med Postgres så gör vi nu all automatisering för Postgres först och främst. Vi vill automatisera att hämta data från en säkerhetskopia. Vi konfigurerar Postgres korrekt. Vi vet hur man får planer att matcha osv.

Men eftersom systemet är utbyggbart kan det även användas för MySQL. Och det finns sådana exempel. Yandex har en liknande sak, men de publicerar den inte någonstans. De använder det i Yandex.Metrica. Och det finns bara en historia om MySQL. Men teknikerna är desamma, ZFS.

Tack för rapporten! Jag har också ett par frågor. Du nämnde att kloning kan användas för analyser, till exempel för att bygga ytterligare index där. Kan du berätta lite mer om hur det fungerar?

Och jag kommer omedelbart att ställa den andra frågan om likheten mellan montrarna, likheten mellan planerna. Planen beror också på den statistik som samlas in av Postgres. Hur löser du detta problem?

Enligt analysen finns det inga specifika fall, eftersom vi inte har använt det ännu, men det finns en sådan möjlighet. Om vi ​​pratar om index, tänk dig då att en fråga jagar en tabell med hundratals miljoner poster och en kolumn som vanligtvis inte är indexerad i prod. Och vi vill räkna ut lite data där. Om denna förfrågan skickas till prod, så finns det en möjlighet att det blir enkelt på prod, eftersom förfrågan kommer att behandlas där i en minut.

Ok, låt oss göra en tunn klon som inte är hemsk att stoppa i några minuter. Och för att göra det bekvämare att läsa analyserna kommer vi att lägga till index för de kolumner där vi är intresserade av data.

Kommer indexet att skapas varje gång?

Du kan göra det så att vi rör vid data, gör ögonblicksbilder, sedan kommer vi att återhämta oss från denna ögonblicksbild och köra nya förfrågningar. Det vill säga, du kan göra det så att du kan skapa nya kloner med redan anbringade index.

När det gäller frågan om statistik, om vi återställer från en säkerhetskopia, om vi replikerar, kommer vår statistik att vara exakt densamma. Eftersom vi har hela den fysiska datastrukturen, det vill säga, vi kommer att ta med data som den är med alla statistikmått också.

Här är ett annat problem. Om du använder en molnlösning så är bara logiska dumpar tillgängliga där, eftersom Google, Amazon inte tillåter dig att ta en fysisk kopia. Det kommer att bli ett problem.

Tack för rapporten. Det fanns två bra frågor här om MySQL och resursdelning. Men i själva verket beror allt på att detta inte är ett ämne för specifik DBMS, utan om filsystemet som helhet. Och följaktligen bör frågorna med resursdelning också lösas därifrån, inte i slutet av att det är Postgres, utan i filsystemet, på servern, till exempel.

Min fråga är lite annorlunda. Det är närmare den flerskiktiga databasen, där det finns flera lager. Till exempel sätter vi upp en tio terabyte bilduppdatering, vi replikerar. Och vi använder specifikt den här lösningen för databaser. Replikering pågår, data uppdateras. Det är 100 anställda som arbetar parallellt, som hela tiden lanserar dessa olika skott. Vad ska man göra? Hur försäkrar man sig om att det inte finns någon konflikt, att de startade en, och sedan ändrades filsystemet, och alla dessa bilder försvann?

De kommer inte att gå eftersom det är så ZFS fungerar. Vi kan hålla separat i en tråd filsystemändringarna som kommer på grund av replikering. Och behåll klonerna som utvecklare använder på äldre versioner av data. Och det fungerar för oss, allt är i sin ordning med detta.

Det visar sig att uppdateringen kommer att ske som ett extra lager, och alla nya bilder kommer att gå redan, baserat på detta lager, eller hur?

Från tidigare lager som var från tidigare replikeringar.

De tidigare lagren kommer att falla av, men de kommer att referera till det gamla lagret, och kommer de att ta nya bilder från det senaste lagret som togs emot i uppdateringen?

I allmänhet, ja.

Då som en konsekvens kommer vi att ha upp till ett fikon av lager. Och med tiden kommer de att behöva komprimeras?

Ja allt stämmer. Det finns något fönster. Vi håller ögonblicksbilder varje vecka. Det beror på vilken resurs du har. Om du har möjlighet att lagra mycket data kan du lagra ögonblicksbilder under lång tid. De kommer inte att försvinna av sig själva. Det kommer inte att finnas någon datakorruption. Om ögonblicksbilderna är föråldrade, som det verkar för oss, det vill säga det beror på policyn i företaget, så kan vi helt enkelt ta bort dem och frigöra utrymme.

Hej, tack för rapporten! Fråga om Joe. Du sa att kunden inte ville ge alla tillgång till datan. Strängt taget, om en person har resultatet av Explain Analyze, kan han titta på data.

Det är så. Till exempel kan vi skriva: "SELECT FROM WHERE email = to that". Det vill säga, vi kommer inte att se själva datan, men vi kan se några indirekta tecken. Detta måste förstås. Men å andra sidan finns allt där. Vi har en loggrevision, vi har koll på andra kollegor som också ser vad utvecklarna gör. Och om någon försöker göra detta, kommer säkerhetstjänsten att komma till dem och arbeta med den här frågan.

God eftermiddag Tack för rapporten! Jag har en kort fråga. Om företaget inte använder Slack, finns det någon bindning till det nu, eller är det möjligt för utvecklare att distribuera instanser för att koppla en testapplikation till databaserna?

Nu finns det en länk till Slack, det vill säga det finns ingen annan budbärare, men jag vill verkligen göra stöd för andra budbärare också. Vad kan du göra? Du kan distribuera DB Lab utan Joe, gå med hjälp av REST API eller med hjälp av vår plattform och skapa kloner och ansluta till PSQL. Men detta kan göras om du är redo att ge dina utvecklare tillgång till data, eftersom det inte längre kommer att finnas någon skärm.

Jag behöver inte det här lagret, men jag behöver en sådan möjlighet.

Då ja, det går att göra.

Källa: will.com