Jag använder gridfs på jobbet på en av våra servrar som är en del av en prisjämförande webbplats med hedervärd trafikstatistik (cirka 25 000 besökare per dag). Servern har inte mycket ram, 2 gig, och till och med CPU:n är inte riktigt snabb (Core 2 duo 1,8Ghz) men servern har gott om lagringsutrymme:10Tb (sata) i raid 0-konfiguration. Jobbet som servern gör är väldigt enkelt:
Varje produkt på vår prisjämförare har en bild (det finns cirka 10 miljoner produkter enligt vår produktdb), och servrarnas uppgift är att ladda ner bilden, ändra storlek på den, lagra den på gridfs och leverera den till besökarens webbläsare. .. om det inte finns i rutnätet... eller... leverera det till besökarnas webbläsare om det redan är lagrat i rutnätet. Så detta kan kallas ett "traditionellt cdn-schema".
Vi har lagrat och bearbetat 4 miljoner bilder på denna server sedan den är igång. Ändra storlek och lagra saker görs av ett enkelt php-skript... men förvisso kan ett python-skript eller något som java vara snabbare.
Aktuell datastorlek:11,23g
Aktuell lagringsstorlek:12,5 g
Index :5
Indexstorlek:849,65 m
Om tillförlitligheten:Detta är mycket tillförlitligt. Servern laddas inte, indexstorleken är ok, frågorna är snabba
Om hastigheten:Visst, är det inte snabbt som lokal fillagring, kanske 10% långsammare, men tillräckligt snabbt för att användas i realtid även när bilden behöver bearbetas, vilket i vårt fall är väldigt php-beroende. Underhålls- och utvecklingstider har också minskat:det blev så enkelt att ta bort en enstaka eller flera bilder:fråga bara i db med ett enkelt raderingskommando. En annan intressant sak:när vi startade om vår gamla server, med lokal fillagring (så miljoner filer i tusentals mappar), hänger den ibland i timmar eftersom systemet utförde en filintegritetskontroll (detta tog verkligen timmar...). Vi har inte det här problemet längre med gridfs, våra bilder är nu lagrade i stora mongodb-bitar (2gb-filer)
Så... i mina tankar... Ja, gridfs är tillräckligt snabbt och pålitligt för att användas för produktion.