DBA bot Joe. Anatoly Stansler (Postgres.ai)

Ako backendový vývojár chápe, že SQL dotaz bude dobre fungovať na „produkte“? Vo veľkých alebo rýchlo rastúcich spoločnostiach nemá každý prístup k „produktu“. A s prístupom nie je možné bezbolestne skontrolovať všetky požiadavky a vytvorenie kópie databázy často trvá hodiny. Na vyriešenie týchto problémov sme vytvorili umelého DBA - Joe. Bol už úspešne implementovaný vo viacerých spoločnostiach a pomáha viac ako desiatke vývojárov.

Video:

Ahojte všetci! Volám sa Anatolij Stansler. Pracujem vo firme postgres.ai. Zaviazali sme sa urýchliť proces vývoja odstránením oneskorení spojených s prácou Postgres od vývojárov, DBA a QA.

Máme skvelých klientov a dnes bude časť reportáže venovaná prípadom, s ktorými sme sa stretli pri práci s nimi. Budem hovoriť o tom, ako sme im pomohli vyriešiť dosť vážne problémy.

Keď vyvíjame a robíme zložité migrácie s vysokou záťažou, kladieme si otázku: „Rozbehne sa táto migrácia?“. Využívame recenziu, využívame poznatky skúsenejších kolegov, DBA odborníkov. A môžu povedať, či to poletí alebo nie.

Ale možno by bolo lepšie, keby sme si to mohli sami otestovať na kópiách v plnej veľkosti. A dnes si povieme len to, aké sú teraz prístupy k testovaniu a ako sa to dá robiť lepšie a s akými nástrojmi. Povieme si aj o výhodách a nevýhodách takýchto prístupov a o tom, čo tu môžeme opraviť.

Kto kedy robil indexy priamo na produkte alebo robil nejaké zmeny? Pomerne málo. A pre koho to viedlo k tomu, že sa stratili údaje alebo došlo k výpadkom? Potom poznáte túto bolesť. Vďaka Bohu, že existujú zálohy.

Prvým prístupom je testovanie v prod. Alebo, keď vývojár sedí na lokálnom počítači, má testovacie dáta, existuje nejaký obmedzený výber. A prejdeme na prod, a dostaneme túto situáciu.

Bolí to, je to drahé. Asi je lepšie nie.

A aký je najlepší spôsob, ako to urobiť?

Vezmime si inscenáciu a vyberieme tam nejakú časť produktu. Alebo v najlepšom prípade vezmime skutočný produkt, všetky údaje. A potom, čo sme to vyvinuli lokálne, dodatočne skontrolujeme inscenáciu.

To nám umožní odstrániť niektoré chyby, t. j. zabrániť tomu, aby boli na prod.

Aké sú problémy?

• Problém je, že túto inscenáciu zdieľame s kolegami. A veľmi často sa stáva, že urobíte nejakú zmenu, bam - a nie sú žiadne údaje, práca je fuč. Staging bol multi-terabajtový. A musíte dlho čakať, kým sa znova zdvihne. A rozhodneme sa to dokončiť zajtra. To je všetko, máme vývoj.
• A, samozrejme, máme tam veľa kolegov, veľa tímov. A to sa musí robiť ručne. A to je nepohodlné.

A stojí za to povedať, že máme len jeden pokus, jeden záber, ak chceme urobiť nejaké zmeny v databáze, dotknúť sa údajov, zmeniť štruktúru. A ak sa niečo pokazilo, ak došlo k chybe pri migrácii, potom sa rýchlo nevrátime späť.

Je to lepšie ako predchádzajúci prístup, ale stále existuje vysoká pravdepodobnosť, že do výroby pôjde nejaký druh chyby.

Čo nám bráni poskytnúť každému vývojárovi skúšobnú verziu, kópiu v plnej veľkosti? Myslím, že je jasné, čo stojí v ceste.

Kto má databázu väčšiu ako terabajt? Viac ako polovica izby.

A je jasné, že držať stroje pre každého vývojára, keď je taká veľká produkcia, je veľmi drahé a navyše to trvá dlho.

Máme klientov, ktorí si uvedomili, že je veľmi dôležité testovať všetky zmeny na kópiách v plnej veľkosti, ale ich databáza je menšia ako terabajt a nie sú žiadne zdroje na udržiavanie testovacej stolice pre každého vývojára. Preto si musia stiahnuť výpisy lokálne do svojho počítača a otestovať ich týmto spôsobom. Trvá to veľa času.

Aj keď to robíte v rámci infraštruktúry, sťahovanie jedného terabajtu dát za hodinu je už veľmi dobré. Používajú ale logické výpisy, sťahujú lokálne z cloudu. Pre nich je rýchlosť približne 200 gigabajtov za hodinu. A stále trvá nejaký čas, kým sa otočí z logického výpisu, zroluje indexy atď.

Ale používajú tento prístup, pretože im umožňuje udržať produkt spoľahlivý.

Čo tu môžeme robiť? Urobme testovacie lavice lacnými a doprajme každému vývojárovi vlastnú testovaciu lavicu.

A toto je možné.

A v tomto prístupe, keď robíme tenké klony pre každého vývojára, môžeme to zdieľať na jednom stroji. Ak máte napríklad 10TB databázu a chcete ju dať 10 vývojárom, nemusíte mať databázy XNUMX x XNUMXTB. Potrebujete iba jeden stroj na vytváranie tenkých izolovaných kópií pre každého vývojára pomocou jedného stroja. O niečo neskôr vám poviem, ako to funguje.

Reálny príklad:

• DB - 4,5 terabajtov.

• Nezávislé kópie môžeme získať za 30 sekúnd.

Nemusíte čakať na skúšobný stojan a závisieť od toho, aký veľký je. Môžete to získať za pár sekúnd. Pôjde o úplne izolované prostredia, ktoré však medzi sebou zdieľajú dáta.

Toto je skvelé. Tu hovoríme o mágii a paralelnom vesmíre.

V našom prípade to funguje pomocou systému OpenZFS.

OpenZFS je súborový systém kopírovania pri zápise, ktorý podporuje snímky a klony hneď po vybalení. Je spoľahlivý a škálovateľný. Je veľmi ľahko ovládateľná. Dá sa nasadiť doslova v dvoch tímoch.

Existujú aj ďalšie možnosti:

• lvm,

• Storage (napríklad Pure Storage).

Databázové laboratórium, o ktorom hovorím, je modulárne. Dá sa implementovať pomocou týchto možností. Ale zatiaľ sme sa zamerali na OpenZFS, pretože problémy boli konkrétne s LVM.

Ako to funguje? Namiesto toho, aby sme údaje prepisovali pri každej zmene, uložíme ich jednoduchým označením, že tieto nové údaje pochádzajú z nového bodu v čase, z novej snímky.

A v budúcnosti, keď sa chceme vrátiť späť alebo chceme vytvoriť nový klon z nejakej staršej verzie, povieme len: "OK, dajte nám tieto bloky údajov, ktoré sú takto označené."

A tento používateľ bude pracovať s takýmto súborom údajov. Postupne ich bude meniť, robiť si vlastné momentky.

A budeme vetviť. Každý vývojár v našom prípade bude mať možnosť mať svoj vlastný klon, ktorý upraví, a zdieľané dáta budú zdieľané medzi všetkými.

Ak chcete nasadiť takýto systém doma, musíte vyriešiť dva problémy:

• Prvým je zdroj údajov, odkiaľ ich budete brať. Môžete nastaviť replikáciu s produkciou. Dúfam, že už môžete použiť zálohy, ktoré ste nakonfigurovali. WAL-E, WAL-G alebo Barman. A aj keď používate nejaké cloudové riešenie, ako je RDS alebo Cloud SQL, môžete použiť logické výpisy. Stále vám však odporúčame používať zálohy, pretože s týmto prístupom zachováte aj fyzickú štruktúru súborov, čo vám umožní byť ešte bližšie k metrikám, ktoré by ste videli vo výrobe, aby ste zachytili existujúce problémy.

• Druhým je miesto, kde chcete hostiť databázové laboratórium. Môže to byť Cloud, môže to byť On-premise. Tu je dôležité povedať, že ZFS podporuje kompresiu dát. A robí to celkom dobre.

