MySQL databáze nad 500 MB

Jaroslav

Re:MySQL databáze nad 500 MB
« Odpověď #15 kdy: 13. 06. 2014, 08:51:51 »
ta instance DB serveru jela na uplne jinem serveru nez apache, takze to vliv nemelo ... podle vytizeni DB si pri generovani PDF ta databaze ani neohrala packy, pac ocividne nic neservirovala...

Na te vykonejsi masine kde ted zije kopie se v momente, kdy kliknu na generovani pdf ukaze v dvou vterinach traffic 3 Mb  a konec ..



Jaroslav

Re:MySQL databáze nad 500 MB
« Odpověď #16 kdy: 13. 06. 2014, 09:13:28 »
max_allowed_packet=32MB a stejne to nejde

and

Re:MySQL databáze nad 500 MB
« Odpověď #17 kdy: 13. 06. 2014, 09:38:34 »
max_allowed_packet=32MB a stejne to nejde
Je to rozbity...

Re:MySQL databáze nad 500 MB
« Odpověď #18 kdy: 13. 06. 2014, 09:43:27 »
500 MB je miniaturní databáze, v tom problém určitě nebude. Problém může být ve špatné struktuře dat (např. chybějící indexy), nebo ve špatných dotazech (nevyužívají se indexy, z databáze se tahá víc dat, než je potřeba…).

SQL databáze sice nejsou určené pro ukládání souborů, ale použít se k tomu dají. U takhle miniaturní databáze s tím nejspíš nebude žádný problém. Výhoda uložení v databázi je, že máte zaručenou referenční integritu (pokud tak databázi navrhnete, samozřejmě). Např. při obnově ze zálohy nemusíte nic řešit, prostě obnovíte data do nové databáze a můžete pokračovat. Nevýhodou je také zálohování – nejspíš budete dělat dump celé databáze, takže i neměnící se data budete mít v každé záloze znova. Při použití souborů byste nejspíš zálohoval jen rozdíly. Použití databáze může mít ještě jednu nevýhodu u zatíženého webu – data se budou v paměti několikrát kopírovat, při použití souborů je možné data odeslat rovnou z diskové mezipaměti bez kopírování.

Každopádně je neefektivní binární data do databáze ukládat v base64, zbytečně se tím zvětší objem dat o třetinu. Navíc při použití to zase musíte dekódovat, takže ta data budete mít nejspíš v jednu chvíli v paměti dvakrát. Pro ukládání velkých binárních dat do SQL databází slouží datový typ BLOB – Binary Large OBject.

Honza

Re:MySQL databáze nad 500 MB
« Odpověď #19 kdy: 13. 06. 2014, 09:46:21 »
Ahoj,
   pokud to jse, posli vypisy:

show create table 'tabule';
show table status like 'tabule';
show global variables;
show global status;

a pak dotaz, kterym vybiras ten spravny sloupecek z databaze s navic predrazenym explain, neco jako:
explain select * from 'tabule' where id=xxx;

Pak muzes kouknout na apache error log zda-li tam neco neni. + na zacatek php skriptu dej:
error_reporting(E_ALL);

Tech mist, kde muze byt problem je opravdu hodne. Jen pro info jestli dobre rozumim,
mas nekde centralni databazi s daty (obrazky) a k ni se pres TCPko pripojujes z nejakeho slabeho
zeleza (napr. nejaky infostanek) a generujes tam pdfka ktera zobrazis. Je to tak? Pokud
ano, posli kolik mas RAM na tom slabem zeleze a kolik mas nastaven limit v php. Taky si nejsem
jist, zda-li nesestreli kernel nejaky subproces, kvuli nedostatku RAM. Mas nastaven SWAP?
Koukni jeste do systemoveho logu, zda-li kernel nepise neco o sestreleni nejvic rozezraneho procesu.



Re:MySQL databáze nad 500 MB
« Odpověď #20 kdy: 13. 06. 2014, 10:39:48 »
Každopádně je neefektivní binární data do databáze ukládat v base64, zbytečně se tím zvětší objem dat o třetinu. Navíc při použití to zase musíte dekódovat, takže ta data budete mít nejspíš v jednu chvíli v paměti dvakrát. Pro ukládání velkých binárních dat do SQL databází slouží datový typ BLOB – Binary Large OBject.

Osobně bloby nedoporučuju, protože ono je to v podstatě totéž, jako soubor na disku a v DB uložená cesta. U blobů nelze pořádně zajistit referenční integritu apod. Ale pokud bych měl volit mezi soubory na disku a bloby, tak bloby vedou (právě z důvodů centrálního uložení všech aplikačních dat na jednom místě a pokud se nastaví inkrementální zálohování, tak ani s tím není problém).

PostgreSQL má datový typ bytea (byte array), který je přesně vhodný na použití jaké má původní tazatel. Navíc u postgresu se každé pole větší než (afaik) 2KB uloží na disk komprimovaně (což u komprimovaných obrázků nic nepřinese, ale u obecných souborů je to znát a z hlediska appky je to zcela transparentní -- netřeba řešit komprimaci v appce zvlášť). Bytea se chová jako kterýkoliv jiný datový typ (int, decimal apod), akorát je prostě o něco větší.

