Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Jaroslav 12. 06. 2014, 22:16:50

Název: MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 12. 06. 2014, 22:16:50
Ahoj,
udelal jsem ti takovej jednoduchej php script pro ukladani PNG do DB jenomze, ted mi databaze s obrazky zabere asi 500 Mb a casto se mi stava ze php se proste "zasekne" a data z DB mi nezobrazi (misto toho mam jenom bilou stranku). Uloziste v DB je zvoleno INODB. Obrazky se ukladaji pomoci base64...
Muze prosim nekdo poradit?

Název: Re:MYSQL data > 500 Mb
Přispěvatel: Zopper 12. 06. 2014, 22:22:15
Neukládat obrázky do DB, ale jako soubory, a v DB mít jen meta informace? Jako klíč/jméno může posloužit třeba hash toho obrázku. To pořeší i duplicity (pokud to budou totožné soubory, ne jen podobné obrázky).
Název: Re:MYSQL data > 500 Mb
Přispěvatel: Jaroslav 12. 06. 2014, 22:24:41
Pozde prave ... ja uz tam ma naukladano hromadu obrazku ... jenomze nemuzu prijit na to proc pri generovani PDF nedostanu soubor, ale jenom prazdnou stranku. Driv jak tam bylo malo obrazku, tak to slo ... ale ted je s tim problem, tak nevim jestli staci jenom zmenit promenou v php, kvuli nejake odezve nebo tak neco
Název: Re:MYSQL data > 500 Mb
Přispěvatel: BoneFlute 12. 06. 2014, 22:29:29
Pozde prave ... ja uz tam ma naukladano hromadu obrazku ... jenomze nemuzu prijit na to proc pri generovani PDF nedostanu soubor, ale jenom prazdnou stranku.

Začal bych tím, že si zjistím, co je to za chybu. To znamená nastavit si php na dev mód aby ti vypisoval všechny chyby i noticky. Podobně tak i MySQL (což mimochodem hodně štěstí). A podle té chyby zjistíš, jak dál.

Ukládat obrázky do databáze není vysloveně blbej nápad, ačkoliv má svá úskalí.

Co bych zvážil, je to ukládání pomocí base64. To mi přijde jako dosti plítvání místem, a nevidím v tom přínos. Ale to už je mimo tvou otázku.
Název: Re:MYSQL data > 500 Mb
Přispěvatel: Jaroslav 12. 06. 2014, 22:36:42
base64 se mi prave zdal driv jako vyhodny v jednoduchosti...
no budu se muset hrabat v logu apache ... ja jenom jestli s tim nema nekdo nejaky zkusennosti
Název: Re:MYSQL data > 500 Mb
Přispěvatel: Jaroslav 12. 06. 2014, 22:38:31
Prave na generovani pdf pouzivam mpdf v php. Mam tlacitko nahled a tlacitko na generovani PDF. Pokud dam nahled tak ten obrazek dostanu v pohode. Jak dam to pdf, tak konec. Pokud ale v pdf necham jenom text a nenecham nacist obrazek, pak se pdf vygeneruje ...
Název: Re:MYSQL data > 500 Mb
Přispěvatel: David1234 12. 06. 2014, 22:45:44
Já bych to viděl na http://www.php.net/manual/en/function.set-time-limit.php
Název: Re:MYSQL data > 500 Mb
Přispěvatel: VojtaB 12. 06. 2014, 22:48:29
Takže generuješ ty PDF pomocí mPDF nebo je bereš z DB?