Predstavte si, že každému takémuto klonu v závislosti od operácií, ktoré so základňou robíme, vyrastie nejaký ten dev. Na to bude potrebovať priestor aj dev. Ale vzhľadom na to, že sme zobrali základ 4,5 terabajtu, ZFS to skomprimuje na 3,5 terabajtu. To sa môže líšiť v závislosti od nastavení. A ešte máme priestor pre dev.

Takýto systém môže byť použitý v rôznych prípadoch.

• Sú to vývojári, DBA pre overovanie dotazov, pre optimalizáciu.

• Toto možno použiť pri testovaní kvality na testovanie konkrétnej migrácie predtým, ako ju spustíme do prod. A tiež môžeme vytvoriť špeciálne prostredia pre QA s reálnymi dátami, kde môžu testovať nové funkcie. A namiesto hodín čakania to bude trvať niekoľko sekúnd a v niektorých iných prípadoch, keď sa nepoužívajú tenké kópie, možno aj dni.

• A ďalší prípad. Ak spoločnosť nemá nastavený analytický systém, môžeme izolovať tenký klon produktovej základne a dať ho na dlhé dopyty alebo špeciálne indexy, ktoré sa dajú použiť v analytike.

S týmto prístupom:

1. Nízka pravdepodobnosť chýb na „produkte“, pretože všetky zmeny sme testovali na dátach v plnej veľkosti.

2. Máme kultúru testovania, pretože teraz nemusíte čakať hodiny na svoj vlastný stojan.

3. A neexistuje žiadna bariéra, žiadne čakanie medzi testami. V skutočnosti môžete ísť a skontrolovať. A takto to bude lepšie, keď urýchlime vývoj.

• Bude menej refaktoringu. Menej chýb skončí v prod. Neskôr ich budeme refaktorovať menej.

• Dokážeme zvrátiť nezvratné zmeny. Toto nie je štandardný prístup.

1. Je to výhodné, pretože zdieľame zdroje testovacích staníc.

Už dobré, ale čo by sa dalo ešte urýchliť?

Vďaka takémuto systému dokážeme výrazne znížiť hranicu pre vstup do takéhoto testovania.

Teraz je tu začarovaný kruh, keď sa vývojár, aby sa dostal k skutočným dátam v plnej veľkosti, musí stať odborníkom. S takýmto prístupom mu treba dôverovať.

Ale ako pestovať, ak tam nie je. Čo ak však máte k dispozícii len veľmi malý súbor testovacích údajov? Potom nezískate skutočný zážitok.

Ako sa dostať z tohto kruhu? Ako prvé rozhranie, vhodné pre vývojárov akejkoľvek úrovne, sme zvolili robota Slack. Ale môže to byť akékoľvek iné rozhranie.

Čo vám to umožňuje? Môžete vziať konkrétny dotaz a poslať ho na špeciálny kanál pre databázu. V priebehu niekoľkých sekúnd automaticky nasadíme tenký klon. Spustite túto požiadavku. Zhromažďujeme metriky a odporúčania. Ukážme si vizualizáciu. A potom tento klon zostane, aby sa tento dotaz dal nejako optimalizovať, pridať indexy atď.

A Slack nám tiež dáva príležitosti na spoluprácu hneď po vybalení. Keďže toto je len kanál, môžete začať diskutovať o tejto požiadavke priamo vo vlákne pre takúto žiadosť, pingnite svojich kolegov, DBA, ktorí sú vo vnútri spoločnosti.

Ale sú tu, samozrejme, problémy. Pretože toto je skutočný svet a my používame server, ktorý je hostiteľom mnohých klonov naraz, musíme skomprimovať množstvo pamäte a výkonu procesora dostupného pre klony.

Ale aby boli tieto testy hodnoverné, musíte tento problém nejako vyriešiť.

Je zrejmé, že dôležitým bodom sú rovnaké údaje. Ale už to máme. A chceme dosiahnuť rovnakú konfiguráciu. A môžeme dať takúto takmer identickú konfiguráciu.

Bolo by skvelé mať rovnaký hardvér ako vo výrobe, ale môže sa líšiť.

Pripomeňme si, ako Postgres pracuje s pamäťou. Máme dve kešky. Jeden zo súborového systému a jeden natívny Postgres, teda zdieľaná vyrovnávacia pamäť.

