|
Prebacivanje slika iz blob polja u file
U mysql bazi podataka se nalaze slike u blob polju. Kako je baza narasla, ovo je postao problem u izvrsavanju aplikacije jer je tabela u kojoj se nalazi ovo polje sa slikom dostiglo velicinu 41MB a ima 1500 slogova.
Da li postoji automatski nacin da se blob polja prebace na host u neki folder u jpg. formatu ili koji su vec te slike, a da se u to polje upise putanja do kreirane slike na hostingu. Nadam se da sam bio jasan, cilj je da se u polju slika ne nalazi vise binarni zapis slike, vec putanja do slike, koja će se nalaziti na hostingu. |
Citat:
Citat:
Da li neko ima objektivan razlog zašto se ne bi trebalo da se čuvaju binarni podaci u bazi? Ja znam jedan (otežan backup i restore kroz neke klijente kao što je phpMyAdmin), ali to je manje više to. Neko iskusniji? |
Naravno da ne koristim select * froim table; , ali spajam ovu tabeli sa drugim tabelama, maksimalno sa još dve preko INNER JOIN. Da li misliš da ako tabela ima 41MB, to ne opterećuje procesor na hostingu. Mi upravo imamo problem što se upiti ponekad sporo izvršavaju, tačnije troši se puno procesorskih resursa. Opet ponekad se upiti izvšavaju dovoljno brzo pa nema "slow_queries" u mysql bazi, ali ponekad pri većoj poseti isti upiti se sporo izvršavaju i povećava se drastično broj slow_queries u mysql serveru, i raste potrošnja procesora.
Da li mislite da smanjivanje veličine ove tabele, i izbacivanje blob polja iz nje neće umanjiti potrošnju procesora. Sve ostale tabele su oko 100KB. |
ne bi trebalo da je ta velicina problem, ja imam baze od 2-4GB koje rade bez problema join-e... ok, tabela od 4GB bas i nije rekorder u brzini, ali radi...
|
Ova sto se brzine radi ok, ali trosi dosta CPU, trenutno je baza na VPS hostingu, ali ako ovo ne resi problem onda mora na dedicated.
|
Prodji bolje kroz upite i lupaj explain na njima. Moze lako da se desi da ti radi file sort nad rezultatom zato sto nemas index namesten na ORDER BY polju pa ne moze da sortira rezultat u memoriji ili tako nesto...
Tabela ti je vrlo, vrlo mala. Ako imas problema, proveri i velicinu kesha u db serveru i sve ostalo. Ovo ne bi trebalo da ti se desava. (isto iskustvo sa tabelama od 1+GB, radio na njoj i join sa jos 3 tabele, fercera sve...) |
Citat:
- brzi je pristup filesystemu nego bazi podataka - smanjenje operacija - ovako moras iscitati blob polje, kreirati tmp datoteku i pokazati je u browseru pa onda brisati. - ako je DB server na mrezi, povecavas promet jer je u pitanju staticki sadrzaj (slike) koje mogu da budu i na web serveru. Ima smisla ukoliko se radi o distribuiranom sistem, vishe web servera a jedan DB, ima smisla kad ima preko nekoliko miliona recorda (zbog filesystem ogranicenja na broj fajlova u jednom folderu i usporavanje pristupa tim fajlovima kad je broj veliki). |
kad se radi o slikama znacajno je takodje i sto je serviranje statickih fajlova preko web servera direktno znatno (reda 10x) brze nego preko skripte... a tu je i znacajno veca upotreba memorije kad se kopiraju velike kolicine podataka izmedju baze i skripte jer npr. kod klasicnih (buffered) querija php drajveri uvek prvo naprave kopiju podataka iz baze, pa ih tek onda daju skripti (a onda ih mi u skripti obicno opet kopiramo u neku promenjivu, itd..).
a moze se postaviti i kontra pitanje cemu uopste drzanje BLOB polja? Koje su prednosti toga, sem malkice jednostavnije brisanje.. |
Posle prebacivanja slika, iz baze na hard disk hostinga, tabela se sa 41MB smanjila na 300KB. Potrosnja procesora drasticno umanjila, eto jos jednog razloga zasto ne koristiti bazu podataka za prikazivanje slika.
Load procesora je isao do 15 a sada je ode na 1 kada je poseta jako velika, inace je oko 0.2 Sta mislito o ovome ? |
Djuki, o trenutnoj postavci (bar ja) ne mislim nista, jer to je sasvim normalno da se ponasa tako sa 300kb tabelama.
Ali ipak bih pogledao zasto se zakucavao toliko na 41MB bazi. To ni u ludilu ne sme da se dogadja, premalo je to podataka da bi se gusio... Bolje sad to da vijas nego da cekas momenat kada stvarno budes imao 40MB u bazi (a koje mozda neces moci da maknes na disk)... ;-) |
| Vreme je GMT +2. Trenutno vreme je 15:54. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.