DBA bot Joe. Anatoly Stansler (Postgres.ai)

Jak vývojář backendu pochopí, že dotaz SQL bude dobře fungovat na „produktu“? Ve velkých nebo rychle rostoucích společnostech nemá každý přístup k „produktu“. A s přístupem nelze všechny požadavky bezbolestně zkontrolovat a vytvoření kopie databáze často trvá hodiny. Abychom tyto problémy vyřešili, vytvořili jsme umělého DBA - Joe. Byl již úspěšně implementován v několika společnostech a pomáhá více než desítce vývojářů.

Video:

Ahoj všichni! Jmenuji se Anatoly Stansler. Pracuji pro společnost postgres.ai. Zavázali jsme se urychlit proces vývoje odstraněním zpoždění spojených s prací Postgres od vývojářů, DBA a QA.

Máme skvělé klienty a dnes bude část reportáže věnována případům, se kterými jsme se při práci s nimi setkali. Budu mluvit o tom, jak jsme jim pomohli vyřešit docela vážné problémy.

Když vyvíjíme a provádíme komplexní migrace s vysokým zatížením, položíme si otázku: „Rozjede se tato migrace?“. Využíváme review, využíváme znalostí zkušenějších kolegů, DBA odborníků. A mohou říct, jestli to poletí nebo ne.

Ale možná by bylo lepší, kdybychom si to mohli sami vyzkoušet na kopiích plné velikosti. A dnes si povíme jen to, jaké přístupy k testování jsou nyní a jak to lze dělat lépe a s jakými nástroji. Budeme také mluvit o výhodách a nevýhodách takových přístupů a o tom, co zde můžeme opravit.

Kdo kdy dělal indexy přímo na produktu nebo provedl nějaké změny? Docela málo. A pro koho to vedlo ke ztrátě dat nebo výpadkům? Pak tu bolest znáte. Díky bohu, že existují zálohy.

Prvním přístupem je testování v prod. Nebo když vývojář sedí na místním stroji, má testovací data, je tam nějaký omezený výběr. A vyrazíme na prod, a dostaneme tuto situaci.

Bolí to, je to drahé. Asi bude nejlepší ne.

A jaký je nejlepší způsob, jak to udělat?

Vezměme si staging a vybereme tam nějakou část produktu. Nebo v nejlepším případě vezměme skutečný produkt, všechna data. A poté, co jsme jej vyvinuli lokálně, dodatečně zkontrolujeme staging.

To nám umožní odstranit některé chyby, tj. zabránit tomu, aby byly na prod.

jaké jsou problémy?

• Problém je, že tuto inscenaci sdílíme s kolegy. A velmi často se stává, že uděláte nějakou změnu, bam - a nejsou data, práce je fuč. Staging byl multiterabajtový. A musíte dlouho čekat, než se zase zvedne. A rozhodneme se to dokončit zítra. To je vše, máme vývoj.
• A samozřejmě tam máme mnoho kolegů, mnoho týmů. A to se musí dělat ručně. A to je nepohodlné.

A stojí za to říci, že máme jen jeden pokus, jeden výstřel, pokud chceme provést nějaké změny v databázi, osahat data, změnit strukturu. A pokud se něco pokazilo, pokud došlo k chybě při migraci, pak se rychle nevrátíme.

To je lepší než předchozí přístup, ale stále existuje vysoká pravděpodobnost, že se do výroby dostane nějaká chyba.

Co nám brání dát každému vývojáři testovací lavici, kopii v plné velikosti? Myslím, že je jasné, co stojí v cestě.

Kdo má databázi větší než terabajt? Více než polovina místnosti.

A je jasné, že držet stroje pro každého vývojáře, když je tak velká produkce, je velmi drahé a navíc to trvá dlouho.

Máme klienty, kteří si uvědomili, že je velmi důležité testovat všechny změny na kopiích v plné velikosti, ale jejich databáze je menší než terabajt a nejsou žádné prostředky na to, aby pro každého vývojáře bylo možné udržovat testovací stolici. Proto si musí výpisy stáhnout lokálně do svého počítače a testovat tímto způsobem. Zabere to spoustu času.

I když to děláte uvnitř infrastruktury, pak stahování jednoho terabajtu dat za hodinu je už velmi dobré. Používají ale logické výpisy, stahují se lokálně z cloudu. U nich je rychlost asi 200 gigabajtů za hodinu. A ještě chvíli trvá, než se otočí z logického výpisu, srolují indexy atd.