Je dôležité poznamenať, že zdieľaná vyrovnávacia pamäť sa prideľuje pri spustení Postgresu v závislosti od veľkosti, ktorú zadáte v konfigurácii.

A druhá vyrovnávacia pamäť využíva všetok dostupný priestor.

A keď urobíme niekoľko klonov na jednom stroji, ukáže sa, že postupne zaplníme pamäť. A v dobrom zmysle, zdieľaná vyrovnávacia pamäť predstavuje 25 % z celkového množstva pamäte, ktorá je k dispozícii v počítači.

A ukazuje sa, že ak tento parameter nezmeníme, tak na jednom stroji budeme môcť spustiť len 4 inštancie, teda 4 zo všetkých takýchto tenkých klonov. A to je, samozrejme, zlé, pretože ich chceme mať oveľa viac.

Ale na druhej strane, vyrovnávacia pamäť sa používa na vykonávanie dopytov na indexy, to znamená, že plán závisí od toho, aké veľké sú naše vyrovnávacie pamäte. A ak len vezmeme tento parameter a znížime ho, potom sa naše plány môžu veľa zmeniť.

Napríklad, ak máme veľkú vyrovnávaciu pamäť na prod, potom Postgres uprednostní použitie indexu. A ak nie, tak tu bude SeqScan. A aký by to malo zmysel, keby sa naše plány nezhodovali?

Tu sa ale dostávame k záveru, že v skutočnosti plán v Postgres nezávisí od konkrétnej veľkosti uvedenej v Shared Buffer v pláne, ale závisí od efektívnej_veľkosti_cache.

Effective_cache_size je odhadované množstvo vyrovnávacej pamäte, ktorá je nám k dispozícii, t. j. súčet vyrovnávacej pamäte vyrovnávacej pamäte a vyrovnávacej pamäte systému súborov. Toto je nastavené konfiguráciou. A táto pamäť nie je pridelená.

A vďaka tomuto parametru môžeme Postgres oklamať a povedať, že v skutočnosti máme k dispozícii veľa údajov, aj keď tieto údaje nemáme. A tak sa plány úplne zhodujú s výrobou.

To však môže ovplyvniť načasovanie. Dopyty optimalizujeme načasovaním, ale je dôležité, aby načasovanie záviselo od mnohých faktorov:

• Závisí to od záťaže, ktorá je momentálne na výr.

• Závisí to od vlastností samotného stroja.

A to je nepriamy parameter, ale v skutočnosti vieme optimalizovať presne podľa množstva dát, ktoré tento dotaz načíta, aby sme dostali výsledok.

A ak chcete, aby sa načasovanie priblížilo tomu, čo uvidíme v produkte, potom musíme vziať najpodobnejší hardvér a možno ešte viac, aby sa všetky klony zmestili. Ide však o kompromis, t. j. získate rovnaké plány, uvidíte, koľko údajov prečíta konkrétny dotaz a budete môcť usúdiť, či je tento dotaz dobrý (alebo migrácia) alebo zlý, treba ho ešte optimalizovať .

Poďme sa pozrieť na to, ako je Joe špecificky optimalizovaný.

Zoberme si požiadavku z reálneho systému. V tomto prípade je databáza 1 terabajt. A chceme spočítať počet nových príspevkov, ktoré mali viac ako 10 lajkov.

Píšeme správu na kanál, bol pre nás nasadený klon. A uvidíme, že takáto požiadavka bude dokončená za 2,5 minúty. Toto je prvá vec, ktorú si všimneme.

B Joe vám ukáže automatické odporúčania na základe plánu a metrík.

Uvidíme, že dotaz spracováva príliš veľa údajov na získanie relatívne malého počtu riadkov. A je potrebný nejaký špecializovaný index, pretože sme si všimli, že v dotaze je príliš veľa filtrovaných riadkov.

Pozrime sa bližšie na to, čo sa stalo. Skutočne vidíme, že sme prečítali takmer jeden a pol gigabajtu údajov z vyrovnávacej pamäte súborov alebo dokonca z disku. A to nie je dobré, pretože máme len 142 riadkov.

