Předumpování databáze, aneb bude to brnkačka (diskuse)

[z_sk]

Poznas prikaz parallel?

[henk]

Vím, že existuje. Ale xargs znám už déle, tak dostal přednost. Navíc mi parallel nepřišel moc intuitivní, když jsem na něj koukal naposled.

[z_sk]

Ja preferujem na pararell nieco: v tom duchu (zas bez toho formatovanie vety v tom a s :::: som pouzival)

[petr]

A cim bylo zpusobene to leakovani mista na disku?

[henk]

Kolega na to nepřišel a já neměl čas se v tom vrtat. Jinak databáze je hodně stará a prošla mnoha verzemi(upgrady), tak mi přišlo lepší ji rovnou takto vyčistit.

[Max]

Hmm, pěkný leakožrout :)
Zdar Max

[johnyK]

projekt, ktery ma 5000 databazi a celkem 550 000 tabulek? Tim se ridi zemekoule, vesmir nebo Agrofert? Uz u SAP jsem si rikal, ze kdyz to ma v zakladni sestave 60 000 tabulek, tak ze se panove analytici u SAP zblaznili, ale jak je videt ono se to da gradovat.

Ostatne soudim, ze fandove relacnich databazi a cele te teorie okolo by se meli nechat vysetrit

[Faceless man]

Tabuliek v DB nieje nikdy dosť ! :-P

[ehmmm]

A pritom to ma jen 100 GB. (?)

[Faceless man]

Na SQL db málo !

[henk]

:) Řekl bych co to je, ale nejsem si vůbec jistý jestli můžu. Je to prasečina a kdyby se na to někdo podíval, tak by možná zjistil, že půlka jde promazat. Ale to teď nikomu nestojí za námahu.

Jinak k těm prasečinám: viděl jsem i systém, který pro ukládání dat používal názvy sloupců. Následně narazil na interní limit MySQL, tak jsme mu kvůli tomu museli upgradovat na verzi, která má limit výše :)

[Josef Kufner]

Neemuluje se těmi tabulkami dělení dat do partitions?

[podlesh]

Myslím že je naprosto jasné že ty tabulky nivytvořil žádný analytik, ty jsou prostě generovány za běhu. Možná jsou to dočasné tabulky a chybí mazání?

[Heron]

Viděl jsem projekt, který vytvářel DB per uživatele. Těch tabulek tam nebylo 110 per DB, ale trochu míň. Tuším snad SOGo nebo něco z balíku iRedMail. Je to prasárna, která nemá žádnou výhodu (možná až na jednoduchý drop v případě smazání uživatele). Navíc v žádném normálním DB produktu by to nešlo dělat, obvykle se připojuje ke konkrétní DB a nikoliv k serveru. Ale MySQL to má hold takto.

Ale proč to dělají takto fakt netuším. Když tam těch userů bude fakt hodně, tak v případě MySQL to znamená stejný počet adresářů. Tuším že u ext3 byl limit 32tis podadresářů v jednom adresáři. Tj jen 32tis uživatelů. Kdyby to bylo v normálně strukturované DB, tak by nebyl žádný problém několik milionů.

[trekker.dk]

innodb_file_per_table je na prd. docela často tomu nějaká tabulka uletí a pak se to musí nahánět, že se ztratil nějaký soubor, takže tabulka neexistuje, kromě případů, kdy ji chcete vytvořit, to pak hází chybu

innodb_file_per_table je ovšem taky na prd, to si ten innodb soubor pěkně bobtná a když pak v serverovně vypadne napájení (samozřejmě zálohované, asi zálohovaný výpadek), tak možná máte o celodenní zábavu ve formě obnovy databází ze záloh postaráno

Ale můžete si vybrat

[Odin1918]

Predne je fajn, ze jste si nejak poradil. Co uz fajn neni, je fakt, ze se nikdo nezaobiral resenim priciny problemu. I kdyz chapu, ze toto vase reseni ma nejnizsi naklady na lidske zdroje. Do budoucna bych se zamyslel nad pouzitim nejake opravdove databaze. PostgreSQL urazil za posledni roky hezky kousek cesty a myslim si, ze na takove mnozstvi dbs a tabulek je to urcite lepsi alternativa. Pokud vam tam takove objemy vznikaji nejakou primitivni emulaci partitioningu, urcite bych ten postgres doporucil tim spise.