WN - Många file i en mapp

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Många file i en mapp (https://www.wn.se/forum/showthread.php?t=14879)

Lundmark

2006-06-28 22:19

Hej

Om man har 100.000 bilder i en mapp eller 100 mappar med 1000 bilder i varje, gör det någon skilnad i prestanda?

// Erik

jocke4u

2006-06-28 22:27

Rent generellt tror jag inte det spelar någon roll men om du skall lista 100.000 filer i en katalog (t.ex. med kommandopromt eller Windows Explorer) så lär det gå mycket snabbare med en hierarki med submappar. Men att systemet skulle gå långsammare tror jag inte.

zoran

2006-06-28 22:34

Citat:

Originally posted by Lundmark@Jun 28 2006, 21:19
Hej

Om man har 100.000 bilder i en mapp eller 100 mappar med 1000 bilder i varje, gör det någon skilnad i prestanda?

// Erik

Det beror på OS och på filsystem.

Blackex

2006-06-29 08:53

Jag skulle nog dela upp dem i mappar (om det är möjligt). Filsystem i allmänhet är inte byggda för att alla filer skall hamna i en mapp. Flera mappar kan även underlätta backuper och sökningar. Det hela beror på användningsområdet.

Ett alternativ är att stoppa in bilderna i en databas som BLOBar (Binary Large Objects). Då kan du även accessa bilderna från andra datorer utan stora problem. Backuper blir ännu lättare. Du kan lägga på en massa attribut till dina bilder (nyckelkord, titel, beskrivning, när bilden togs, när bilden uppdaterades, vem som uppdaterade bilden etc). Fördelarna med databas är många!

hnn	2006-06-29 11:02

ReiserFS på under Linux vet jag att det enbart kan hantera ynka ~33000 samtidiga filer i katalog.

Däremot, NTFS kan hantera det mindre blygsamma 4,294,967,295 filer eller kataloger per katalog (2^32 filer minus 1 fil)

Däremot:
NTFS < 5 vet jag att det enbart kan hantera 255 kataloger i ett rakt led neråt...
NTFS > 5 vet jag inte, har inte hunnit testa...

Prestandan i den 255 katalogen är sisådär.. Inget o rekommendera o använda i produktionsmiljö.

EDIT:
Hittade däremot denna:

Citat:

anything above 50,000 will cause problems, I work with very large file systems, we usually break it down to 2000- files per folder (we use day/hour/minute directory structure, and seconds if necesary)

Lundmark

2006-06-29 14:38

Citat:

Ursprungligen postat av zoran

Citat:

Ursprungligen postat av Lundmark

Hej

Om man har 100.000 bilder i en mapp eller 100 mappar med 1000 bilder i varje, gör det någon skilnad i prestanda?

// Erik

Det beror på OS och på filsystem.

Det är en linuxmaskin med CentOS

Lundmark

2006-07-02 23:01

Citat:

ett alternativ är att stoppa in bilderna i en databas som BLOBar

Jag har läst lite om det både
här och på andra forum. Många är neggativa till det... gäller det även 2006?

eg0master

2006-07-02 23:44

Det beror mig veterligen mycket på vad du ska göra med filerna.
Sökningar och listningar av kataloger kan lida en del, medans direkt access till filerna (om du känner till hela namnen) inte påverkas i samma utsträckning om allt ligger i samma katalog.

jonny

2006-07-03 00:03

Citat:

Originally posted by Blackex@Jun 29 2006, 07:53

Ett alternativ är att stoppa in bilderna i en databas som BLOBar (Binary Large Objects). Då kan du även accessa bilderna från andra datorer utan stora problem. Backuper blir ännu lättare. Du kan lägga på en massa attribut till dina bilder (nyckelkord, titel, beskrivning, när bilden togs, när bilden uppdaterades, vem som uppdaterade bilden etc). Fördelarna med databas är många

Ingen bra lösning ur prestandasynpunkt. Lagra metadata i databasen och filer på disk.

jimmie

2006-07-03 00:16

Citat:

Originally posted by Lundmark@Jul 2 2006, 23:01

Citat:

ett alternativ är att stoppa in bilderna i en databas som BLOBar

Jag har läst lite om det både
här och på andra forum. Många är neggativa till det... gäller det även 2006?

Ja det gäller fortfarande år 2006.

Till trådskaparen: Dela upp i mappar...

Blackex

2006-07-03 13:34

Citat:

Originally posted by jonny@Jul 2 2006, 23:03
Ingen bra lösning ur prestandasynpunkt. Lagra metadata i databasen och filer på disk.

Det beror på vilka behov som finns.

Fördel med bilder i databas: Transaktionerna är Atomära A, Konsistensbevarande C, Isolerade I och Hållbara D = ACID
Nackdel med bilder i databas: Prestanda

http://www.extremeexperts.com/SQL/FAQ/StoreImages.aspx

zoran

2006-07-03 15:48

Citat:

Ursprungligen postat av Blackex

Citat:

Ursprungligen postat av jonny

Ingen bra lösning ur prestandasynpunkt. Lagra metadata i databasen och filer på disk.

Ptja, buzzwords buzzwords.

Det går att uppnå samma "syrlighet" även med rätt språk, rätt felhantering, rätt tabellkonstruktion och bilder som filer.

Se följande pseudokod:

Kod:



try {

  connection.beginTransaction();

  int imageid = insert_data_intoDb(image);

  store_image_file(image);

  connection.commit();

} catch ( java.sql.SQLException e){

  if ( connection != null ){

    connection.rollback();

  }

} catch ( java.io.IOException ex ){

  if ( connection != null ){

    connection.rollback();

  }

  if ( checkFile(imageid) ){

    removeFile(imageid);

  }

}

Så, om någon av momenten går fel, inget händer. Dvs din operation är rätt säker för inkonsistens.

/Zoran

Blackex

2006-07-03 16:15

Citat:

Originally posted by zoran@Jul 3 2006, 14:48
Det går att uppnå samma "syrlighet" även med rätt språk, rätt felhantering, rätt tabellkonstruktion och bilder som filer.

Du har rätt, men...

Vad händer exempelvis när
- du får hög belasting och måste spegla bilderna till flera datorer.
- du vill göra en inkrementell backup
- när du av misstag råkar ta bort en bild och motsvarande rad i tabellen finns kvar.

Med din lösning blir du tvungen att bygga funktionalitet för att hantera ovanstående situationer. Funktionalitet som redan finns i de flesta databaser.

zoran

2006-07-03 16:57

Citat:

Ursprungligen postat av Blackex

Citat:

Ursprungligen postat av zoran

Det går att uppnå samma "syrlighet" även med rätt språk, rätt felhantering, rätt tabellkonstruktion och bilder som filer.

Spegling av bilder sker mycket enklare på filsystemsbasis eller tom via skript än att blanda in ett helt annat middleware som är bra på att vara databas.

Inkrementell backup är ju också lättare att göra från ett filsystem än att hålla på att bläddra i databasen.

Ja, visst den tredje punkten kan jag acceptera som motargument.

Blackex

2006-07-03 17:40

Citat:

Inkrementell backup är ju också lättare att göra från ett filsystem än att hålla på att bläddra i databasen.

I MySQL är det bara att koppla på den binära loggen. Inget mer behöver göras. Vet ej vad du menar med bläddra i databasen.

Även om det är lättare att göra inkrementell backup från ett filsystem så kvarstår problematiken med att se till att filerna och databasen är i synk.

kullervo

2006-07-03 23:55

Citat:

Originally posted by hnn@Jun 29 2006, 09:02
ReiserFS på under Linux vet jag att det enbart kan hantera ynka ~33000 samtidiga filer i katalog.

Om filsystemet kör enkla hash-tabeller över filnamnen (ext2/ext3 t.ex.) ökar accesstiden till filerna exponensiellt med antalet filer i en katalog. Kör man däremot ett filsystem som har någon form av träd-algoritm för filnamnen (reiserfs, xfs etc) kan man ösa på med bra mycket fler filer i en katalog innan det blir segt. Hans Reisen själv säger att ReiserFS (åtminstonde 3.6 och senare) klarar av 100.000 filer i en om samma katalog utan att accesstiderna blir märkbara. Jag brukar inte lägga mer än 10.000 filer i samma katalog.

Alla tider är GMT +2. Klockan är nu 18:45.