A zdalo by sa, že tu máme indexové skenovanie a malo by to fungovať rýchlo, ale keďže sme odfiltrovali príliš veľa riadkov (museli sme ich počítať), dopyt pomaly vyšiel.

A to sa stalo v pláne kvôli tomu, že podmienky v dotaze a podmienky v indexe sa čiastočne nezhodujú.

Skúsme index spresniť a uvidíme, ako sa potom zmení vykonanie dotazu.

Vytvorenie indexu trvalo pomerne dlho, ale teraz skontrolujeme dotaz a vidíme, že čas namiesto 2,5 minúty je len 156 milisekúnd, čo je dosť. A čítame len 6 megabajtov dát.

A teraz používame iba indexové skenovanie.

Ďalším dôležitým príbehom je, že chceme plán predstaviť nejakým zrozumiteľnejším spôsobom. Implementovali sme vizualizáciu pomocou Flame Graphs.

Toto je iná požiadavka, intenzívnejšia. Plamenné grafy vytvárame podľa dvoch parametrov: toto je množstvo údajov, ktoré konkrétny uzol započítal do plánu a načasovania, t. j. čas vykonania uzla.

Tu môžeme porovnávať konkrétne uzly medzi sebou. A bude jasné, ktorý z nich zaberie viac alebo menej, čo je pri iných spôsoboch vykresľovania zvyčajne ťažké.

Samozrejme, každý pozná stránku explain.depesz.com. Dobrou vlastnosťou tejto vizualizácie je, že si uložíme textový plán a tiež vložíme niektoré základné parametre do tabuľky, aby sme mohli triediť.

A vývojári, ktorí sa tejto téme ešte nevenovali, používajú aj stránku explain.depesz.com, pretože ľahšie zistia, ktoré metriky sú dôležité a ktoré nie.

Existuje nový prístup k vizualizácii – to je vysvetli.dalibo.com. Robia vizualizáciu stromu, ale je veľmi ťažké porovnávať uzly medzi sebou. Tu môžete štruktúru dobre pochopiť, ak však existuje veľká požiadavka, budete musieť posúvať tam a späť, ale aj možnosť.

spolupráce

A ako som povedal, Slack nám dáva príležitosť spolupracovať. Ak napríklad narazíme na zložitý dotaz, v ktorom nie je jasné, ako ho optimalizovať, môžeme si tento problém objasniť s kolegami vo vlákne v Slacku.

Zdá sa nám, že je dôležité testovať na dátach v plnej veľkosti. Na tento účel sme vytvorili nástroj Update Database Lab, ktorý je dostupný v open source. Môžete použiť aj Joe bota. Môžete si to vziať hneď teraz a implementovať to u vás. Sú tam k dispozícii všetci sprievodcovia.

Dôležité je tiež poznamenať, že samotné riešenie nie je revolučné, pretože existuje Delphix, ale ide o podnikové riešenie. Je úplne uzavretý, je veľmi drahý. Špeciálne sa špecializujeme na Postgres. Toto všetko sú produkty s otvoreným zdrojom. Pripoj sa k nám!

Tu končím. Ďakujem!

otázky

Ahoj! Ďakujeme za správu! Veľmi zaujímavé, najmä pre mňa, pretože pred časom som riešil približne rovnaký problém. A tak mám množstvo otázok. Dúfam, že dostanem aspoň časť.

Zaujímalo by ma, ako vypočítate miesto pre toto prostredie? Technológia znamená, že za určitých okolností môžu vaše klony narásť do maximálnej veľkosti. Zhruba povedané, ak máte desať terabajtovú databázu a 10 klonov, potom je ľahké simulovať situáciu, keď každý klon váži 10 jedinečných údajov. Ako vypočítate toto miesto, teda tú deltu, o ktorej ste hovorili, v ktorej budú tieto klony žiť?

Dobrá otázka. Tu je dôležité sledovať konkrétne klony. A ak má klon nejakú priveľkú zmenu, začne rásť, potom môžeme na to používateľa najskôr upozorniť, alebo tento klon okamžite zastaviť, aby nedošlo k poruche.

Áno, mám vnorenú otázku. To znamená, ako zabezpečíte životný cyklus týchto modulov? Máme tento problém a celý samostatný príbeh. Ako sa to stane?

