/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Databasesystem med håndtering af BLOB's
Fra : Jack Petersen


Dato : 02-11-04 15:29



 
 
Troels Arvin (02-11-2004)
Kommentar
Fra : Troels Arvin


Dato : 02-11-04 15:43

On Tue, 02 Nov 2004 15:28:59 +0100, Jack Petersen wrote:

> Jeg sidder pt. med et projekt hvor jeg mangler lidt input vedr. en
> database der skal kunne håndterer meget store datafiler (100++ MB).

_Så_ store BLOBs skal man have meget særlige grunde til at lægge i
DBMSet, vil jeg mene. Hvad er det for data?

--
Greetings from Troels Arvin, Copenhagen, Denmark


Jack Petersen (02-11-2004)
Kommentar
Fra : Jack Petersen


Dato : 02-11-04 16:49



Troels Arvin (02-11-2004)
Kommentar
Fra : Troels Arvin


Dato : 02-11-04 17:32

On Tue, 02 Nov 2004 16:48:31 +0100, Jack Petersen wrote:

> Det er primært billeder i forskellige formater. Og den særlige grund til
> at det ville være atraktivt er at DB'en er ACID i modsætning til
> filsystemet og det er næmmere at tage backup.

ACID og andre DBMS-karakteristika er absolut rart at arbejde med. Og med
servere, der bliver kraftigere og kraftigere, er det da også ofte
interessant at proppe kæmpe dataklumper i DBMSer.

Jeg synes blot, at 100MB er i overkanten. Det skal sammenlignes med de
muligheder, der typisk findes ved at have data liggende som rå filer:
Hvis det fx. er data, der skal overføres via web'et, vil en webserver
kunne optimere på flere leder, hvis rå filer afsendes. Det kan fx. dreje
sig om zero-copy udsendelse af filer (kortest mulige vej fra disk til
netkort); den slags er der mindre chance for, hvis data skal via en
database-protokol (inkl. de buffere, der måtte være involverede) først.

- Men dette er jo løs snak. Kan nogen mon komme med en mere rationel
grænse for, hvornår det begynder at gøre rigtig ondt at benytte BLOBs
vs. rå filer?

--
Greetings from Troels Arvin, Copenhagen, Denmark


Jesper Krogh (02-11-2004)
Kommentar
Fra : Jesper Krogh


Dato : 02-11-04 18:39

I dk.edb.database, skrev Troels Arvin:
> - Men dette er jo løs snak. Kan nogen mon komme med en mere rationel
> grænse for, hvornår det begynder at gøre rigtig ondt at benytte BLOBs
> vs. rå filer?

Hæld dem ind i databasen og se om det er acceptabelt. Det var min
tilgangsvinkel. Med PostgreSQL fandt jeg endda ud af at det
hastighedsmæssigt ikke berørte mine queries overhovet og da BLOB'en kun
sjældent blev tilgået, så var det skønnest at have dem der. (I stedet
for at skulle sikre overensstemmelse med et filsystem også).

--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabbernet.dk


Jesper Sommer (03-11-2004)
Kommentar
Fra : Jesper Sommer


Dato : 03-11-04 17:44

Hvorfor ikke opfinde et "dokument" begreb i databasen, som kan linke til et
eksternt fil arkiv ? Det er jo tæske-nemt at få din applikation til at
behandle et link som er læst fra databasen ?

Bevares der er fordele ved at gemme det i basen - men også ulemper. Hvad nu
når din DBMS leverandør ikke supporterer fysiske segmenter over en vis
størelse ? Eller hvad når du laver nye felter i dine tabeller, og skal
genopbygge (rebuild) databasen senere for at optimere performance og undgå
fragmentering ? Hvordan ser transaktionsloggen ud for din DBMS hvis du
ændrer 4-5 BLOPs af 100 MB (gemmes de også i loggen, eller gør de ikke) ?
Kan du lægge dine BLOPs på et andet fysisk device end dine øvrige tabeller ?
Eller måske i en helt anden database ?

Jeg vil ikke være nervøs for at gemme 1x100 MB i mine baser. Men jeg ville
være nervøs for at gemme 100x100 MB i min database ... eller endnu flere ...
hvis ikke der var en rigtig god grund til det ... bedre end "mere
bekvemmeligt kode" ...



- Jesper



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408924
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste