SQL dotaz: defragmentace tabulky

SQL dotaz: defragmentace tabulky
« kdy: 05. 08. 2022, 09:33:06 »
SQL nerozumim a tak se ptam.

Velika tabulka kategorie je framentovana a je potreba udelat rebuild. Ale jak to vlastne funguje, slo by ten rebuilt udelat jen pro recordy mladsi nez zvolene datum?

Prijde mi nesmysl horkotezko vymazat miliardu nejstarsich zaznamu a potom delat rebuild.
« Poslední změna: 05. 08. 2022, 09:36:30 od pruzkumbojem »


Re:SQL dotaz: defragmentace tabulky
« Odpověď #1 kdy: 05. 08. 2022, 10:10:29 »
SQL je jazyk, ty se asi ptáš na nějakou databázi, ne?

Re:SQL dotaz: defragmentace tabulky
« Odpověď #2 kdy: 05. 08. 2022, 10:20:05 »
Ale jak to vlastne funguje, slo by ten rebuilt udelat jen pro recordy mladsi nez zvolene datum?
Rebuild znamená, že se vezme ta tabulka a záznamy uvnitř se porovnají podle clusterovaného indexu. (Protože clusterovaný index=tabulka.)

Ruku do ohně za to nedám, ale vzhledem k logice toho jak to funguje nepředpokádám, že je normálně možné rebuildnout jen část tabulky. (Snad možná pokud je tabulka rozdělená do víc částí, tak možná by šlo udělat rebuild tý jedný části. (Nebo možná pokud to datum by bylo součástní toho clusterovaného indexu, ale to u tabulky Kategorie nedává moc smysl.)

Prijde mi nesmysl horkotezko vymazat miliardu nejstarsich zaznamu a potom delat rebuild.
Co Vám na tom přijde nesmyslného?

Vymažete hromadu starých záznamů, čímž ale vzniknou v tabulce mezery, která jen zabírají místo. Přerovnat záznamy (=rebuild) naopak dává perfektní smysl.

Pokud Vás to utěší, tak některý databáze tuším umějí rebuildnout tabulku a nechat ji při tom přístupnou.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #3 kdy: 05. 08. 2022, 11:01:19 »
Ja to znam jako uzivatel, u MariaDB i MySQL rebuild nikdy neprerusil "pristupnost tabulky". Docasne tam vznikne druha tabulka a zapis se presmerovava. Proto je taky docasne potreba vice diskoveho prostoru, o velikosti defragmentovane tabulky.

Nezpochybnuji, ze kdyz promazu tabulku, tak vznikne defragmentace a musi se to defragmentovat. (naopak, bych chtel aby to provider delal casteji nez jednou za 5 let).

Protoze i diky historii neudrzby je reseni straslive pomale, nechci mazat miliardu radku a potom prosit o defragmentaci.
Chci preskocit ten mesic mazani a proste behem defragmentace zapomenout starsi radky.

A ptam se takhle blbe tady, protoze L1-3 support proste lze.


Prijde mi nesmysl horkotezko vymazat miliardu nejstarsich zaznamu a potom delat rebuild.
Co Vám na tom přijde nesmyslného?

Vymažete hromadu starých záznamů, čímž ale vzniknou v tabulce mezery, která jen zabírají místo. Přerovnat záznamy (=rebuild) naopak dává perfektní smysl.

Pokud Vás to utěší, tak některý databáze tuším umějí rebuildnout tabulku a nechat ji při tom přístupnou.

al.da

Re:SQL dotaz: defragmentace tabulky
« Odpověď #4 kdy: 05. 08. 2022, 18:16:21 »
Rad bych vedel, co si predstavujete pod slovem defragmentace? Ulozeni dat? nebo zmenu udaju ve sloupcich?
Se nedivim, ze support s Vami nechce nic mit :):):)


Re:SQL dotaz: defragmentace tabulky
« Odpověď #5 kdy: 05. 08. 2022, 18:55:33 »
haha, ja pouzivam jejich terminy.

BTW nezminil jsem mazani radku?
A ta definice je mi celkem u p****e, protoze jsem ptal na rebuild tabulky od jisteho radku, protoze ty predtim nechce ze strany klienta mazat..

Rad bych vedel, co si predstavujete pod slovem defragmentace? Ulozeni dat? nebo zmenu udaju ve sloupcich?
Se nedivim, ze support s Vami nechce nic mit :):):)

