Mazání řádků na SQL serveru a uvolňování místa

[pruzkumbojem]

sorry za potencialne dementni dotaz, ale tady mi support tvrdi, ze kdykoli scriptem mazeme radky v MariaDB, tak to neuvolni prostor zabrany na disku, ze SQL team musi pokazdy "rebuild table"

jak se to presne chova?

[Reklama]

[Idris]

To dá rozum, že se ten soubor zázračně nescvrkne. Doporučuji přečíst si o "database vacuuming".

(Tady je vidět, k čemu je alespoň základní IT vzdělání, tohle se bere na VŠ snad hned v prváku.)

[lazywriter]

V případě MySQL (resp. MariaDB) je víc možností a záleží na formátu uložení dat:

- pokud je formát MyISAM, tak ten se zmenší. Je to ale tak primitivní způsob uložení, že se dnes už nedoporučuje.
- pokud je formát INNODB, tak jsou zase další možnosti Buď je jeden tablespace a ten se skutečně nezmenšuje a pro uvolnění místa je potřeba offline dump a reload celé databáze. Nebo je, nejspíš, použitý file-per-table mód. Ten také neuvolňuje, ale dokud není fragmentace tabulky velká, tak by to nemělo mít dopad na výkon. A pokud nastane (např. po nějakém větším odmazávání), tak na konci stačí použít OPTIMIZE TABLE. Ale pozor, jedná se víceméně o dump/restore té jedné tabulky, který transparentně provede server a tabulka je celou dobu při něm zamknutá. Takže pro větší tabulky to může zabrat čas a musíte si ověřit, jaké dopady na produkci to může mít.

[pruzkumbojem]

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

V případě MySQL (resp. MariaDB) je víc možností a záleží na formátu uložení dat:

- pokud je formát MyISAM, tak ten se zmenší. Je to ale tak primitivní způsob uložení, že se dnes už nedoporučuje.
- pokud je formát INNODB, tak jsou zase další možnosti Buď je jeden tablespace a ten se skutečně nezmenšuje a pro uvolnění místa je potřeba offline dump a reload celé databáze. Nebo je, nejspíš, použitý file-per-table mód. Ten také neuvolňuje, ale dokud není fragmentace tabulky velká, tak by to nemělo mít dopad na výkon. A pokud nastane (např. po nějakém větším odmazávání), tak na konci stačí použít OPTIMIZE TABLE. Ale pozor, jedná se víceméně o dump/restore té jedné tabulky, který transparentně provede server a tabulka je celou dobu při něm zamknutá. Takže pro větší tabulky to může zabrat čas a musíte si ověřit, jaké dopady na produkci to může mít.

[oss]

trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Vytaj vo svete MySQL.

[Reklama]

[pruzkumbojem]

pokud se mi sem podarilo nalakat mySQL lidi, tak mam jinou otazku.

Jak neprimo poznam, jestli je to mySQL nebo MariaDB a jaka verze? Na chovani tabulek?
Nemuzu udelat neco jako @@version, to je zablokovany uz nejakou dobu.

Myslim neco jako "pokud muzu pridat vic nez 64 indexu na tabulku, tak je to 128bitovej server"

Pokud ..tohle.., tak je to urcite MariaDB.

[mark42]

skus na zaciatok SHOW PLUGINS, mozno Ti to ukaze nieco, od coho sa dokazes odrazit. Napr. Storage engine, ktory je len v MariaDB a nie v MySQL.

[Pavel Stěhule]

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Tohle nedělá žádná databáze. Defragmentace, shrink, ... je časově náročná operace, většinou vyžaduje dost agresivní zámky, a to si nemůžete dovolit volat automaticky.

[MalyTomi]

ktora db to robi automaticky?
cistenie sa vacsinou robi pri zalohe/obnove db, resp. sa naplanuje v noci, lebo za plnej prevadzky by to bol masaker. A taka zmena velkosti suboru je casovo narocna operacia, spomen si na defragmentaciu, co sa vtedy deje.

[hurvajs spejbl]

pokud se mi sem podarilo nalakat mySQL lidi, tak mam jinou otazku.

Jak neprimo poznam, jestli je to mySQL nebo MariaDB a jaka verze? Na chovani tabulek?
Nemuzu udelat neco jako @@version, to je zablokovany uz nejakou dobu.

Myslim neco jako "pokud muzu pridat vic nez 64 indexu na tabulku, tak je to 128bitovej server"

Pokud ..tohle.., tak je to urcite MariaDB.

nejjednoduší je se zeptat providera, pokud nemáte přístup k serveru / Dockeru.

Pak třeba jak se už zmiňovalo, SHOW PLUGINS.

Jen doufám, že myšlenka "pokud mohu více než 64 indexů" je myšlena obrazně... Pokud potřebujete tolik indexů, je něco špatně. Ono dost lidí neví, že indexy nejsou vždy třeba (záleží na datech) a moc indexů také škodí a pokud jsou i nevhodně použité, může být výsledný efekt horší než před zavedením indexů

[Ondrej Nemecek]

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Tohle nedělá žádná databáze. Defragmentace, shrink, ... je časově náročná operace, většinou vyžaduje dost agresivní zámky, a to si nemůžete dovolit volat automaticky.