Ale používají tento přístup, protože jim umožňuje udržet produkt spolehlivý.

Co tady můžeme dělat? Udělejme testovací lavice levně a dopřejme každému vývojáři vlastní testovací lavici.

A to je možné.

A v tomto přístupu, když děláme tenké klony pro každého vývojáře, můžeme to sdílet na jednom počítači. Pokud máte například 10TB databázi a chcete ji dát 10 vývojářům, nemusíte mít databáze XNUMX x XNUMXTB. K vytváření tenkých izolovaných kopií pro každého vývojáře pomocí jednoho počítače potřebujete pouze jeden počítač. Jak to funguje, vám řeknu o něco později.

Reálný příklad:

• DB - 4,5 terabajtů.

• Nezávislé kopie můžeme získat za 30 sekund.

Nemusíte čekat na zkušební stanoviště a záviset na tom, jak je velký. Můžete to získat během několika sekund. Půjde o zcela izolovaná prostředí, která však mezi sebou sdílejí data.

To je skvělé. Zde mluvíme o magii a paralelním vesmíru.

V našem případě to funguje pomocí systému OpenZFS.

OpenZFS je souborový systém kopírování při zápisu, který podporuje snímky a klony ihned po vybalení. Je spolehlivý a škálovatelný. Je velmi snadno ovladatelná. Dá se nasadit doslova ve dvou týmech.

Existují další možnosti:

• lvm,

• Úložiště (například Pure Storage).

Databázová laboratoř, o které mluvím, je modulární. Lze implementovat pomocí těchto možností. Ale prozatím jsme se zaměřili na OpenZFS, protože tam byly problémy konkrétně s LVM.

Jak to funguje? Místo abychom data přepisovali pokaždé, když je změníme, uložíme je jednoduchým označením, že tato nová data jsou z nového okamžiku, nového snímku.

A v budoucnu, když se budeme chtít vrátit zpět nebo budeme chtít vytvořit nový klon z nějaké starší verze, řekneme jen: "OK, dejte nám tyto bloky dat, které jsou takto označené."

A tento uživatel bude s takovým souborem dat pracovat. Postupně je bude měnit, dělat si vlastní momentky.

A budeme větvit. Každý vývojář v našem případě bude mít možnost mít svůj vlastní klon, který upraví, a data, která budou sdílena, budou sdílet všichni.

Chcete-li takový systém nasadit doma, musíte vyřešit dva problémy:

• První je zdroj dat, odkud je budete brát. Můžete nastavit replikaci s výrobou. Doufám, že již můžete použít zálohy, které jste nakonfigurovali. WAL-E, WAL-G nebo Barman. A i když používáte nějaké cloudové řešení, jako je RDS nebo Cloud SQL, můžete použít logické výpisy. Stále vám ale doporučujeme používat zálohy, protože s tímto přístupem si zachováte i fyzickou strukturu souborů, což vám umožní být ještě blíže metrikám, které byste viděli ve výrobě, abyste zachytili ty existující problémy.

• Druhým je místo, kde chcete hostit databázovou laboratoř. Může to být Cloud, může to být On-premise. Zde je důležité říci, že ZFS podporuje kompresi dat. A dělá to docela dobře.

Představte si, že každému takovému klonu v závislosti na operacích, které se základnou provádíme, vyroste nějaký ten dev. K tomu bude dev také potřebovat prostor. Ale vzhledem k tomu, že jsme vzali základ 4,5 terabajtu, ZFS to zkomprimuje na 3,5 terabajtu. To se může lišit v závislosti na nastavení. A stále máme prostor pro vývoj.

Takový systém lze použít pro různé případy.

• To jsou vývojáři, DBA pro ověřování dotazů, pro optimalizaci.

• To lze použít při testování kvality k otestování konkrétní migrace předtím, než ji zavedeme do prod. A také můžeme vytvořit speciální prostředí pro QA s reálnými daty, kde mohou testovat nové funkce. A místo hodin čekání to zabere sekundy a v některých jiných případech, kdy se tenké kopie nepoužívají, možná i dny.

• A další případ. Pokud společnost nemá nastaven analytický systém, můžeme izolovat tenký klon produktové základny a dát jej na dlouhé dotazy nebo speciální indexy, které lze použít v analytice.

S tímto přístupem:

1. Nízká pravděpodobnost chyb na "produ", protože jsme všechny změny testovali na datech v plné velikosti.

2. Máme kulturu testování, protože nyní nemusíte čekat hodiny na svůj vlastní stojan.

3. A neexistuje žádná bariéra, žádné čekání mezi testy. Ve skutečnosti můžete jít a zkontrolovat. A bude to tak lepší, až urychlíme vývoj.

• Bude méně refaktoringu. Méně chyb skončí v prod. Později je budeme méně refaktorovat.

• Můžeme zvrátit nevratné změny. Toto není standardní přístup.

1. To je výhodné, protože sdílíme zdroje testovacích stolic.

Už dobré, ale co by se ještě dalo urychlit?

Díky takovému systému můžeme výrazně snížit práh pro zadání takového testování.

Nyní je tu začarovaný kruh, kdy se vývojář, aby získal přístup ke skutečným datům v plné velikosti, musí stát odborníkem. Takový přístup mu musí věřit.

Ale jak pěstovat, když tam není. Ale co když máte k dispozici jen velmi malý soubor testovacích dat? Pak nezískáte žádný skutečný zážitek.

Jak z tohoto kruhu ven? Jako první rozhraní, vhodné pro vývojáře jakékoli úrovně, jsme zvolili bota Slack. Ale může to být jakékoli jiné rozhraní.

Co vám to umožňuje? Můžete vzít konkrétní dotaz a poslat ho na speciální kanál pro databázi. Během několika sekund automaticky nasadíme tenký klon. Spusťte tento požadavek. Shromažďujeme metriky a doporučení. Ukažme si vizualizaci. A pak tento klon zůstane, aby se tento dotaz dal nějak optimalizovat, přidat indexy atp.

A také nám Slack dává příležitosti ke spolupráci hned po vybalení. Vzhledem k tomu, že se jedná pouze o kanál, můžete začít diskutovat o tomto požadavku přímo ve vlákně pro takový požadavek a pingnout své kolegy, DBA, kteří jsou uvnitř společnosti.

Ale jsou tu samozřejmě problémy. Protože toto je skutečný svět a my používáme server hostující mnoho klonů najednou, musíme komprimovat množství paměti a výkonu CPU, které mají klony k dispozici.

Ale aby byly tyto testy věrohodné, musíte tento problém nějak vyřešit.

Je jasné, že důležitým bodem jsou stejná data. Ale už to máme. A chceme dosáhnout stejné konfigurace. A můžeme dát takovou téměř identickou konfiguraci.

Bylo by skvělé mít stejný hardware jako ve výrobě, ale může se lišit.

Připomeňme si, jak Postgres pracuje s pamětí. Máme dvě keše. Jeden ze souborového systému a jeden nativní Postgres, tedy sdílená mezipaměť vyrovnávací paměti.

Je důležité si uvědomit, že sdílená mezipaměť se přiděluje při spuštění Postgresu v závislosti na velikosti, kterou zadáte v konfiguraci.

A druhá mezipaměť využívá veškerý dostupný prostor.

A když uděláme více klonů na jednom stroji, ukáže se, že postupně zaplňujeme paměť. A v dobrém slova smyslu je sdílená mezipaměť vyrovnávací paměti 25 % z celkového množství paměti, která je v počítači k dispozici.

A ukazuje se, že pokud tento parametr nezměníme, tak na jednom stroji budeme moci spustit pouze 4 instance, tedy celkem 4 tyto tenké klony. A to je samozřejmě špatně, protože jich chceme mít mnohem víc.

Ale na druhou stranu se Buffer Cache používá k provádění dotazů na indexy, to znamená, že plán závisí na tom, jak velké jsou naše cache. A pokud jen vezmeme tento parametr a snížíme ho, pak se naše plány mohou hodně změnit.

Pokud máme například velkou mezipaměť na prod, pak Postgres raději použije index. A pokud ne, tak tu bude SeqScan. A jaký by to mělo smysl, kdyby se naše plány neshodovaly?

Zde ale docházíme k závěru, že ve skutečnosti plán v Postgresu nezávisí na konkrétní velikosti uvedené ve Shared Buffer v plánu, záleží na efektivní_velikost_cache.

Effective_cache_size je odhadované množství mezipaměti, které máme k dispozici, tj. součet mezipaměti vyrovnávací paměti a mezipaměti systému souborů. Toto je nastaveno konfigurací. A tato paměť není přidělena.