Re:SQL dotaz: defragmentace tabulky
« Odpověď #6 kdy: 05. 08. 2022, 22:09:12 »
Hádám, že někdy muže být levnější zkopírovat zajímavé záznamy do jiné tabulky, udělat truncate a pak zajímavá data nalít zpět (ale je to specielní případ - pokud se ponechá jen zlomek dat z ohromné tabulky).

Re:SQL dotaz: defragmentace tabulky
« Odpověď #7 kdy: 05. 08. 2022, 22:50:59 »
Budu optimista, takze doufam po smazani  5-6 TB zbude tak 2TB nejnovejsi recordu.

ono se to trochu zacyklilo, kdyz zakaznik rika, ze nemuze mazat protoze je to extremne pomaly, zatimco support rika je to pomaly, protoze nemazete. Plus teda zakaznik neco smazal a prekvapive velikost tabulky se nezmenila. A support rekl co... "nojono, je to fragmentovany"
A muj pohled na vec je, ze se plati 1+ milionu EUR rocne, ve smlouve neni nic o limitu velikosti tabulek a vendor na tu tabulku nesahl 7 let, co se na ti delaji miliardy zapisu a mazani.

A protoze se uz se supportem timhle zpusobem nechci dal bavit, lepsi CSAT nez 3 z 10 ode mne nedostanou, takze se jim holt kazi jejich krasny reporty. A najednou stredni management se mnou chce schuzky a ptaji se, co pro mne muzou udelat.

P.S. porad je to lepsi nez dratem do oka nebo IBM.



Hádám, že někdy muže být levnější zkopírovat zajímavé záznamy do jiné tabulky, udělat truncate a pak zajímavá data nalít zpět (ale je to specielní případ - pokud se ponechá jen zlomek dat z ohromné tabulky).

L..

  • ****
  • 302
    • Zobrazit profil
    • E-mail
Re:SQL dotaz: defragmentace tabulky
« Odpověď #8 kdy: 06. 08. 2022, 08:42:50 »
No, jak bych to... Napsal jsi tu pět příspěvků a stále jsi nesdělil, jakou konkrétní SQL databázi tam máte. Jestli takhle komunikuješ i se supportem, tak se nedivím, že není schopný dát rozumnou radu.

Jelikož je ta DB tak tajná, tak mohu poradit jen obecně: Nevím o tom. že by nějaká SQL DB měla operaci "rebuild tabulky jen z určitých záznamů". Pokud by bylo potřeba něco takového dělat, tak viz předřečník - potřebné záznamy se odlijí do nové tabulky a tabulky se nějakým způsobem vymění.

V případě historických tabulek (reporty atp.) kam rutinně přibývají a odmazávají se řádky se to řeší partitioningem, kdy se pak dropne najednou celý partition - například měsíc nebo rok dat.

Nicméně tohle je, podle toho co píšeš, spíš nějaký číselník (?) Samozřejmě, pokud je takhle "průtočný" a má sloupeček s datem vytvoření, tak se to tak řešit dá taky. Ale je to tedy docela zvláštní pattern.

Dál stojí za poznámku, že DB operace jsou (pokud jsou dobře indexy) většinou log(n). Tedy pokud odmažeš 3/4 záznamů, tak to nejspíš pomůže, ale řádové zlepšení bych si od toho nesliboval. Maximálně kdybyste se potom najednou zase vlezli do cache, ale na to bych nespoléhal.

Celkově mi přijde, že by se na to měl nejdřív kouknout někdo, kdo DB rozumí, aby zjistil, v čem je přesně zakopaný pes. Trochu blbý v těchhle situacích je, že support aplikace sice zná aplikaci, ale nevidí do DB, aby zjistil, na čem přesně to vázne. DB admini zase koukají jen na DB a že je nějaká aplikace pomalá je nezajímá.