Pre každý klon je nejaký TTL. V podstate máme fixný ttl.

Čo, ak nie tajomstvo?

1 hodina, t.j. nečinnosť - 1 hodina. Ak sa nepoužije, tak ho búchame. Nie je tu však žiadne prekvapenie, pretože klon dokážeme zdvihnúť za pár sekúnd. A ak to znova potrebujete, prosím.

Zaujíma ma aj výber technológií, pretože napríklad z toho či onoho dôvodu používame paralelne viacero metód. Prečo ZFS? Prečo ste nepoužili LVM? Spomenuli ste, že sa vyskytli problémy s LVM. Aké boli problémy? Podľa mňa je najoptimálnejšia možnosť s úložiskom, čo sa týka výkonu.

Aký je hlavný problém ZFS? Skutočnosť, že musíte bežať na rovnakom hostiteľovi, t.j. všetky inštancie budú žiť v rovnakom OS. A v prípade úložiska môžete pripojiť rôzne zariadenia. A úzkym miestom sú len tie bloky, ktoré sú na úložnom systéme. A zaujímavá je aj otázka výberu technológií. Prečo nie LVM?

Konkrétne môžeme diskutovať o LVM na stretnutí. O skladovaní - je to len drahé. Systém ZFS vieme implementovať kdekoľvek. Môžete ho nasadiť na váš počítač. Môžete si jednoducho stiahnuť úložisko a nasadiť ho. ZFS je nainštalovaný takmer všade, ak hovoríme o Linuxe. To znamená, že dostaneme veľmi flexibilné riešenie. A hneď po vybalení dáva ZFS veľa. Dá sa nahrať toľko dát, koľko chcete, pripojiť veľké množstvo diskov, nechýbajú snímky. A ako som povedal, je ľahké ho spravovať. To znamená, že používanie sa zdá byť veľmi príjemné. Je odskúšaný, má veľa rokov. Má veľmi veľkú komunitu, ktorá sa rozrastá. ZFS je veľmi spoľahlivé riešenie.

Nikolaj Samokhvalov: Môžem sa vyjadriť ďalej? Volám sa Nikolay, pracujeme spolu s Anatolijom. Súhlasím, že skladovanie je skvelé. A niektorí naši zákazníci majú Pure Storage atď.

Anatoly správne poznamenal, že sa zameriavame na modularitu. A v budúcnosti môžete implementovať jedno rozhranie - urobte snímku, vytvorte klon, zničte klon. Všetko je jednoduché. A skladovanie je v pohode, ak je.

Ale ZFS je k dispozícii každému. DelPhix je už dosť, majú 300 klientov. Z toho Fortune 100 má 50 klientov, t.j. sú zameraní na NASA atď. Je čas, aby si túto technológiu zaobstaral každý. A to je dôvod, prečo máme open source Core. Máme časť rozhrania, ktorá nie je open source. Toto je platforma, ktorú ukážeme. Chceme však, aby bola dostupná pre každého. Chceme urobiť revolúciu, aby všetci testeri prestali hádať na notebookoch. Musíme napísať SELECT a hneď vidíme, že je pomalý. Prestaňte čakať, kým vám o tom DBA povie. Tu je hlavný cieľ. A myslím si, že na to prídeme všetci. A robíme túto vec, aby ju mal každý. Preto ZFS, pretože bude dostupné všade. Ďakujeme komunite za riešenie problémov a za to, že máte licenciu na open source atď.*

Pozdravujem! Ďakujeme za správu! Moje meno je Maxim. Riešili sme rovnaké problémy. Rozhodli sa sami. Ako zdieľate zdroje medzi týmito klonmi? Každý klon môže v danom čase robiť svoju vlastnú vec: jeden testuje jednu vec, druhý inú, niekto vytvára index, niekto má náročnú prácu. A ak sa ešte dá deliť podľa CPU, tak podľa IO, ako sa delí? Toto je prvá otázka.

A druhá otázka sa týka odlišnosti stánkov. Povedzme, že tu mám ZFS a všetko je v pohode, ale klient na prod nemá ZFS, ale napríklad ext4. Ako v tomto prípade?