A díky tomuto parametru můžeme Postgres oklamat tím, že ve skutečnosti máme k dispozici spoustu dat, i když tato data nemáme. A tak se plány zcela shodují s výrobou.

Ale to může ovlivnit načasování. Dotazy optimalizujeme načasováním, ale je důležité, aby načasování záviselo na mnoha faktorech:

• Záleží na zátěži, která je aktuálně na prod.

• Záleží na vlastnostech samotného stroje.

A to je nepřímý parametr, ale ve skutečnosti můžeme optimalizovat přesně podle množství dat, které tento dotaz načte, abychom dostali výsledek.

A pokud chcete, aby se načasování blížilo tomu, co uvidíme v prod, pak musíme vzít co nejpodobnější hardware a případně ještě více, aby všechny klony seděly. Jedná se ale o kompromis, tj. získáte stejné plány, uvidíte, kolik dat konkrétní dotaz přečte a budete moci usoudit, zda je tento dotaz dobrý (nebo migrace) nebo špatný, stále je třeba jej optimalizovat .

Pojďme se podívat, jak je Joe konkrétně optimalizován.

Vezměme požadavek z reálného systému. V tomto případě je databáze 1 terabajt. A my chceme spočítat počet nových příspěvků, které měly více než 10 lajků.

Píšeme zprávu na kanál, byl pro nás nasazen klon. A uvidíme, že takový požadavek bude dokončen za 2,5 minuty. To je první věc, které si všimneme.

B Joe vám ukáže automatická doporučení na základě plánu a metrik.

Uvidíme, že dotaz zpracovává příliš mnoho dat na to, aby získal relativně malý počet řádků. A je potřeba nějaký druh specializovaného indexu, protože jsme si všimli, že v dotazu je příliš mnoho filtrovaných řádků.

Podívejme se blíže na to, co se stalo. Skutečně vidíme, že jsme přečetli téměř jeden a půl gigabajtu dat ze souborové mezipaměti nebo dokonce z disku. A to není dobré, protože máme jen 142 řádků.

A zdálo by se, že zde máme indexové skenování a mělo to proběhnout rychle, ale protože jsme odfiltrovali příliš mnoho řádků (museli jsme je počítat), dotaz pomalu vyšel.

A to se v plánu stalo díky tomu, že podmínky v dotazu a podmínky v indexu částečně nesouhlasí.

Zkusme index zpřesnit a uvidíme, jak se poté změní provádění dotazu.

Vytvoření indexu trvalo poměrně dlouho, ale nyní kontrolujeme dotaz a vidíme, že čas místo 2,5 minuty je pouze 156 milisekund, což je dost dobré. A přečteme pouze 6 megabajtů dat.

A nyní používáme pouze indexové skenování.

Dalším důležitým příběhem je, že chceme plán představit nějakým srozumitelnějším způsobem. Implementovali jsme vizualizaci pomocí Flame Graphs.

To je jiný požadavek, intenzivnější. Plamenné grafy sestavujeme podle dvou parametrů: jedná se o množství dat, které konkrétní uzel počítal v plánu a načasování, tedy dobu provedení uzlu.

Zde můžeme porovnávat konkrétní uzly mezi sebou. A bude jasné, která z nich zabere více nebo méně, což je u jiných způsobů vykreslování většinou obtížné.

Samozřejmě, každý zná translate.depesz.com. Dobrou vlastností této vizualizace je, že si uložíme textový plán a také vložíme některé základní parametry do tabulky, abychom mohli třídit.

A vývojáři, kteří se do tohoto tématu ještě neponořili, používají i translate.depesz.com, protože snáze zjistí, které metriky jsou důležité a které ne.

Existuje nový přístup k vizualizaci – to je explain.dalibo.com. Dělají vizualizaci stromu, ale je velmi těžké porovnat uzly mezi sebou. Zde můžete dobře porozumět struktuře, ale pokud existuje velký požadavek, budete muset rolovat tam a zpět, ale také možnost.

Коллаборация

A jak jsem řekl, Slack nám dává příležitost ke spolupráci. Pokud například narazíme na složitý dotaz, u kterého není jasné, jak optimalizovat, můžeme si tento problém vyjasnit s kolegy ve vláknu ve Slacku.

Zdá se nám, že je důležité testovat na datech v plné velikosti. K tomu jsme vytvořili nástroj Update Database Lab, který je dostupný v open source. Můžete také použít Joe bota. Můžete si to vzít hned a implementovat to u vás. Jsou tam k dispozici všichni průvodci.

