Autor Zpráva
Fisir
Profil
Ahoj.

Momentálně do MySQL ukládám běžné textové záležitosti, jako jsou revize článků, stránek, komentáře, … a k revizím článků přímo do MySQL (datový typ MEDIUMBLOB) ještě malý ilustrační obrázek. Nyní se však chystám přidělat podporu fotogalerie (a možná i videí) a chtěl bych ji mít možnost opět verzovat, stejně, jako to dělám se stránkami a články. Otázka tedy zní: zpomalí se nějak MySQL databáze, pokud budou v určitých tabulkách uloženy soubory o velikosti v řádech MB (a v případě videí i desítek MB)? A jaký datový typ bych měl případně zvolit?
juriad
Profil
Nedělal bych to. Verzovat můžeš i na disku - přece název souboru může být libovolný - třeba odpovídající ID v databázi.
Keeehi
Profil
Fisir:
Teoreticky o možné je, ovšem když jsem to jedno zkoušel, tak to nedopadlo vůbec dobře. Je to naprosto zbytečná zátěž. Jak píše juriad verzovat se dá i tak. Osobně bych to dělal tak, že bych jao jméno souboru použil jeho hash. V databázi se pak už jen pracuje s tímto hashem. Hash souboru identifikuje jeho obsah, takže není závislý na existenci nějakého ID v databázi. Navíc to má tu výhodu (i když ji třeba zrovna nevyužiješ), že se pak dá stejný soubor použít pro více záznamů.
Fisir
Profil
Reaguji na Keeehiho:
Navíc to má tu výhodu (i když ji třeba zrovna nevyužiješ), že se pak dá stejný soubor použít pro více záznamů.
Tuhle výhodu „simuluji“ i v databázi – když je u aktuální revize sloupec pro soubor prázdný, hledám starší neprázdný.

Děkuji, soubory tedy budu ukládat normálně na disk a do databáze jen jejich jméno.
Keeehi
Profil
Fisir:
To moje však funguje pře více souborů. Řekněme že máme na začátku 2 různé soubory Av1 a Bv1. Potom upravím soubor A, takže vznikne Av2. Ovšem teto modifikace byla náhodou taková, že teď obsah souborů Av2 a Bv1 je stejný.
Jak to vypadá teď u tebe v databázi:
soubor | vreze | obsah
A      | v1    | aaaaaa...
B      | v1    | 111111...
A      | v2    | 111111...
Jak je vidět, v sloupci obsah je zbytečně duplicitní hodnota. Když to budeš ukládat na disku, tak se problém přesune tam. Budou tam 2 soubory s rozdílným jménem, ale stejným obsahem. Což je zbytečné.

Soubor není nic jiného, než nějaká posloupnost bajtů. Když jako název souboru použiju jeho hash, tak už jeho obsah dokážu rychle identifikovat právě podle jeho jména. Já bych měl na disku tedy jen 2 soubory:
f48a2: aaaaaa....
bb7c1: 111111...

A v databázi
soubor | vreze | hash
A      | v1    | f48a2
B      | v1    | bb7c1
A      | v2    | bb7c1

To že soubor na disku nemá původní jméno mě nemusí trápit. To mám uložené v databázi a až to bude potřeba, tak si ho vygeneruji a přidám k tomu správný obsah.
Kajman
Profil
Mysql data souborů zvládne, viděl jsem i filesystém na ní postavený. Pokud se obrázky ukládají na disk, tak to může usnadnit zálohování - rsync souborů + export hlaviček do sql.
Fisir
Profil
Reaguji na Kajmana:
A bude to platit i v případě větších souborů (řádově desítky MB)? Jde mi jen o to, že takto bych měl veškerá data na jednom místě, ale není problém přesunout soubory na disk.
Kajman
Profil
Fisir:

Právě u velkých souborů v kombinaci s jejich velkým počtem mohou nastat potíže se zálohováním databáze klasickým sql exportem a importem. U souborů můžete využít rychlé nástroje, které zálohují pouze rozdíly. Pokud zálohujete jinak, např. snapshotem virtuálu, můžete tento rozdíl pustit z hlavy.

Výkonový rozdíl mezi soubory a bloby u mysql netuším, zkuste si pohledat něco v angličtině, pokud nestačí zkušenosti, které zdělil Keeehi.
RASik
Profil *
Ahoj,
taky trochu na lokále experimentuju s vkládáním souborů z formuláře do DB, ale chová se to podivně. Některé typy souborů se nedaří vložit vůbec bez ohledu na velikost (PDF, rtf, jpg), některé do velikosti cca 0,5MB, (např. doc,xlsx), některé do 1MB(bmp), ale v žádném případě se mi nepodařilo uložit soubor větší než 1MB.
Prosím, co mám kde nastavit? Mám v php.ini toto:
file_uploads = On
post_max_size = 32M
upload_max_filesize = 32M
v my.ini ani v httpd.conf jsem nenašel nic, co by se dalo nastavit. Přiznám se, že anglinou zas tak nevládnu.
Jedu na MySQL 5.0.51
Apache 2.2.15
PHP 5.2.6
Dík za popostrčení.
lionel messi
Profil
RASik:
Některé typy souborů se nedaří vložit vůbec bez ohledu na velikost (PDF, rtf, jpg), některé do velikosti cca 0,5MB, (např. doc,xlsx), některé do 1MB(bmp), ale v žádném případě se mi nepodařilo uložit soubor větší než 1MB.
Aký dátový typ je stĺpec, do ktorého dáta ukladáš?
RASik
Profil *
Mám tam:
longblob - BINARY
Alphard
Profil
Ptát se na typ sloupce byla podle mě dost střelba naslepo. Co si máme představit pod se mi nepodařilo uložit soubor? Je chyba v uploadu, v php, v mysql?
RASik
Profil *
Zkoušel jsem to před asi 2 roky - starší verze Apache, MySQL i PHP a prakticky se stejným výsledkem. Tehdy jsem to neměl za chybu, ale za vlastnost. Teď se k tomu po delší době vracím...

Kde je chyba právě vůbec netuším, protože žádné chybovky jsem neobdržel. Hledal jsem i v logách Apache, PHP i MySQL a zplna hrdla mlčí.
Mám ve skriptu podmínku if(!$vloz=mysql_query($vlozit) { echo "nepodařilo se"; } a právě to se zobrazí, v databázi záznam nepřibyde. Podotýkám, že nemám @mysql_query.

PS: ano, vím, že mysql je zastaralý, ale věřím,, že tím to není a zatím tedy neřeším...


Vlastně až tady jsem se dověděl, že by mělo jít ukládat i větší - velké - soubory, proto to opět zkouším - spíš ze zvědavosti...
Kajman
Profil
RASik:
Mrkněte, jak máte nastavené max_allowed_packet.
RASik
Profil *
V my.ini ani php.ini nic takového nemám...
Kajman
Profil
Současné nastavení zjistíte příkazem
SHOW VARIABLES LIKE 'max_allowed_packet'

Pro přenastavení si do my.ini do sekce [mysqld] zkuste přidat např.
max_allowed_packet=256M
RASik
Profil *
Přidal jsem do my.ini nedefaultní hodnotu
max_allowed_packet=73741824 - je to správně? Rozumím, že jde o přípustnou velikost cca 73MB?
Restartoval MySQL, zkusil vložit soubor bmp o velikosti 1800kB a FUNGUJE. DÍKY!


Tak proto jsem to nemoh nastavit, když to tam nebylo (rozhodně jsem to nesmáznul...)
MOC díky a pro dnešek dobrou...

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0