Otázky sú veľmi dobré. Tento problém som trochu spomenul s tým, že zdieľame zdroje. A riešenie je toto. Predstavte si, že testujete na inscenácii. Môžete mať aj takú situáciu v rovnakom čase, že niekto dá jeden náklad, niekto iný. A ako výsledok vidíte nepochopiteľné metriky. Dokonca rovnaký problém môže byť aj s prod. Keď chcete skontrolovať nejakú požiadavku a vidíte, že je s ňou nejaký problém - funguje pomaly, tak v skutočnosti problém nebol v požiadavke, ale v tom, že existuje nejaké paralelné zaťaženie.

A preto je dôležité zamerať sa na to, aký bude plán, aké kroky v pláne podnikneme a koľko údajov na to získame. To, že naše disky budú napríklad niečím zaťažené, to konkrétne ovplyvní časovanie. Môžeme však odhadnúť, ako je táto požiadavka zaťažená, podľa množstva údajov. Nie je až také dôležité, že zároveň dôjde k nejakej poprave.

mam dve otazky. Toto je veľmi cool vecička. Vyskytli sa prípady, keď sú výrobné údaje kritické, ako napríklad čísla kreditných kariet? Je už niečo pripravené alebo je to samostatná úloha? A druhá otázka - existuje niečo také pre MySQL?

O údajoch. Budeme robiť zahmlievanie, kým to neurobíme. Ale ak nasadíte presne Joe, ak nedáte prístup vývojárom, potom nie je prístup k údajom. prečo? Pretože Joe neukazuje údaje. Zobrazuje len metriky, plány a to je všetko. Bolo to urobené zámerne, pretože je to jedna z požiadaviek nášho klienta. Chceli byť schopní optimalizovať bez toho, aby mali všetci prístup.

O MySQL. Tento systém je možné použiť na čokoľvek, čo ukladá stav na disk. A keďže robíme Postgres, robíme teraz najprv všetku automatizáciu pre Postgres. Chceme automatizovať získavanie údajov zo zálohy. Postgres správne konfigurujeme. Vieme, ako zosúladiť plány atď.

Ale keďže je systém rozšíriteľný, dá sa použiť aj pre MySQL. A existujú také príklady. Yandex má podobnú vec, ale nikde to nezverejňuje. Používajú ho vo vnútri Yandex.Metrica. A je tu len príbeh o MySQL. Ale technológie sú rovnaké, ZFS.

Ďakujeme za správu! tiez mam par otazok. Spomenuli ste, že klonovanie sa dá použiť na analýzu, napríklad na vytvorenie ďalších indexov. Môžete povedať trochu viac o tom, ako to funguje?

A hneď položím druhú otázku o podobnosti stánkov, o podobnosti plánov. Plán závisí aj od štatistík, ktoré zbiera Postgres. Ako riešite tento problém?

Podľa analytikov neexistujú žiadne konkrétne prípady, pretože sme to ešte nevyužili, ale takáto príležitosť existuje. Ak hovoríme o indexoch, predstavte si, že dotaz prenasleduje tabuľku so stovkami miliónov záznamov a stĺpec, ktorý zvyčajne nie je indexovaný v prod. A tam chceme vypočítať nejaké údaje. Ak sa táto požiadavka odošle na prod, tak je tu možnosť, že na prod to bude jednoduché, pretože tam bude žiadosť spracovaná minútu.

Dobre, urobme tenký klon, ktorý nie je hrozné zastaviť na pár minút. A aby bolo čítanie analýzy pohodlnejšie, pridáme indexy pre tie stĺpce, v ktorých nás údaje zaujímajú.

Index sa vytvorí zakaždým?

Môžete to urobiť tak, že sa dotkneme údajov, urobíme snímky, potom sa z tejto snímky obnovíme a budeme riadiť nové požiadavky. To znamená, že to môžete urobiť tak, že môžete pestovať nové klony s už pripojenými indexmi.

Čo sa týka otázky o štatistikách, ak obnovíme zo zálohy, ak urobíme replikáciu, tak naše štatistiky budú úplne rovnaké. Pretože máme celú fyzickú dátovú štruktúru, to znamená, že dáta prinesieme tak, ako sú so všetkými štatistickými metrikami.