Jestli generuješ, tak bych to viděl na time limit nebo spíš memory limit. mPDF je dost nenažranej na paměť.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 12. 06. 2014, 23:03:07
Tak max execution time sem dal na pet minut ... nahled se mi zobrazi do 7 vterin ... a stejne to freezne a zustane bila stranka ...
Memory limit na proces sem dal 300 Mb a stejne dostava v prohlizeci hlasu "cekani na server"
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: h7 12. 06. 2014, 23:22:49
Takto ti těžko někdo řekne, kde máš chybu, když nevidí do tvého kódu, tvé DB apod. Musíš zjistit více informací. Např.:
- povolit zobrazování chyb (error_reporting) a doufat, že se nějaká chyba zobrazí
- vrazit na určité místo nějaký výpis (echo apod.), pokud se to vypíše, tak se dané místo programu ještě vykonalo. Posouváním místa zjistíš, kam až to doběhne

Když tak píšeš o DB a množství dat, máš v DB nějaký rozumný index? Tedy nemusí to procházet celou tabulku (fullscan), aby to našelo příslušný řádek? Pokud si nejsi jist, použij EXPLAIN SELECT ...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 12. 06. 2014, 23:33:26
Zkusil jsem jeste premistit celou DB na jinej server, pac ten na kterym jede DB instance ma 256 Mb RAM a 866 Mhz cpu  :-\ ted je to na jinym zeleze a cely pdf dostanu do deseti vterin ...

Na to starem serveru vidim Hitrate permanetne 100% a na to novem je to v klidu a ani se to nehne ... ovsem nevim co si mam predstavit pod pojmem hitrate
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: to_je_jedno 13. 06. 2014, 07:40:48
90% to bude memory limit, 9% time limit.

Ovsem ptej se sam sebe jestli jsi spravny clovek na jakekoliv programovani kdyz pises nejdriv dotaz do fora misto abys projel apache log kde bys to nasel a uz davno mel vyresene.
Dale se zamysli nad tim jak se ptas, protoze na podobne hloupe napsane dotazy budes vzdy dostavat hloupe odpovedi.

500MB je prtava DB, tam problem vubec neni.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: strepty 13. 06. 2014, 07:42:10
Zda sa ze je to uz vyriesene. Ale taketo nieco som riesil s PdfCreatorom na Windowse a Mssql, vyzeralo to tak ze pdf creator vyrabal pdf este v dobe ked nemal zdroj dat tak vyrobil prazdne pdf.  Moje riesenie bolo sice riadne ugly ale funfovalo, dal som do skriptu medzi nacitanie obrazka a spustenie pdf creatora pauzu 10 sekund. Ten cas treba zistit experimentalne.   
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: karel 13. 06. 2014, 08:10:21
Zkusil jsem jeste premistit celou DB na jinej server, pac ten na kterym jede DB instance ma 256 Mb RAM a 866 Mhz cpu  :-\ ted je to na jinym zeleze a cely pdf dostanu do deseti vterin ...

Na to starem serveru vidim Hitrate permanetne 100% a na to novem je to v klidu a ani se to nehne ... ovsem nevim co si mam predstavit pod pojmem hitrate

Ty si chlape opravdu "vostrej" na stroji s 256MB ram nastavis limit na php 300MB aby si pomohl k dokonceni skryptu, do toho mas minimalne v pulce ram narvanou mysql ktera cast te ram zaplni vysledkem s vyhledavani a na tvorbu pdf i pres tvoje nastaveni proste nezbyde misto, neco proste selhat musi. Samozrejme by se to dalo rozbehat i na teto konfiguraci, jen je nutne jajit presne uzke hrdlo.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: e3k 13. 06. 2014, 08:27:58
ja by som pozrel SHOW VARIABLES LIKE 'max_allowed_packets';
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 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 ..

Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 13. 06. 2014, 09:13:28
max_allowed_packet=32MB a stejne to nejde
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: and 13. 06. 2014, 09:38:34
max_allowed_packet=32MB a stejne to nejde
Je to rozbity...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Honza 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.

Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Tomáš Crhonek 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.  ;)
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: BrainLess 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Tomáš Crhonek 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Tomáš Crhonek 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.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 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 ...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 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 ...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 13. 06. 2014, 12:47:28
*obsazuje
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: to_je_jedno 13. 06. 2014, 13:02:13
a tohle vsechno jsme meli tusit z kavove sedliny nebo vestecke koule?
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jaroslav 13. 06. 2014, 13:46:50
a tohle vsechno jsme meli tusit z kavove sedliny nebo vestecke koule?