Důležité je také podotknout, že samotné řešení není převratné, protože existuje Delphix, ale jedná se o podnikové řešení. Je úplně uzavřený, je velmi drahý. Specializujeme se konkrétně na Postgres. Všechny tyto produkty jsou open source. Připoj se k nám!

Tady končím. Děkuji!

otázky

Ahoj! Díky za zprávu! Velmi zajímavé, zvláště pro mě, protože jsem před časem řešil přibližně stejný problém. A tak mám řadu otázek. Snad se dočkám alespoň části.

Zajímalo by mě, jak počítáte místo pro toto prostředí? Technologie znamená, že za určitých okolností mohou vaše klony dorůst do maximální velikosti. Zhruba řečeno, pokud máte desetiterabajtovou databázi a 10 klonů, pak je snadné nasimulovat situaci, kdy každý klon váží 10 unikátních dat. Jak vypočítáte toto místo, tedy tu deltu, o které jste mluvil, ve které budou tyto klony žít?

Dobrá otázka. Zde je důležité sledovat konkrétní klony. A pokud má klon nějakou příliš velkou změnu, začne růst, pak na to můžeme uživatele nejprve upozornit, nebo tento klon okamžitě zastavit, aby nedošlo k selhání.

Ano, mám vnořenou otázku. To znamená, jak zajistíte životní cyklus těchto modulů? Máme tento problém a celý samostatný příběh. Jak se to stane?

Pro každý klon je nějaký TTL. V podstatě máme fixní ttl.

Co, když to není tajemství?

1 hodina, tedy nečinnost - 1 hodina. Pokud se nepoužívá, tak s tím bouchneme. Ale není to žádné překvapení, protože klon můžeme vychovat během několika sekund. A pokud to budete znovu potřebovat, tak prosím.

Zajímá mě i výběr technologií, protože například z toho či onoho důvodu používáme více metod paralelně. Proč ZFS? Proč jsi nepoužil LVM? Zmínil jste, že byly problémy s LVM. Jaké byly problémy? Podle mě je nejoptimálnější varianta s úložištěm, co se výkonu týče.

Jaký je hlavní problém ZFS? Skutečnost, že musíte běžet na stejném hostiteli, tj. všechny instance budou žít ve stejném operačním systému. A v případě úložiště můžete připojit různá zařízení. A úzkým hrdlem jsou pouze ty bloky, které jsou na úložném systému. A zajímavá je otázka výběru technologií. Proč ne LVM?

Konkrétně o LVM můžeme diskutovat na setkání. O skladování - je to prostě drahé. Systém ZFS můžeme implementovat kdekoli. Můžete jej nasadit na svůj počítač. Úložiště si můžete jednoduše stáhnout a nasadit. ZFS je nainstalován téměř všude, pokud mluvíme o Linuxu. To znamená, že dostáváme velmi flexibilní řešení. A samotný ZFS dává hodně z krabice. Můžete nahrát tolik dat, kolik chcete, připojit velké množství disků, existují snapshoty. A jak jsem řekl, je snadné ho spravovat. To znamená, že se zdá velmi příjemné používat. Je vyzkoušený, je mu mnoho let. Má velmi velkou komunitu, která se rozrůstá. ZFS je velmi spolehlivé řešení.

Nikolaj Samokhvalov: Mohu se vyjádřit dále? Jmenuji se Nikolay, pracujeme společně s Anatolym. Souhlasím, že skladování je skvělé. A někteří naši zákazníci mají Pure Storage atd.

Anatoly správně poznamenal, že se zaměřujeme na modularitu. A v budoucnu můžete implementovat jedno rozhraní - pořídit snímek, vytvořit klon, zničit klon. Všechno je snadné. A skladování je v pohodě, pokud ano.

Ale ZFS je k dispozici všem. DelPhix už je dost, mají 300 klientů. Z toho Fortune 100 má 50 klientů, tj. míří na NASA atd. Je čas, aby si tuto technologii pořídil každý. A proto máme open source Core. Máme část rozhraní, která není open source. Toto je platforma, kterou si ukážeme. Ale chceme, aby byl přístupný všem. Chceme udělat revoluci, aby všichni testeři přestali u notebooků hádat. Musíme napsat SELECT a hned vidíme, že je pomalý. Přestaňte čekat, až vám o tom DBA řekne. Zde je hlavní cíl. A myslím, že na to přijdeme všichni. A děláme to pro každého. Proto ZFS, protože bude k dispozici všude. Děkujeme komunitě za vyřešení problémů a za to, že máte open source licenci atd.*

