Jeg kan kun svare for MongoDB her, jeg vil ikke lade som om, jeg ved meget om HDFS og andre sådanne teknologier.
GridFs-implementeringen er fuldstændig klientsiden i selve driveren. Dette betyder, at der ikke er nogen særlig indlæsning eller forståelse af konteksten for filservering i selve MongoDB, faktisk forstår MongoDB ikke selv, at de er filer ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Dette betyder, at forespørgsel efter enhver del af files eller chunks indsamling vil resultere i den samme proces, som den ville gøre for enhver anden forespørgsel, hvorved den indlæser de data, den har brug for i dit arbejdssæt ( http://en.wikipedia.org/wiki/Working_set ), som repræsenterer et sæt data (eller alle indlæste data på det tidspunkt) krævet af MongoDB inden for en given tidsramme for at opretholde optimal ydeevne. Det gør det ved at indlæse det i RAM (vel teknisk set gør OS det).
Et andet punkt at tage i betragtning er, at dette er driverimplementeret. Det betyder, at specifikationen kan variere, dog tror jeg ikke den gør. Alle drivere giver dig mulighed for at forespørge efter et sæt dokumenter fra files samling, som kun huser filernes metadata, så du senere kan servere selve filen fra chunks samling med en enkelt forespørgsel.
Men det er ikke det vigtige, du vil tjene selve filen, inklusive dens data; det betyder, at du vil indlæse files samling og dens efterfølgende chunks indsamling i dit arbejdssæt.
Med det i tankerne har vi allerede ramt den første hage:
Bliver filer fra gridfs cachelagret i ram, og hvordan vil det påvirke læse-skriveydelsen?
Læseydelsen af små filer kunne være fantastisk, direkte fra RAM; skriverierne ville være lige så gode.
For større filer, ikke så. De fleste computere vil ikke have 600 GB RAM, og det er sandsynligt, faktisk ret normalt, at huse en 600 GB partition af en enkelt fil på en enkelt mongod eksempel. Dette skaber et problem, da den fil, for at blive serveret, skal passe ind i dit arbejdssæt, men den er umuligt større end din RAM; på dette tidspunkt kunne du have sidetrashing ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ), hvorved serveren bare fejler siden 24/7 og prøver at indlæse filen. Skriverne her er heller ikke bedre.
Den eneste måde at undgå dette på er at begynde at lægge en enkelt fil på tværs af mange shards :\ .
Bemærk:en ting mere at overveje er, at standardgennemsnitsstørrelsen for en chunks "chunk" er 256KB, så det er mange dokumenter for en 600GB fil. Denne indstilling kan manipuleres i de fleste drivere.
Hvad sker der med gridfs, når jeg prøver at skrive få filer samtidigt. Vil der være nogen lås til læse/skrive-operationer? (Jeg vil kun bruge det som fillagring)
GridFS, som kun er en specifikation, bruger de samme låse som på enhver anden samling, både læse- og skrivelåse på et databaseniveau (2.2+) eller på et globalt niveau (før-2.2). De to forstyrrer også hinanden, dvs. hvordan kan du sikre en konsekvent læsning af et dokument, der skrives til?
Når det er sagt, eksisterer muligheden for strid baseret på dine scenariespecifikationer, trafik, antal samtidige skrivninger/læsninger og mange andre ting, vi ikke aner.
Måske er der nogle andre løsninger, der kan løse mit problem mere effektivt?
Jeg har personligt fundet ud af, at S3 (som @mluggy sagde) i reduceret redundans-format fungerer bedst til at gemme en ren del af metadata om filen i MongoDB, ligesom at bruge GridFS, men uden chunks-samlingen, lad S3 håndtere al den distribution, backup og andre ting til dig.
Forhåbentlig har jeg været klar, håber det hjælper.
Edit:I modsætning til hvad jeg ved et uheld sagde, har MongoDB ikke en samlingsniveaulås, det er en databaseniveaulås.