dekuju tem co prispeli do konverzace necim uzitecnym ...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jan Forman 13. 06. 2014, 21:07:39
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.

Ono se hodně změnilo v průběhu času a takovej Gallera Cluster není vůbec špatná věc.
http://galeracluster.com/products/
Je fakt, že vývoj byl vždycky spíš cílený na praktické věci, zatímco PostgreSQL se snaží jít cestou Oracle DB (obojí ma něco do sebe)
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Trident 14. 06. 2014, 00:06:41
Problem nekterych lidi tkvi v tom, ze stale neveri ze moderni filesystem muze byt na spravu efektivnejsi a rychlejsi nez databaze. Historicky se databaze pouzivaly na obejiti limitaci tehdejsich filesystemu. Koneckoncu filesystem je jen druh specialni databaze;)
V momente kdyz ale muzu strukturovat filesystem do nekonecna (neni limit vnorenych adresaru a souboru v adresari), deduplikace, vlastni indexace adresaru, snapshoty, online replikace a presuny celych dat na jine svazky, tak potom prestava mit jakkakoliv databaze na pouhe ukladani samotnych fotek smysl.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: h7 14. 06. 2014, 00:40:22
Tohle umí které filesystémy?
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: snajpa 14. 06. 2014, 09:10:39
ZFS :)
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: dustin 14. 06. 2014, 10:05:56
Každý nástroj je k něčemu určen. Pokud potřebuje aplikace k fotkám ukládat metadata, slouží k tomu databáze. Pokud DB zvládne i uložení přímo binárních dat, nabízí se logicky uložení všeho dohromady. Jednoduchost zálohování, udržování konzistence, atd.

500MB není žádná velká databáze. Pokud k souborům není potřeba přistupovat přes filesystém (např. po síti přes sambu či nfs), klidně bych takové soubory do DB uložil. Je to nejjednodušší a jednoduchá řešení bývají ta správná. Záloha je snadná, pro větší objemy doporučuji mysqldump s parametrem --tab. Výsledné soubory pro jednotlivé tabulky se snadno inkrementálně zálohují, lze je před zálohováním bzipnout, snadno z nich lze obnovit jen jednu nebo několik tabulek a je to rychlejší (mnohokrát vyzkoušené).

Řešit takovou aplikaci přes funkce ZFS je nesmysl.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Kit 14. 06. 2014, 10:35:38
Řešit takovou aplikaci přes funkce ZFS je nesmysl.

Ke každému souboru je možné přidat libovolné množství dalších atributů. To je pro takovou aplikaci jak stvořené.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: flv 14. 06. 2014, 11:24:21
Ukladat soubory do db smysl ma, alespon v pripade, kdy tech souboru ukladate vice nejdnou, jsou na sobe zavisle a potrebujete zajistit integritu pri rollbacku.

Název: Re:MySQL databáze nad 500 MB
Přispěvatel: whatever 14. 06. 2014, 13:08:22
Ahoj,
udelal jsem ti takovej jednoduchej php script pro ukladani PNG do DB jenomze, ted mi databaze s obrazky zabere asi 500 Mb a casto se mi stava ze php se proste "zasekne" a data z DB mi nezobrazi (misto toho mam jenom bilou stranku). Uloziste v DB je zvoleno INODB. Obrazky se ukladaji pomoci base64...
Muze prosim nekdo poradit?
podivat se na long queries. zkontrolovat jestli nevisi na plnym replikacnim logu. zkontrolovat jestli nevisi na plnym ulozisti cili kvoty uvnitr ino a kvoty na mediu na kterem je to ino a cekova kapacita oblasti ve ktere je to ino minus pro roota vyhrazene bloky. zkontrolovat kernel log na chyby. zkontrolovat delku io front jestli se potichoucku nekurvi fyzicke uloziste a firmware to jen maskuje. zkontrolovat misto pro logovani beziciho mysql enginu (ted nemyslim replikacni log, ale warningy/errory). podle toho co se najde pak budes pokracovat v dalsim hledani...
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: dustin 14. 06. 2014, 13:22:00
Ke každému souboru je možné přidat libovolné množství dalších atributů. To je pro takovou aplikaci jak stvořené.

