Zde mohu odpovědět pouze za MongoDB, nebudu předstírat, že toho hodně vím o HDFS a dalších podobných technologiích.
Implementace GridFs je zcela na straně klienta v rámci samotného ovladače. To znamená, že neexistuje žádné zvláštní načítání nebo chápání kontextu poskytování souborů v rámci samotné MongoDB, ve skutečnosti MongoDB sám ani nechápe, že se jedná o soubory ( http://docs.mongodb.org/manual/applications/gridfs/ ).
To znamená, že dotazování na jakoukoli část files nebo chunks sběr bude mít za následek stejný proces jako u jakéhokoli jiného dotazu, přičemž data, která potřebuje, načte do vaší pracovní sady ( http://en.wikipedia.org/wiki/Working_set ), která představuje sadu dat (nebo všechny načtená data v té době) požadované MongoDB v daném časovém rámci k udržení optimálního výkonu. Dělá to stránkováním do RAM (dobře technicky to OS dělá).
Dalším bodem, který je třeba vzít v úvahu, je, že se jedná o implementovaný ovladač. To znamená, že specifikace se může lišit, ale nemyslím si, že tomu tak je. Všechny ovladače vám umožní dotazovat se na sadu dokumentů ze files kolekce, která obsahuje pouze metadata souborů, což vám umožní později obsluhovat samotný soubor z chunks kolekce s jediným dotazem.
To však není to podstatné, chcete obsloužit samotný soubor včetně jeho dat; to znamená, že budete načítat files kolekce a její následné chunks sběr do vaší pracovní sady.
S ohledem na to jsme již narazili na první zádrhel:
Budou soubory z gridfs ukládány do mezipaměti v paměti RAM a jak to ovlivní výkon čtení a zápisu?
Čtení malých souborů může být úžasné, přímo z RAM; zápisy by byly stejně dobré.
U větších souborů tomu tak není. Většina počítačů nebude mít 600 GB RAM a je pravděpodobné, ve skutečnosti docela normální, umístit 600GB oddíl jednoho souboru na jeden mongod instance. To vytváří problém, protože tento soubor, aby mohl být obsluhován, se musí vejít do vaší pracovní sady, je však nemožně větší než vaše RAM; v tomto okamžiku můžete mít stránku mlátit ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ), kdy server pouze chybuje stránku 24/7 a pokouší se načíst soubor. Ani zde nejsou o nic lepší.
Jediný způsob, jak to obejít, je začít vkládat jeden soubor přes mnoho útržků :\ .
Poznámka:Ještě jedna věc, kterou je třeba vzít v úvahu, je výchozí průměrná velikost chunks "kus" je 256 kB, takže to je hodně dokumentů na 600GB soubor. Toto nastavení je manipulovatelné ve většině ovladačů.
Co se stane s gridfs, když se pokusím napsat několik souborů současně. Bude existovat nějaký zámek pro operace čtení/zápisu? (budu ho používat pouze jako úložiště souborů)
GridFS, protože je pouze specifikací, používá stejné zámky jako na jakékoli jiné kolekci, zámky pro čtení i zápis na úrovni databáze (2.2+) nebo na globální úrovni (před 2.2). Oba se také vzájemně ruší, tj. jak můžete zajistit konzistentní čtení dokumentu, do kterého se zapisuje?
Jak již bylo řečeno, možnost sporu existuje na základě specifik vašeho scénáře, provozu, počtu souběžných zápisů/čtení a mnoha dalších věcí, o kterých nemáme ani ponětí.
Možná existují nějaká jiná řešení, která mohou můj problém vyřešit efektivněji?
Osobně jsem zjistil, že S3 (jak řekl @mluggy) ve formátu se sníženou redundancí funguje nejlépe, když ukládá pouhou část metadat o souboru v rámci MongoDB, podobně jako když používáte GridFS, ale bez shromažďování kousků, nechte S3 zvládnout veškerou distribuci, zálohování a další věci pro vás.
Doufám, že jsem se vyjádřil jasně, doufám, že to pomůže.
Edit:Na rozdíl od toho, co jsem náhodou řekl, MongoDB nemá zámek na úrovni kolekce, je to zámek na úrovni databáze.