Na tohle téma mám takovou vtipnou historku: U jednoho mobilního operátora jsme měli aplikaci od vendora, co ukládala reportingová data do DB. Najednou se ukládání dat do DB hrozně zpomalilo, data se hromadila ve frontě v aplikaci a reporty se zpoždovaly víc a víc. DB admini lehce arogantně tvrdili, že u nich to není, že oni tam nic nedělali, že jsme určitě něco zmršili my. Udělal jsem nějaké testy a došel k tomu, že ta DB je prostě podivně pomalá, ale ani to s nimi nehlo. Po několika dnech, když už situace začínala být kritickou, manažer zákazníka donutil DB adminy ať se na to přeci jen kouknou. Poměrně rychle zjistili, že se na DB stroji projevil bug v ZFS, kdy se po překročení určitého procenta zaplněnosti výrazně zpomalil zápis na FS. Oprava byla jednoduchá - prostě odmazali nějaký balast, takže procento zaplnění disku spadlo pod kritickou mez a DB se zase zázračně rozjela. No, sypali si popel na hlavu docela dlouho.

Ta historika slouží pro ilustraci, že výkonové problémy jsou často komplexní a musí je řešit někdo, kdo má přístup ke konkrétní DB a potřebné znalosti.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #9 kdy: 06. 08. 2022, 12:35:22 »
Na tohle téma mám takovou vtipnou historku: U jednoho mobilního operátora jsme měli aplikaci od vendora, co ukládala reportingová data do DB. Najednou se ukládání dat do DB hrozně zpomalilo, data se hromadila ve frontě v aplikaci a reporty se zpoždovaly víc a víc. DB admini lehce arogantně tvrdili, že u nich to není, že oni tam nic nedělali, že jsme určitě něco zmršili my. Udělal jsem nějaké testy a došel k tomu, že ta DB je prostě podivně pomalá, ale ani to s nimi nehlo. Po několika dnech, když už situace začínala být kritickou, manažer zákazníka donutil DB adminy ať se na to přeci jen kouknou. Poměrně rychle zjistili, že se na DB stroji projevil bug v ZFS, kdy se po překročení určitého procenta zaplněnosti výrazně zpomalil zápis na FS. Oprava byla jednoduchá - prostě odmazali nějaký balast, takže procento zaplnění disku spadlo pod kritickou mez a DB se zase zázračně rozjela. No, sypali si popel na hlavu docela dlouho.

Jediný náš operátor, o kterém vím že má zfs na databázi je O2 a u něj jsem řešil přesně tenhle problém. Tenhdy to ale nebyl bug, ale dokumentovaná a neznalá vlastnost, viz např. nastavení spa_slop_shift v openZFS.

Ano, ty problémy bývají komplexní a tím, jak jednotlivé vrstvy řeší různé týmy, se řešení některý problémů extrémně táhne, ikdyž jsou primitivní.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #10 kdy: 06. 08. 2022, 13:15:56 »
1/ to snad neni bug, to je zname chovani vsech verzi ZFS, jakmile je volne misto pod 10%, tak peformance jde ke dnu.
2/popisujes presne moje situace (mnozne cislo), kdy nutim managera vendora, aby donutil adminy zopovedet otazky, u kterych rikaji, ze nemusime vedet odpoved, protoze to u nich neni.

3/ potom jsou bonusove pripady, ktere jsou na odchod z projektu, kdy...

i po primem zavolani supervisorovi teamu eskalace P2 na P1 trva 20 minut

support rika "f**u" na pozadavky, ktery se jinde  se delaly automaticky a preemtivne.

nebo zlaty hreb, po 4mesice trvajicim (technicky lidi zamestnavajicim ) tendru na kompletni support indicka firma skonci na 4 pozici, podle internich komentaru "protoze v minimalne  jedne technicke domene vubec nemala knowhow a lidi". To bylo ve ctvrtek. V pondeli je oznameno, ze kontrakt dostava tahle firma, ze si CEO "pres vikend zavolali a spolupraci vyjasnili"

celkem pochopitelne ani nechci udavat detaily, ktere by vedly k nejake identifikaci.

Na tohle téma mám takovou vtipnou historku: U jednoho mobilního operátora jsme měli aplikaci od vendora, co ukládala reportingová data do DB. Najednou se ukládání dat do DB hrozně zpomalilo, data se hromadila ve frontě v aplikaci a reporty se zpoždovaly víc a víc. DB admini lehce arogantně tvrdili, že u nich to není, že oni tam nic nedělali, že jsme určitě něco zmršili my. Udělal jsem nějaké testy a došel k tomu, že ta DB je prostě podivně pomalá, ale ani to s nimi nehlo. Po několika dnech, když už situace začínala být kritickou, manažer zákazníka donutil DB adminy ať se na to přeci jen kouknou. Poměrně rychle zjistili, že se na DB stroji projevil bug v ZFS, kdy se po překročení určitého procenta zaplněnosti výrazně zpomalil zápis na FS. Oprava byla jednoduchá - prostě odmazali nějaký balast, takže procento zaplnění disku spadlo pod kritickou mez a DB se zase zázračně rozjela. No, sypali si popel na hlavu docela dlouho.

