Jag kan bara svara för MongoDB här, jag kommer inte att låtsas att jag vet mycket om HDFS och andra sådana teknologier.
GridFs-implementeringen är helt och hållet klientsidan inom själva drivrutinen. Detta betyder att det inte finns någon speciell laddning eller förståelse av sammanhanget för filservering inom MongoDB själv, i själva verket förstår MongoDB inte ens att de är filer ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Detta innebär att fråga efter någon del av files eller chunks insamlingen kommer att resultera i samma process som den skulle göra för alla andra frågor, varvid den laddar in den data den behöver till din arbetsuppsättning ( http://en.wikipedia.org/wiki/Working_set ) som representerar en uppsättning data (eller alla laddade data vid den tiden) som krävs av MongoDB inom en given tidsram för att bibehålla optimal prestanda. Det gör det genom att växla in det i RAM-minnet (tekniskt sett gör OS det).
En annan punkt att ta hänsyn till är att detta är drivrutinsimplementerat. Det gör att specifikationen kan variera, det tror jag dock inte att det gör. Alla drivrutiner tillåter dig att fråga efter en uppsättning dokument från files samling som bara innehåller filernas metadata så att du senare kan servera själva filen från chunks samling med en enda fråga.
Men det är inte det viktiga, du vill visa själva filen, inklusive dess data; detta betyder att du kommer att ladda files samling och dess efterföljande chunks samling i ditt arbetsset.
Med det i åtanke har vi redan drabbats av det första problemet:
Kommer filer från gridfs att cachas i ram och hur det kommer att påverka läs-skrivprestanda?
Läsprestandan för små filer kan vara fantastisk, direkt från RAM; skrivningarna skulle vara lika bra.
För större filer, inte så. De flesta datorer kommer inte att ha 600 GB RAM och det är sannolikt, ganska normalt faktiskt, att hysa en 600 GB partition av en enda fil på en enda mongod exempel. Detta skapar ett problem eftersom den filen, för att kunna visas, måste passa in i din arbetsuppsättning men den är omöjligt större än ditt RAM-minne; vid det här tillfället kan du ha page thrashing ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) där servern bara har fel på sidan dygnet runt och försöker ladda filen. Skrivningarna här är inte heller bättre.
Det enda sättet runt detta är att börja lägga en enda fil över många skärvor :\ .
Notera:en sak till att tänka på är att den genomsnittliga standardstorleken för en chunks "chunk" är 256KB, så det är många dokument för en 600GB fil. Denna inställning är manipulerbar i de flesta drivrutiner.
Vad kommer att hända med gridfs när jag försöker skriva några filer samtidigt. Kommer det att finnas något lås för läs-/skrivoperationer? (Jag kommer bara att använda det som fillagring)
GridFS, eftersom det bara är en specifikation, använder samma lås som på alla andra samlingar, både läs- och skrivlås på en databasnivå (2.2+) eller på global nivå (före 2.2). De två stör varandra också, d.v.s. hur kan du säkerställa en konsekvent läsning av ett dokument som skrivs till?
Med det sagt finns möjligheten för tvist baserat på dina scenariospecifikationer, trafik, antal samtidiga skrivningar/läsningar och många andra saker som vi inte har någon aning om.
Kanske finns det några andra lösningar som kan lösa mitt problem mer effektivt?
Jag har personligen funnit att S3 (som @mluggy sa) i reducerat redundansformat fungerar bäst med att lagra bara en del metadata om filen i MongoDB, ungefär som att använda GridFS men utan chunks-samlingen, låt S3 hantera all den distributionen, säkerhetskopieringen och andra saker för dig.
Förhoppningsvis har jag varit tydlig, hoppas det hjälper.
Edit:Till skillnad från vad jag av misstag sa, har MongoDB inte ett samlingsnivålås, det är ett databasnivålås.