Ik ontwikkel een nieuwe website en ik wil GridFS gebruiken als opslag voor alle gebruikersuploads, omdat het veel voordelen biedt ten opzichte van een normale bestandssysteemopslag.
Benchmarks met GridFS bediend door nginx geven aan dat het niet zo snel is als een normaal bestandssysteem dat door nginx wordt bediend.
Is er iemand die GridFS al in een productieomgeving gebruikt of het voor een nieuw project zou gebruiken?
Antwoord 1, autoriteit 100%
Ik gebruik gridfs op het werk op een van onze servers, die deel uitmaakt van een prijsvergelijkende website met betrouwbare verkeersstatistieken (ongeveer 25.000 bezoekers per dag). De server heeft niet veel ram, 2gigs, en zelfs de cpu is niet echt snel (Core 2 duo 1.8Ghz) maar de server heeft genoeg opslagruimte: 10Tb (sata) in raid 0 configuratie. Het werk dat de server doet is heel eenvoudig:
Elk product op onze prijsvergelijker heeft een afbeelding (er zijn ongeveer 10 miljoen producten volgens onze product-db), en de taak van de server is om de afbeelding te downloaden, het formaat te wijzigen, op te slaan op gridfs en af te leveren aan de bezoekersbrowser… als het niet in het raster aanwezig is… of… lever het aan de bezoekersbrowser als het al in het raster is opgeslagen. Dit zou dus een ‘traditioneel cdn-schema’ kunnen worden genoemd.
We hebben 4 miljoen afbeeldingen op deze server opgeslagen en verwerkt sinds deze in gebruik is. Het formaat wijzigen en opslaan wordt gedaan door een eenvoudig php-script… maar een python-script of iets als java kan zeker sneller zijn.
Huidige gegevensgrootte: 11,23 g
Huidige opslaggrootte: 12,5 g
Indices: 5
Indexgrootte: 849,65 m
Over de betrouwbaarheid: dit is zeer betrouwbaar. De server laadt niet, de indexgrootte is ok, zoekopdrachten zijn snel
Over de snelheid: is het zeker niet snel als lokale bestandsopslag, misschien 10% langzamer, maar snel genoeg om in realtime te worden gebruikt, zelfs wanneer de afbeelding moet worden verwerkt, wat in ons geval erg php-afhankelijk is . Onderhouds- en ontwikkelingstijden zijn ook verminderd: het werd zo eenvoudig om één of meerdere afbeeldingen te verwijderen: vraag de db gewoon op met een eenvoudig verwijdercommando. Nog iets interessants: toen we onze oude server herstartten, met lokale bestandsopslag (dus miljoenen bestanden in duizenden mappen), bleef hij soms uren hangen omdat het systeem een controle van de bestandsintegriteit uitvoerde (dit duurde echt uren…). We hebben dit probleem niet meer met gridfs, onze afbeeldingen worden nu opgeslagen in grote mongodb chunks (2GB bestanden)
Dus… in mijn gedachten… Ja, gridfs is snel en betrouwbaar genoeg om voor productie te worden gebruikt.
Antwoord 2, autoriteit 10%
Zoals gezegd, is het misschien niet zo snel als een gewoon bestandssysteem, maar het geeft je voordelen ten opzichte van gewone bestandssystemenwaarvan ik denk dat het de moeite waard is om wat snelheid op te geven.
Uiteindelijk zou je met sharding een punt kunnen bereiken waarop de GridFS-opslag de snellere optie wordt in plaats van een gewoon bestandssysteem en een enkel knooppunt.
Antwoord 3, autoriteit 5%
Maar let op reparaties voor grotere DB’s – een nieuw systeem dat we aan het ontwikkelen zijn, Mongo is niet netjes afgesloten en het lijkt erop dat het repareren van de 7TB GridFS 130 uur zal duren.
Hierdoor denk ik dat ik ga overwegen om over te stappen op OpenStack Swift of Ceph.
Toch was het tot die tijd goed. En de nginx-gridfs-module is lief.
Antwoord 4, autoriteit 4%
mdirolf’s nginx-gridfs-module is geweldig en redelijk eenvoudig te installeren. We gebruiken het in productie bij paint.lyom alle schilderijen te bedienen en er zijn tot nu toe geen problemen geweest.
Antwoord 5, autoriteit 2%
Ik raad het gebruik van gridfs niet aan, tenzij je weet wat je doet.
GridFS is slechts een abstractielaag die bestanden splitst voor chunks en de bestanden opslaat in twee collecties. Meer bestanden – meer overhead. Als u verwacht dat bestanden ongeveer even groot zijn, niet groter dan 32M of zo, bent u op de goede weg.
Probeer geen grote bestanden op gridfs op te slaan. Waarom?
- Drivers in verschillende talen kunnen het hele bestand lezen (bijv. chunks) bij het lezen van het kleine deel van het bestand.
- Het wijzigen van het bestand kan van invloed zijn op alle chunks en de belasting van de database verhogen
Als uw bestandssysteem opgroeit, moet u beslissen om de gridfs te sharden. Wees voorzichtig! Consistentie is niet gegarandeerd wanneer sharding wordt geïnitialiseerd!
Als u denkt aan een read-loaded project, overweeg dan om de bestanden rechtstreeks in documenten te laden (indien 16M of minder groot) of kies een andere clusterfs en koppel bestandsnaam/inode aan uw logica.
Hopelijk helpt dit.