Jediný náš operátor, o kterém vím že má zfs na databázi je O2 a u něj jsem řešil přesně tenhle problém. Tenhdy to ale nebyl bug, ale dokumentovaná a neznalá vlastnost, viz např. nastavení spa_slop_shift v openZFS.

Ano, ty problémy bývají komplexní a tím, jak jednotlivé vrstvy řeší různé týmy, se řešení některý problémů extrémně táhne, ikdyž jsou primitivní.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #11 kdy: 07. 08. 2022, 10:14:01 »
Vzhledem k tomu, co a jak tady píšete, byste to měl nechat na někom zkušenějším. Například aby zjistil , v čem je vůbec problém, a zda je nějaká defragmentace vlastně potřeba.

Jinak defragmentace se z principu nedá udělat pro „nejmladší záznamy“. Defragmentace vzniká tak, že se mažou záznamy, a zůstává po nich volné místo, případně se na jejich místo zapíší novější záznamy. Mohl byste vzít nové záznamy z celé tabulky a posbírat je na jedno místo na konec, přístup k novějším záznamům sekvenčním čtením byste zlepšil, ale tam, odkud jste ty záznamy vzal, by zase vzniklo prázdné místo – takže byste tu tabulku zároveň i ještě víc fragmentoval. Takovému procesu by se těžko mohlo říkat „defragmentace“.

Defragmentace tabulky neznamená, že by se záznamy mazaly. Při defragmentaci se záznamy jen přesouvají. Pořád nevíme, co je to za databázi, každopádně přístupy k defragmentaci jsou možné v zásadě dva. Jeden, jednodušší na implementaci, je prostě všechny záznamy zapsat znovu správně seřazené do nové tabulky. Při takovém přístupu je ovšem potřeba až dvojnásobný prostor proti původní tabulce – v jednu chvíli budete mít na disku celou tabulku dvakrát. Druhá možnost je dělat to na místě, tj. opravdu prohazovat jednotlivé záznamy. Takhle se defragmentují disky, protože k tomu není potřeba další prostor.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #12 kdy: 07. 08. 2022, 12:02:24 »
S tim nelze nesouhlasit.

Vzhledem k tomu, co a jak tady píšete, byste to měl nechat na někom zkušenějším.

Re:SQL dotaz: defragmentace tabulky
« Odpověď #13 kdy: 07. 08. 2022, 22:11:06 »
Mozna by bylo dobry si nejdriv rict co chapete pod pojmem fragmentace tabulky a jak to tento pojem chapou ostatni. A bylo by fajn vedet co za db engine to je.

Napriklad na oracle (ehh mam informace do 12c, uz db dlouho nedelam) fragmentace vznikala defakto na urovni tablespace, kdy bloky objektu (v tomto pripade tabulky) byly rozstrkany vsude mozne vlivem pridavani a mazani zaznamu. Tbs zde totiz byla popsana bitmapou neco jako byla treba FAT. Pokud jste chtel udelat "defragmentaci", znamenalo to analyzu objektu v prislusne tablespace, jejich move jinam a zase zpet, pripadne rebuild u indexu. Nicmene k tomu, aby clovek mohl bez ztraty kyticky takovou operaci provest, musel vedet jake objekty jsou jak na sobe zavisle, kam je presunout a kdyz tim presunem neco rozbil (indexy, procky, package..) vedet co rebuildnout. Nekdo delal import/export ale to mi prislo uz trochu hardcore

Re:SQL dotaz: defragmentace tabulky
« Odpověď #14 kdy: 07. 08. 2022, 23:04:10 »
Ono je to tezky, kdyz si nejak startup rad hraje na zahadnyho. Takze treba  si dali tu praci, aby @@VERSION nefungovalo.  Predpokladam, ze tohle na 99% serveru funguje.

Taky uz  jsem se tu kdysi ptal na trik, jak z nejakoho pozorovani chovani databaze lze urcit typ a verzi...


A bylo by fajn vedet co za db engine to je.