Pozdravy! Díky za zprávu! Jmenuji se Maxim. Řešili jsme stejné problémy. Rozhodli se sami. Jak sdílíte zdroje mezi těmito klony? Každý klon může v kteroukoli chvíli dělat svou vlastní věc: jeden testuje jednu věc, druhý jinou, někdo vytváří index, někdo má těžkou práci. A když ještě můžeš dělit podle CPU, tak podle IO, jak dělíš? Toto je první otázka.

A druhá otázka se týká nepodobnosti stánků. Řekněme, že zde mám ZFS a vše je v pohodě, ale klient na prod nemá ZFS, ale například ext4. Jak v tomto případě?

Otázky jsou velmi dobré. Tento problém jsem trochu zmínil s tím, že sdílíme zdroje. A řešení je toto. Představte si, že testujete na inscenaci. Můžete mít i takovou situaci zároveň, že někdo dá jednu zátěž, někdo jiný. A v důsledku toho vidíte nepochopitelné metriky. Dokonce stejný problém může být s prod. Když chcete zkontrolovat nějaký požadavek a vidíte, že je s ním nějaký problém - jde to pomalu, tak ve skutečnosti problém nebyl v požadavku, ale v tom, že je tam nějaká paralelní zátěž.

A proto je zde důležité zaměřit se na to, jaký bude plán, jaké kroky v plánu podnikneme a kolik dat k tomu získáme. To, že se nám budou něčím zatěžovat třeba disky, to konkrétně ovlivní časování. Ale můžeme odhadnout, jak je tento požadavek nabitý, podle množství dat. Není tak důležité, že zároveň dojde k nějaké exekuci.

Mám dvě otázky. To je velmi cool věc. Vyskytly se případy, kdy jsou kritická výrobní data, jako jsou čísla kreditních karet? Je už něco připraveno nebo je to samostatný úkol? A druhá otázka - existuje něco takového pro MySQL?

O datech. Budeme dělat mlžení, dokud to neuděláme. Ale pokud nasadíte přesně Joe, pokud nedáte přístup vývojářům, pak není přístup k datům. Proč? Protože Joe neukazuje data. Zobrazuje pouze metriky, plány a to je vše. Bylo to provedeno záměrně, protože je to jeden z požadavků našeho klienta. Chtěli mít možnost optimalizovat, aniž by měli všichni přístup.

O MySQL. Tento systém lze použít pro cokoli, co ukládá stav na disk. A protože děláme Postgres, děláme nyní nejprve veškerou automatizaci pro Postgres. Chceme automatizovat získávání dat ze zálohy. Postgres správně konfigurujeme. Víme, jak sladit plány atd.

Ale protože je systém rozšiřitelný, lze jej použít i pro MySQL. A takové příklady existují. Yandex má podobnou věc, ale nikde to nezveřejňuje. Používají to uvnitř Yandex.Metrica. A existuje jen příběh o MySQL. Ale technologie jsou stejné, ZFS.

Díky za zprávu! Mám také pár otázek. Zmínil jste, že klonování lze použít pro analýzu, například pro vytváření dalších indexů. Můžeš říct trochu víc o tom, jak to funguje?

A hned položím druhou otázku o podobnosti stánků, podobnosti plánů. Plán také závisí na statistikách shromážděných Postgresem. Jak tento problém vyřešíte?

Podle analytiků neexistují žádné konkrétní případy, protože jsme to ještě nevyužili, ale existuje taková příležitost. Pokud mluvíme o indexech, pak si představte, že dotaz pronásleduje tabulku se stovkami milionů záznamů a sloupec, který obvykle není indexován v prod. A tam chceme vypočítat nějaká data. Pokud se tento požadavek odešle na prod, tak je možnost, že na prod to bude jednoduché, protože tam bude požadavek minutu zpracován.

Dobře, udělejme tenký klon, u kterého není hrozné se na pár minut zastavit. A aby bylo čtení analytiky pohodlnější, přidáme indexy pro ty sloupce, ve kterých nás zajímají data.

Index bude vytvořen pokaždé?

