DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Maximalan i preporučeni broj fajlova u direktoriju (http://www.devprotalk.com/showthread.php?t=6998)

mb_sa 27. 01. 2009. 09:07

Maximalan i preporučeni broj fajlova u direktoriju
 
Zdravo!

Recimo da ce aplikacija za neko vrijeme baratati sa milion slika. Slike se spasavaju na disk, a njihovi nazivi u tabele. Linux server je u pitanju.

Negdje procitam da je moguce staviti neogranicen broj fajlova u folder, a negdje 32k. Nije mi toliko bitan maximlana broj fajlova u folderu, već preporučeni broj.

Znam da veliki broj fajlova u folderu moze dovesti do problema sa performansama, a tu je i pitanje backupa i managamenta tih foldera.

Zanima me kako vi rasporedjujete veliki broj slika po folderima? Sta je najbolje u praksi i sa kavim ste se problemima susretali?

Pokusacu da vam priblizim moju situaciju. Za svaki unos u jednu tabelu moguce je maximlano pridruziti do 5 jpg slika. Svaki taj unos se mora povezati sa nekom kategorijom, kojih je u mom slucaju 15.

Znaci, u ovom slucaju bi trebalo da bude minimlano 15 foldera. Kako organizovati podfoldere? Mozda po godinama, po mjesecima?

Hvala!

jablan 27. 01. 2009. 10:08

Možeš da koristiš npr. strukturu od 1000 direktorijuma, po modulu id-ja fajla iz baze.

ppavlovic 27. 01. 2009. 10:13

Iz iskustva, mogu u jednom folderu da stoje stotine hiljada fotografija. Jedini problem sa tim je kad pokušaš da ih izlistaš putem ftp-a.

Ja sam koristio md5 za nazive fajlova koji sam generisao na osnovu time() + rand() broj. Tada su nazivi dugi 32 karaktera, recimo ad77affeccaa23921938f899. Uzmeš prvo slovo od naziva fajla i smestiš u taj direktorijum, pa u poddirektorijum koji je drugo slovo, pa tako dalje...

- images/
--------/a/
----------/d/
------------/ad77affeccaa23921938f899

mb_sa 27. 01. 2009. 10:45

Citat:

Originalno napisao jablan (Napišite 65284)
Možeš da koristiš npr. strukturu od 1000 direktorijuma, po modulu id-ja fajla iz baze.

Mozes li mi malo detaljnije objasniti, jer nisam bas najbolje shvatio?! Hvala.

mb_sa 27. 01. 2009. 10:51

Citat:

Originalno napisao ppavlovic (Napišite 65286)
Iz iskustva, mogu u jednom folderu da stoje stotine hiljada fotografija. Jedini problem sa tim je kad pokušaš da ih izlistaš putem ftp-a.

Ja sam koristio md5 za nazive fajlova koji sam generisao na osnovu time() + rand() broj. Tada su nazivi dugi 32 karaktera, recimo ad77affeccaa23921938f899. Uzmeš prvo slovo od naziva fajla i smestiš u taj direktorijum, pa u poddirektorijum koji je drugo slovo, pa tako dalje...

- images/
--------/a/
----------/d/
------------/ad77affeccaa23921938f899

Fin prijedlog. Hvala

Ako i drugi imaju iskustva vezano za ovaj prolbem, bio bih zahvalan da se ukljuce u temu.

Meni bi mozda bilo dovoljan samo jedan podfolder dubinu.

Kôd:

- images
-- kategorija1
--- a
--- b
--- c
...
--- z (+ 0..9)
-- kategorija2
--- a
--- b
--- c
...
--- z (+ 0..9)
 ....


BraMom 27. 01. 2009. 11:05

Ograničenje od 32 k (odnosno 64 k) je ograničenje FAT sistema, to slobodno zaboravi, noviji fajl sistemi mogu bolje.

Na NTFS-u i iole boljim diskovima, do 200 000 fajlova u folderu ne bi smelo da pravi problem.

Moja preporuka je da uz sliku pamtiš "putanju", npr. imaš posebnu tabelu sa opisom "putanje" u kojoj pamtiš gde se to fizički nalazi na disku i kako je spakovano (konvencija za kreiranje podfoldera). Tako da uvek možeš da generišeš full path da bi pročitao konkretan fajl. Jedna od putanja (najnovija) je "aktivna" i na nju se snimaju novi fajlovi. Podfoldere na "putanji" kreiraš kako već u tvom slučaju ima smisla, npr. po kategorijama, po datumu...
Poenta sa putanjama je da sistem bude konfigurabilan, da nemaš hardkodiran način za kreiranje full path-a za snimanje fajla, što ti omogućava bezbolno spajanje "putanja" ili prebacivanje fajlova na novu adresu, tj. neki drugi storidž...

mb_sa 27. 01. 2009. 11:13

Citat:

Originalno napisao BraMom (Napišite 65290)
Ograničenje od 32 k (odnosno 64 k) je ograničenje FAT sistema, to slobodno zaboravi, noviji fajl sistemi mogu bolje.

Na NTFS-u i iole boljim diskovima, do 200 000 fajlova u folderu ne bi smelo da pravi problem.

Moja preporuka je da uz sliku pamtiš "putanju", npr. imaš posebnu tabelu sa opisom "putanje" u kojoj pamtiš gde se to fizički nalazi na disku i kako je spakovano (konvencija za kreiranje podfoldera). Tako da uvek možeš da generišeš full path da bi pročitao konkretan fajl. Jedna od putanja (najnovija) je "aktivna" i na nju se snimaju novi fajlovi. Podfoldere na "putanji" kreiraš kako već u tvom slučaju ima smisla, npr. po kategorijama, po datumu...
Poenta sa putanjama je da sistem bude konfigurabilan, da nemaš hardkodiran način za kreiranje full path-a za snimanje fajla, što ti omogućava bezbolno spajanje "putanja" ili prebacivanje fajlova na novu adresu, tj. neki drugi storidž...

Da, naravno, svakako cu sacuvati putanju, jer jednom je 'izracunam' i korstim, a ne da svaki put je 'racunam' pri prikazu. To stoji, a ako mi bude trebao naziv slike, moze se dobiti putem php basename() funkcije ili da putanju stavljam u posebnu kolonu, što mi u ovom slucaju i ne predstavlja problem, vec kako organizirati foldere i podfoldere sa ciljem da lakse i logicno raspodjelim velikh broj fajlova sa ciljem lakseg backupa i performasni, a na kraju i ogranicenja, jer vjerujm da je lakse pronaci sliku u folderu ako je ih je par hiljada, nego par stotina hiljada.

Hvala na ucescu u temi.

noviKorisnik 27. 01. 2009. 11:17

Možeš da koristiš npr. strukturu od 1000 direktorijuma, po modulu id-ja fajla iz baze
 
Citat:

Originalno napisao mb_sa (Napišite 65287)
Mozes li mi malo detaljnije objasniti, jer nisam bas najbolje shvatio?! Hvala.

Svaka slika je zabeležena u tabeli u bazi, jel, i ima svoj id, kojeg pustiš da ide auto-increment. Ako je id slike recimo 842158 - to znači da će tu sliku smeštaš u direktorijum 158 (to je ostatak od deljenja id-a sa 1000, aka moduo).

Šta je interesantno - imaš 1000 direktorijuma i oni će ravnomerno da se šire kako bude rastao broj slika, biće podjednako opterećeni.

ivanhoe 27. 01. 2009. 11:51

^ ja sam koristio istu tu semu, i fino radi

BTW, ext2 i ext3 imaju problem sa vecim brojem fajlova, dolazi do usporenja... ali do par hiljada fajlova po dir-u nije problem sigurno, sem ako fajlovima pristupas sekvencijalno (listas direktorijum ili tako nesto)

LiquidBrain 27. 01. 2009. 12:05

ext3 filesystem ima ogranicenje po defaultu na 32K linkova (fajlova, direktorijuma) po folderu. To je josh ograniceno sa limitom maksimalnog broja inodova za taj filesystem.

mb_sa 27. 01. 2009. 13:00

Ljudi, hvala na odgovorima. Bilo je vise nego od pomoci.

Najvjerovatnije će korstiti strukturu od 1000 foldera, čini mi se kao super rješenje, a još vidim da neki koriste u praksi, tako da ...

Hvala jos jednom.

lp,
mb

bluesman 27. 01. 2009. 13:20

Citat:

Originalno napisao LiquidBrain (Napišite 65297)
ext3 filesystem ima ogranicenje po defaultu na 32K linkova (fajlova, direktorijuma) po folderu. To je josh ograniceno sa limitom maksimalnog broja inodova za taj filesystem.

Mene je skoro cimn'o jedan sysadmin kao "daj sta da radimo sa ovim direktorijumom, ima ok 7,5 miliona fajlova u tom direktorijumu". E sad, ako je on mene palio - palim i ja vas, ali znam da smo morali da napraivmo tool koji je premestao fajlove u poddirektorijume.

(to je nesto zaostalo od nekog projekta koji je nasledjen, odiclgedno je postojao bug koji nije brisao te temp fajlove, a niko ne vodi racuna o tom sajtu vec godinu dana)

srdjan 27. 01. 2009. 16:17

A sta ako je slika/fajl vezana za jednog konkretnog korisnika... gde je ukupan broj korisnika (foldera) >>> broja fajlova svakog pojedinacnog, npr. galerija slika na facebook.

/p/pe/pera/
...
/m/ma/maja/
/m/ma/maja/fajl1.jpg
...
/m/mi/mika/
/m/mi/mika/fajl1.jpg
/m/mi/mika/fajl2.jpg
...

Imena fajl1, fajl2 su slucajna, najcesce su "realna imena" npr. mojaslika.jpg, mogu biti ista ali i ne moraju. Da li ovakva struktura ima neke skrivene zamke ?

noviKorisnik 27. 01. 2009. 16:53



(... to je jedna fotka sa FB. Adresa je:

Kôd:

http://photos-c.ak.fbcdn.net/photos-ak-snc1/v2076/153/61/545478327/n545478327_1201338_6898.jpg
... teško da će imena fajlova fotki u bilo kom veeelikom sistemu imati veze sa realnim imenima tipa 'mojaslika.jpg' jer se to vrlo lako zakomplikuje (pojavi se već postojeće ime 'beznaslova.jpg'...

jablan 27. 01. 2009. 18:20

Off Topic: ^ Mogao si neku inspirativniju da nađeš... :(

srdjan 27. 01. 2009. 20:14

OK, ideja je bila da i ime foldera (korisnika) ucesvuje u obrazovanju "jednoznacnosti fajla".

bluesman 27. 01. 2009. 20:52

Off Topic:
Citat:

Originalno napisao jablan (Napišite 65347)
Off Topic: ^ Mogao si neku inspirativniju da nađeš... :(

Zato ja u naming convention unosim i kakve slike i tekstovi mogu da se koriste kao primeri, ovo kod mene ne bi proslo :)

kodi 27. 01. 2009. 22:01

u doba kad se mnogo crawl-ovalo dobijem ja "brilijantnu" ideju da saw raw data koji generisu crawleri strpam u folder strukturu tipa aa/aa/aaaade4566547576867.txt
gde je ovaj filename md5 od url-a...

za write se pokazalo fenomenalno.. performanse izvanredne... :)
takodje za read/delete jednog elementa je ultra fast..

ALI, kada je trebalo obrisati, ili nedaj boze tarovati celu strukturu....
(tamo negde posle par miliona upisa) uf, to je znalo da traje bas dugo.

Tako da je to mozda ok resenje za slike - tamo ces tesko imati brisanje/pomeranje cele strukture, medjutim backup i brisanje moze da bude prilichno zajebana rabota...

takodje ne znam kako bi se rsync izborio sa sinhronizacijom tolike strukture, a i mene to trenutno zanima...


Vreme je GMT +2. Trenutno vreme je 02:47.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.