Ovšem pochybuju že budou zákazníci vždy tak disciplinovaní, že si to nastaví sami, zvlášť u Mysql/MariaDB.  Taky bych spíš čekal, že to bude mít provider nějak defaultně nastavené - třeba s možností si to v cronu přenastavit nebo něco podobného.

Jinak mimochodem Postgres v rámci auto vacuum provádí co přesně?

[pruzkumbojem]

No jednak jsem to zminil jako trick jak neprimo odvodit parametr server.

A bohuzel v realnym zivote se SaaS provider rozhodl nahradit na backendu nekolik tabulke jednou, aby "zlepsili performance a zakaznika to nemusi zajimat, nulovy impact"

No, pokud spoji tabulky do jedne a celkovy pocet indexu presahne 64, tak vony si nejaky indexy ztrati, ze jo. (recnicka otazka, vim odpoved, ano, zmizi).

...takze ono to mozna zakaznika musi zajimat, protoze impact neni nulovy a nektery indicti truhlici netusi co cini (plus je jim to jedno).

pokud se mi sem podarilo nalakat mySQL lidi, tak mam jinou otazku.

Jen doufám, že myšlenka "pokud mohu více než 64 indexů" je myšlena obrazně... Pokud potřebujete tolik indexů, je něco špatně. Ono dost lidí neví, že indexy nejsou vždy třeba (záleží na datech) a moc indexů také škodí a pokud jsou i nevhodně použité, může být výsledný efekt horší než před zavedením indexů

[Pavel Stěhule]

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Tohle nedělá žádná databáze. Defragmentace, shrink, ... je časově náročná operace, většinou vyžaduje dost agresivní zámky, a to si nemůžete dovolit volat automaticky.

Ovšem pochybuju že budou zákazníci vždy tak disciplinovaní, že si to nastaví sami, zvlášť u Mysql/MariaDB.  Taky bych spíš čekal, že to bude mít provider nějak defaultně nastavené - třeba s možností si to v cronu přenastavit nebo něco podobného.

Jinak mimochodem Postgres v rámci auto vacuum provádí co přesně?

Nikdy jsem MySQL neprovozoval, takže nevím. Ale tipoval bych, že se to řeší nastavením maximální velikosti na disku a pak nějakým varovným mailem - případně plánovanou nebo neplánovanou odstávkou. U hostingů za 200 kč na měsíc nikdo nic nebude extra řešit. U těch důležitějších systémů tam se to dá možná pořešit bezodstávkově multimastrem.

Na druhou stranu, pokud se nemění poměry tabulek, tak shrinkování tabulek nedává moc velký smysl (pokud neřešíte bloating).

autovacuum řeší - lazy vacuum - odstranění mrtvých verzí (při 20% změněných řádků), platné verze jsou beze změny, analyze - přepočítání statistik (10%) a vacuum freeze (200M transakcí) - "jakoby" reset transakčních id. Všechny zmíněné příkazy mohou hodně cvičit s diskem, ale žádný nevyžaduje exkluzivní zámek.

[hurvajs spejbl]

No jednak jsem to zminil jako trick jak neprimo odvodit parametr server.

A bohuzel v realnym zivote se SaaS provider rozhodl nahradit na backendu nekolik tabulke jednou, aby "zlepsili performance a zakaznika to nemusi zajimat, nulovy impact"

No, pokud spoji tabulky do jedne a celkovy pocet indexu presahne 64, tak vony si nejaky indexy ztrati, ze jo. (recnicka otazka, vim odpoved, ano, zmizi).

...takze ono to mozna zakaznika musi zajimat, protoze impact neni nulovy a nektery indicti truhlici netusi co cini (plus je jim to jedno).

primárně jsem mluvil o tom, že myšlenka, že zavedení indexu = zvýšení výkonu DB. Tato myšlenka je pravdivá jen částečně. Velmi záleží na objemu dat a toho, co se v daném sloupci vyskytuje za hodnoty, např. pokud budu mít 10000 záznamů jsou indexy v podstatě k ničemu. Naopak pokud mám 100mil záznamů, tak ano, ale pokud daný sloupec může být jen boolean, index postrádá smysl. Ale to jen tak na okraj. Bohužel hodně lidí si myslí, že více indexů, tím super rychlost...

[Filip Jirsák]

Velmi záleží na objemu dat a toho, co se v daném sloupci vyskytuje za hodnoty, např. pokud budu mít 10000 záznamů jsou indexy v podstatě k ničemu. Naopak pokud mám 100mil záznamů, tak ano, ale pokud daný sloupec může být jen boolean, index postrádá smysl. Ale to jen tak na okraj. Bohužel hodně lidí si myslí, že více indexů, tím super rychlost...

I tohle je pravdivé jen částečně. Nezáleží na typu hodnota, ale na histogramu hodnot. Když budete mít tabulku se sto milionem záznamů, ale řádků s hodnotou true bude 100 a ty budete hledat, index se vám sakra vyplatí (zejména funkční, ve kterém budou jenom ty true hodnoty). I u těch desítek tisíc záznamů se může sloupec dost vyplatit, zejména pokud ta tabulka bude velká nebo dokonce data, která vás zajímají, vyčtete rovnou z indexu.