Ik kan hier alleen voor MongoDB antwoorden, ik zal niet doen alsof ik veel weet over HDFS en andere soortgelijke technologieën.
De GridFs-implementatie is volledig client-side binnen de driver zelf. Dit betekent dat er geen speciaal laden of begrip is van de context van bestandsserving binnen MongoDB zelf, in feite begrijpt MongoDB zelf niet eens dat het bestanden zijn ( http://docs.mongodb.org/manual/applications/gridfs/).
Dit betekent dat het opvragen van een deel van de files of chunks verzameling resulteert in hetzelfde proces als voor elke andere zoekopdracht, waarbij het de benodigde gegevens in uw werkset laadt ( http://en.wikipedia.org/wiki/Working_set ) die een set gegevens (of alle geladen gegevens op dat moment) vereist door MongoDB binnen een bepaald tijdsbestek om optimale prestaties te behouden. Het doet dit door het in het RAM-geheugen te plaatsen (technisch gezien doet het besturingssysteem dat).
Een ander punt om rekening mee te houden is dat dit een driver is die is geïmplementeerd. Dit betekent dat de specificatie kan variëren, maar ik denk niet dat dit het geval is. Met alle stuurprogramma's kunt u een reeks documenten opvragen uit de files verzameling die alleen de metagegevens van de bestanden bevat, zodat u later het bestand zelf kunt bedienen vanuit de chunks verzameling met een enkele zoekopdracht.
Dat is echter niet het belangrijkste, u wilt het bestand zelf bedienen, inclusief de gegevens; dit betekent dat je de files . gaat laden collectie en de daaropvolgende chunks verzameling in uw werkset.
Met dat in gedachten hebben we het eerste probleem al bereikt:
Worden bestanden van gridfs gecached in ram en hoe beïnvloedt dit de lees-schrijfprestaties?
De leesprestaties van kleine bestanden kunnen geweldig zijn, rechtstreeks vanuit RAM; het schrijven zou net zo goed zijn.
Voor grotere bestanden, niet zo. De meeste computers hebben geen 600 GB RAM en het is waarschijnlijk, heel normaal, om een 600 GB partitie van een enkel bestand op een enkele mongod te plaatsen. voorbeeld. Dit creëert een probleem omdat dat bestand, om te worden bediend, in uw werkset moet passen, maar het is onmogelijk groter dan uw RAM; op dit punt zou je pagina-thrashing kunnen hebben ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) waarbij de server gewoon 24/7 paginafouten maakt en probeert het bestand te laden. De teksten hier zijn ook niet beter.
De enige manier om dit te omzeilen is door een enkel bestand over meerdere scherven te plaatsen :\ .
Opmerking:nog iets om te overwegen is dat de standaard gemiddelde grootte van een chunks "chunk" is 256 KB, dus dat zijn veel documenten voor een bestand van 600 GB. Deze instelling kan in de meeste stuurprogramma's worden gemanipuleerd.
Wat gebeurt er met gridfs als ik probeer om enkele bestanden tegelijkertijd te schrijven. Zal er een vergrendeling zijn voor lees-/schrijfbewerkingen? (Ik gebruik het alleen als bestandsopslag)
GridFS, dat slechts een specificatie is, gebruikt dezelfde vergrendelingen als op elke andere verzameling, zowel lees- als schrijfvergrendelingen op databaseniveau (2.2+) of op globaal niveau (pre-2.2). De twee interfereren ook met elkaar, d.w.z. hoe kunt u zorgen voor een consistente lezing van een document waarnaar wordt geschreven?
Dat gezegd hebbende, bestaat de mogelijkheid van twist op basis van uw scenariospecificaties, verkeer, aantal gelijktijdige schrijf-/leesbewerkingen en vele andere dingen waar we geen idee van hebben.
Misschien zijn er nog andere oplossingen die mijn probleem efficiënter kunnen oplossen?
Ik heb persoonlijk ontdekt dat S3 (zoals @mluggy zei) in gereduceerd redundantieformaat het beste werkt door slechts een deel van de metagegevens over het bestand in MongoDB op te slaan, net zoals het gebruik van GridFS, maar zonder de chunks-verzameling, laat S3 al die distributie, back-up en andere dingen voor jou.
Hopelijk ben ik duidelijk geweest, ik hoop dat het helpt.
Bewerken:in tegenstelling tot wat ik per ongeluk zei, heeft MongoDB geen vergrendeling op verzamelingsniveau, het is een vergrendeling op databaseniveau.