Tu je ďalší problém. Ak používate cloudové riešenie, sú tam dostupné iba logické výpisy, pretože Google, Amazon vám neumožňujú urobiť fyzickú kópiu. Nastane problém.

Ďakujem za správu. Boli tu dve dobré otázky o MySQL a zdieľaní zdrojov. Ale v skutočnosti to všetko súvisí s tým, že toto nie je téma konkrétneho DBMS, ale súborového systému ako celku. A preto by sa odtiaľ mali riešiť aj otázky zdieľania zdrojov, nie na konci, že ide o Postgres, ale napríklad v súborovom systéme, na serveri.

Moja otázka je trochu iná. Je bližšie k viacvrstvovej databáze, kde je niekoľko vrstiev. Napríklad sme nastavili desaťterabajtovú aktualizáciu obrazu, replikujeme. A toto riešenie používame špeciálne pre databázy. Prebieha replikácia, údaje sa aktualizujú. Paralelne pracuje 100 zamestnancov, ktorí neustále spúšťajú tieto rôzne zábery. Čo robiť? Ako sa uistiť, že nedochádza ku konfliktu, že ho spustili a potom sa zmenil systém súborov a všetky tieto obrázky zmizli?

Nepôjdu, pretože tak funguje ZFS. Zmeny súborového systému, ktoré prichádzajú v dôsledku replikácie, môžeme uchovávať oddelene v jednom vlákne. A ponechajte si klony, ktoré vývojári používajú na starších verziách údajov. A funguje nám to, s týmto je všetko v poriadku.

Ukazuje sa, že aktualizácia prebehne ako ďalšia vrstva a všetky nové obrázky už pôjdu na základe tejto vrstvy, však?

Z predchádzajúcich vrstiev, ktoré boli z predchádzajúcich replikácií.

Predchádzajúce vrstvy odpadnú, ale budú odkazovať na starú vrstvu a nasnímajú nové obrázky z poslednej vrstvy prijatej v aktualizácii?

Vo všeobecnosti áno.

Potom ako dôsledok budeme mať až fíg vrstiev. A časom ich bude treba stlačiť?

Áno, všetko je správne. Je tam nejaké okno. Uchovávame týždenné snímky. Záleží na tom, aký zdroj máte. Ak máte možnosť ukladať veľké množstvo údajov, môžete snímky ukladať na dlhú dobu. Samy od seba neodídu. Nedôjde k poškodeniu údajov. Ak sú snímky zastarané, ako sa nám zdá, t.j. závisí to od politiky vo firme, tak ich môžeme jednoducho vymazať a uvoľniť miesto.

Dobrý deň, ďakujeme za správu! Otázka o Joeovi. Povedali ste, že zákazník nechce dať všetkým prístup k údajom. Presne povedané, ak má osoba výsledok funkcie Explain Analyze, potom môže nahliadnuť do údajov.

Je to tak. Napríklad môžeme napísať: „SELECT FROM WHERE email = to that“. To znamená, že neuvidíme samotné údaje, ale môžeme vidieť niektoré nepriame znaky. Toto treba pochopiť. Ale na druhej strane je tam všetko. Máme log audit, máme kontrolu nad ostatnými kolegami, ktorí tiež vidia, čo vývojári robia. A ak sa o to niekto pokúsi, príde za ním bezpečnostná služba a bude na tomto probléme pracovať.

Dobrý deň Ďakujeme za správu! Mám krátku otázku. Ak spoločnosť nepoužíva Slack, existuje na to teraz nejaká väzba, alebo je možné, aby vývojári nasadili inštancie, aby mohli pripojiť testovaciu aplikáciu k databázam?

Teraz je tu odkaz na Slack, t.j. neexistuje žiadny iný messenger, ale naozaj chcem podporiť aj iných poslov. Čo môžeš urobiť? DB Lab môžete nasadiť bez Joea, ísť s pomocou REST API alebo s pomocou našej platformy a vytvárať klony a spájať sa s PSQL. Dá sa to však urobiť, ak ste pripravení poskytnúť svojim vývojárom prístup k údajom, pretože už nebude existovať žiadna obrazovka.

Nepotrebujem túto vrstvu, ale potrebujem takúto príležitosť.

Potom áno, dá sa to.

Zdroj: hab.com