Jinak původní tazatel by si měl především ujasnit jednotky. 500Mb (62.5MB nebo 59.6MiB) není až tak velká database, ale pokud má server který má jen 32MB paměti (256Mb) a ještě záhadný procesor s  866Mhz (to tedy fakt nevím co je), tak problém bude zřejmně v něčem zcela jiném, než v MySQL.  ;)

Re:MySQL databáze nad 500 MB
« Odpověď #21 kdy: 13. 06. 2014, 10:57:16 »
Osobně bloby nedoporučuju, protože ono je to v podstatě totéž, jako soubor na disku a v DB uložená cesta. U blobů nelze pořádně zajistit referenční integritu apod.
Proč by u BLOBů nešlo zajistit referenční integritu? Když budu mít v DB např. článek a u něj seznam obrázků, tak cizí klíč na ID obrázku a NOT NULL na BLOBu docela dobře zajistí, že obrázek odkazovaný z článku v databázi také mám. Pokud budu mít v DB jen cestu k souboru, nikde nemám zaručeno, že takový soubor na disku skutečně existuje.


pokud se nastaví inkrementální zálohování, tak ani s tím není problém).

Jak použitelné je to inkrementální zálohování u PostgreSQL? Výhoda zálohování dumpu databáze je v tom, že snadno vezmu jeden soubor a obnovím ho kdekoli jinde. U inkrementálního zálohování souborů je to podobné, s použitím rsync-diff nebo snapshotů mám uložený kompletní stav, který můžu kdykoli obnovit a pokračovat s ním. U toho inkrementálního zálohování PostgreSQL se bojím toho, že případná obnova bude složitá, a zejména toho, že se to inkrementální zálohování tiše rozbije, aniž bych něco zjistil.

BrainLess

Re:MySQL databáze nad 500 MB
« Odpověď #22 kdy: 13. 06. 2014, 11:07:47 »
Neber to prosim jako osobni utok ale dopustil jsi se nekolika chyb.

1. Chyba navrhu  ( ukladat obrazky do DB a jeste jako base64 je silenost ). Ztracis space, ztracis CPU tim ze to prevadis z/do base64
2. Pouzivas evidentne technologie o kterych toho moc nevis
3. Problem se snazis vyresit typicky managerskym pristupem -> dame tam silnejsi zelezo ..

No a abych jenom nekritizoval tak k tomu co uz bylo receno ( debug mode a vetsi ukecanost logovani ) bych jeste prihodil strace ale to uz je hodne hluboka orba.

Re:MySQL databáze nad 500 MB
« Odpověď #23 kdy: 13. 06. 2014, 11:36:41 »
Proč by u BLOBů nešlo zajistit referenční integritu? Když budu mít v DB např. článek a u něj seznam obrázků, tak cizí klíč na ID obrázku a NOT NULL na BLOBu docela dobře zajistí, že obrázek odkazovaný z článku v databázi také mám. Pokud budu mít v DB jen cestu k souboru, nikde nemám zaručeno, že takový soubor na disku skutečně existuje.

O blobech více Tomáš Vondra: http://www.fuzzy.cz/cs/clanky/ukladani-souboru-do-postgresql-databaze/

Co na BLOBech není pěkného? Neexistuje referenční integrita - můžete klidně smazat BLOB který je stále odkazován z tabulky. Můžete sice vytvořit AFTER UPDATE a AFTER DELETE triggery pro odstranění osiřelých BLOBů, nebo můžete použít  "lo" contrib balíček. Každopádně žádné z těchto řešení nevynucuje referenční integritu takže vám nějaký blbeček klidně může umazat BLOBy přímo

Při vytvoření blobu máte pouze oid (číslo blobu) a funkce na práci s ním, které mají jako argument právě oid. To, že je někde v katalogu systémová tabulka pg_largeobject je sice hezké, ale vám to moc nepomůže (rozhodně by se nepokoušel dělat nějaké hacky s katalogem, to se při nejbližší příležitosti (například obnovení dumpu po havárii) vymstí).

Jak použitelné je to inkrementální zálohování u PostgreSQL? Výhoda zálohování dumpu databáze je v tom, že snadno vezmu jeden soubor a obnovím ho kdekoli jinde.

