[Blackex]

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]

Ursprungligen postat av Blackex

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

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:

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]

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]

Ursprungligen postat av Blackex

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.

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]

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]

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.