Ty atributy jsou naindexované pro rozumně výkonné vyhledávání? Je k dispozici standardní známý a široce podporovaný jazyk pro jejich vyhledávání i přes více najednou (joinování inner i left), spoustu funkcí, hromadnou aktualizaci - tedy sql nebo nějaký nosql dotazovací jazyk? A jak je zajištěna referenční integrita mezi více soubory? Jak je zajištěna transakční bezpečnost při ukládání více informací více příkazy po sobě?

Databáze a filesystém jsou různé technologie a každá slouží k něčemu jinému.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Jan Nejman 14. 06. 2014, 16:38:14
Ahoj,

  jinak 'blob' neni prilis vhodny pro ulozeni dat. Do blobu jde v MySQL ulozit jen 64kB dat! Nevim, jak velka
data tam ukladas, ale pokud vetsi, doporucuji pouzit rovnou longblob (max. 4GB)... Pokud mas delku radku
delsi jak 64kB (zvlast po base64 ti to jeste naroste), tak MySQL data orizne na max. velikost daneho typu.
To by pak mohlo zpusobovat, ze mPDF vytuhne, protoze mu tam davas neuplny data... Mozna hodi MySQL
warning, ale insert s automatickym orezem urcite projde... Mozna v tomto bude zakopany pes, teda me by
to davalo smysl. Samozrejme, jak uz jsem psal, je nutne udelat vice kroku, jak diagnostikovat misto problemu.
Napr. nevolat mPDF ale treba nactena data z MySQL jen vypsat na obrazovku, alespon pak budes vedet,
jestli MySQL jede a problem je nekde dale...

Mej se,
Honza
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: andy 14. 06. 2014, 19:30:22
To akoze tahas pdf-ka selectom? To fakt neni moc dobre. Zbytocne vyzieras systemove zdroje. Lepsie by bolo si to aspon hned po selecte ulozit niekde do tempu a uz  stym pracovat ako so suborom.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Tomáš Crhonek 14. 06. 2014, 21:21:30
ale insert s automatickym orezem urcite projde...

Jo jo, moc hezká vlastnost:

http://www.soom.cz/clanky/1145--SQL-Truncation-Attack-aneb-jak-hacknout-SOOMcz
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: podlesh 15. 06. 2014, 22:31:49
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.
Jenom bych upozornil, že toto není specialita MySQL, mají to tak i jiné db engine. Naopak mi přijde že většina a postgresql je v tomto trochu atypický.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: anton stahovec 17. 06. 2014, 10:22:44
Obrazky ukladaj na disk je zbytocne ich davat do DB. Podla id obrazka si vytvor napr.: 2 urovne adresarov.

ID obrazka 0x1234567890

prvy adresar bude mat meno 90 a jeho podadresar meno 78 t.j. na prvej urovni budes mat 256 adresarov a kazdy adresar max. 256 podadresarov. File system by mal kludne tuto hierarchiu zvladnut.
Název: Re:MySQL databáze nad 500 MB
Přispěvatel: Kit 17. 06. 2014, 10:43:22
... Podla id obrazka si vytvor napr.: 2 urovne adresarov...

U dnešních souborových systémů je toto opatření zpravidla zbytečné. Zvládají i milióny souborů v jednom adresáři.