Psal jsem o tom článek (http://www.heronovo.cz/zalohovani-obnova-postgresql-metodou-pitr-point-time-recovery/). Ano, není to tak snadné jako udělat pg_dump, na druhou stranu, když se to nastaví, je možné provést obnovu k jakémukoliv času (point in time), pokud vím, že transakce v 9:00 rozmlátila DB (delete bez where apod), tak jsem shopen obnovit stav k 8:59 (případně přímo ke konkrétnímu číslu transakce, ale to se málokdy ví).

Dále, pokud je db velká, tak klasické dumpy ztrácejí na efektivitě. PostgreSQL, na rozdím od MySQL s MYISAM, při dumpu neblokuje provoz, db je normálně použitelná, ale pochopitelně to žere (nejen) diskový výkon. Klasické dumpy nelze moc dobře skladovat inkrementálně (malinkatá 10GB DB při každodenním dumpu za 1 měsíc sežere 300GB na zálohovacím stroji).

Každá věc má pro a proti a je na adminovi, aby to zvážil.

Re:MySQL databáze nad 500 MB
« Odpověď #24 kdy: 13. 06. 2014, 11:58:55 »
O blobech více Tomáš Vondra: http://www.fuzzy.cz/cs/clanky/ukladani-souboru-do-postgresql-databaze/

Co na BLOBech není pěkného? Neexistuje referenční integrita - můžete klidně smazat BLOB který je stále odkazován z tabulky. Můžete sice vytvořit AFTER UPDATE a AFTER DELETE triggery pro odstranění osiřelých BLOBů, nebo můžete použít  "lo" contrib balíček. Každopádně žádné z těchto řešení nevynucuje referenční integritu takže vám nějaký blbeček klidně může umazat BLOBy přímo

Při vytvoření blobu máte pouze oid (číslo blobu) a funkce na práci s ním, které mají jako argument právě oid. To, že je někde v katalogu systémová tabulka pg_largeobject je sice hezké, ale vám to moc nepomůže (rozhodně by se nepokoušel dělat nějaké hacky s katalogem, to se při nejbližší příležitosti (například obnovení dumpu po havárii) vymstí).

To je ale implementace v PostgreSQL. Navíc i tam by v tomhle případě asi šlo bez problémů použít bytea. Tazatel ale píše o MySQL, kde jsou BLOBy normální datový typ.

Re:MySQL databáze nad 500 MB
« Odpověď #25 kdy: 13. 06. 2014, 12:10:11 »
To je ale implementace v PostgreSQL. Navíc i tam by v tomhle případě asi šlo bez problémů použít bytea. Tazatel ale píše o MySQL, kde jsou BLOBy normální datový typ.

Fajn, z rychlého přeletění dokumentace MySQL (5.5) to vypadá, že (long)blob je u mysql podobný typ jako bytea v psql. Potom tedy ano.

Mě MySQL nesmí do domu už nějakých pár let, takže tohle mi uniklo.

Jaroslav

Re:MySQL databáze nad 500 MB
« Odpověď #26 kdy: 13. 06. 2014, 12:12:39 »
Neber to prosim jako osobni utok ale dopustil jsi se nekolika chyb.

1. Chyba navrhu  ( ukladat obrazky do DB a jeste jako base64 je silenost ). Ztracis space, ztracis CPU tim ze to prevadis z/do base64
2. Pouzivas evidentne technologie o kterych toho moc nevis
3. Problem se snazis vyresit typicky managerskym pristupem -> dame tam silnejsi zelezo ..

No a abych jenom nekritizoval tak k tomu co uz bylo receno ( debug mode a vetsi ukecanost logovani ) bych jeste prihodil strace ale to uz je hodne hluboka orba.

Manazerskej pristup ... kdyz sem v logu z apache v error_log nic nenasel co by ukazovalo proc se to podelalo a potreboval sem to rychle rozjet tak co sem mel delat? Navic jak je mozny ze stejna verze mysql se stejnym configem ma rozdilnej vysledek...
Problem taky je ze masiny nejsou ve stejne siti HTTP server a MYSQL jsou v jinych sitich. MYSQL lezi za jinym firewallem. Tam kam sem premystil DB, tak to je v lokalni siti...

Co se vykonu tyce... Tak na web serveru jsou 4Gb ramky 2 jadro ... jednotlive procesy httpd neprekracuji ani ram ani nevyzdimaji cpu. Co se tyce toho noveho serveru, tak ten ani nemrkne a data posle, ten druhej ma porad "Hit rate 100%" coz porad netusim co znamena a ty data do toho pdfka neposle ..

Jinak DB je udelana formou relace ... v jedne tabulce lezi nazev, id obrazku a nejaky ostatni data a podle id se ten obrazek sosne z jine tabulky kde je jenom id=obrazek. Snad jsem pouzil spravnou terminologii a v php delam prilezitostne, takze  nemam problem priznat chybu pokud sem ji udelal tak markantni ...

Jaroslav

Re:MySQL databáze nad 500 MB
« Odpověď #27 kdy: 13. 06. 2014, 12:36:47 »
Chyba je v MPDF ...
A to presne v CPU... me to fungovalo, protoze jsem to zkousel mimo produkcni cas v jine instanci ... takze mi to slo, protoze na serveru nejeli i ostatni ...
Ted jak je tam vic lidi je videt, ze httpd spolehlive obsahuje celej procesor ...

Jaroslav

Re:MySQL databáze nad 500 MB
« Odpověď #28 kdy: 13. 06. 2014, 12:47:28 »
*obsazuje

Re:MySQL databáze nad 500 MB
« Odpověď #29 kdy: 13. 06. 2014, 13:02:13 »
a tohle vsechno jsme meli tusit z kavove sedliny nebo vestecke koule?
Děkuji za možnost editace příspěvku.