Můžete to udělat tak, že se dotkneme dat, uděláme snímky, pak se z tohoto snímku zotavíme a budeme řídit nové požadavky. To znamená, že to můžete udělat tak, abyste mohli vychovávat nové klony s již připojenými indexy.

Pokud jde o otázku ohledně statistik, pokud obnovujeme ze zálohy, pokud provádíme replikaci, pak naše statistiky budou úplně stejné. Protože máme celou fyzickou strukturu dat, to znamená, že data přineseme tak, jak jsou se všemi metrikami statistik.

Zde je další problém. Pokud používáte cloudové řešení, pak jsou tam k dispozici pouze logické skládky, protože Google, Amazon vám neumožňují pořídit fyzickou kopii. Bude problém.

Díky za zprávu. Byly zde dvě dobré otázky týkající se MySQL a sdílení zdrojů. Ale ve skutečnosti to všechno souvisí s tím, že to není téma konkrétního DBMS, ale souborového systému jako celku. A v souladu s tím by odtud měly být také vyřešeny otázky sdílení zdrojů, nikoli na konci, že jde o Postgres, ale například v systému souborů, na serveru.

Moje otázka je trochu jiná. Blíží se vícevrstvé databázi, kde je více vrstev. Například jsme nastavili desetiterabajtovou aktualizaci obrazu, replikujeme. A toto řešení používáme speciálně pro databáze. Replikace probíhá, data se aktualizují. Paralelně zde pracuje 100 zaměstnanců, kteří neustále spouštějí tyto různé záběry. Co dělat? Jak se ujistit, že nedochází ke konfliktu, že jeden spustili a pak se změnil systém souborů a všechny tyto obrázky odešly?

Nepůjdou, protože tak funguje ZFS. Změny souborového systému, ke kterým dochází v důsledku replikace, můžeme uchovávat odděleně v jednom vláknu. A zachovat klony, které vývojáři používají na starších verzích dat. A nám to funguje, s tímto je vše v pořádku.

Ukazuje se, že aktualizace proběhne jako další vrstva a všechny nové obrázky již půjdou na základě této vrstvy, že?

Z předchozích vrstev, které byly z předchozích replikací.

Předchozí vrstvy odpadnou, ale budou odkazovat na starou vrstvu a převezmou nové obrázky z poslední vrstvy, která byla přijata v aktualizaci?

Obecně ano.

Pak jako důsledek budeme mít až obr vrstev. A časem je bude potřeba komprimovat?

Ano, vše je správně. Je tam nějaké okno. Uchováváme týdenní snímky. Záleží na tom, jaký zdroj máte. Pokud máte možnost ukládat velké množství dat, můžete snímky ukládat po dlouhou dobu. Sami neodejdou. Nedojde k poškození dat. Pokud jsou snapshoty zastaralé, jak se nám zdá, tedy záleží na politice ve firmě, tak je můžeme jednoduše smazat a uvolnit místo.

Dobrý den, děkujeme za zprávu! Otázka o Joeovi. Řekl jste, že zákazník nechtěl dát přístup k datům všem. Přesně řečeno, pokud má člověk výsledek Explain Analyze, může nahlédnout do dat.

Je to tak. Například můžeme napsat: "SELECT FROM WHERE email = to that". To znamená, že neuvidíme samotná data, ale můžeme vidět nějaké nepřímé znaky. Tomu je třeba rozumět. Ale na druhou stranu je tam všechno. Máme log audit, máme kontrolu nad ostatními kolegy, kteří také vidí, co vývojáři dělají. A pokud se o to někdo pokusí, pak za ním přijde bezpečnostní služba a bude na tomto problému pracovat.

Dobré odpoledne Díky za zprávu! mám krátkou otázku. Pokud společnost nepoužívá Slack, existuje na něj nyní nějaká vazba, nebo je možné, aby vývojáři nasadili instance za účelem připojení testovací aplikace k databázím?

Nyní je zde odkaz na Slack, tj. neexistuje žádný jiný messenger, ale opravdu chci podpořit i další messengery. Co můžeš udělat? DB Lab můžete nasadit bez Joea, jít s pomocí REST API nebo s pomocí naší platformy a vytvářet klony a propojovat se s PSQL. Ale to lze provést, pokud jste připraveni poskytnout svým vývojářům přístup k datům, protože již nebude žádná obrazovka.

Nepotřebuji tuto vrstvu, ale potřebuji takovou příležitost.

Pak ano, dá se to.

Zdroj: www.habr.com