Zde je dobrý článek o s3fs, po přečtení jsem se uchýlil k EBS Share.
Zdůrazňuje několik důležitých aspektů při používání s3fs, konkrétně souvisejících s inherentními omezeními S3:
- žádný soubor nesmí být větší než 5 GB
- soubor nelze částečně aktualizovat, takže změna jednoho bajtu znovu nahraje celý soubor.
- operace s mnoha malými soubory je velmi efektivní (každý je koneckonců samostatný objekt S3), ale velké soubory jsou velmi neefektivní
- Přestože S3 podporuje částečné/rozdělené stahování, s3fs tuto výhodu nevyužívá, takže pokud chcete číst pouze jeden bajt 1GB souboru, budete si muset stáhnout celý GB.
Záleží tedy na tom, co ukládáte, zda je s3fs proveditelná možnost. Pokud ukládáte řekněme fotografie, kde chcete zapsat celý soubor nebo přečíst celý soubor, nikdy soubor postupně neměňte, pak je to v pořádku, i když se někdo může ptát, pokud to děláte, proč nepoužít S3 API přímo?
Pokud mluvíte o aplikačních datech (řekněme databázové soubory, soubory protokolování), kde chcete provést malou přírůstkovou změnu, pak je to rozhodně ne - S3 Just nefunguje tak, že nemůžete přírůstkově změnit soubor.
Výše zmíněný článek hovoří o podobné aplikaci - s3backer - která řeší problémy s výkonem implementací virtuálního souborového systému přes S3. To řeší problémy s výkonem, ale samo o sobě má několik vlastních problémů:
- Vysoké riziko poškození dat kvůli zpožděným zápisům
- Příliš malá velikost bloků (např. výchozí 4K) může znamenat značné dodatečné náklady (např. 130 USD za 50 GB s úložištěm o velikosti 4K bloků)
- Příliš velké velikosti bloků mohou způsobit značné poplatky za přenos dat a ukládání.
- Využití paměti může být neúnosné:ve výchozím nastavení ukládá do mezipaměti 1000 bloků.
S výchozí velikostí bloku 4K to není problém, ale většina uživatelů
pravděpodobně bude chtít zvětšit velikost bloku.
Uchýlil jsem se k EBS Mounted Drived sdílené z instance EC2. Měli byste však vědět, že ačkoli je to nejvýkonnější možnost, má jeden velký problém. Sdílení NFS připojené k EBS má své vlastní problémy – jediný bod selhání; pokud dojde k výpadku počítače, který sdílí svazek EBS, ztratíte přístup ke všem počítačům, které ke sdílené složce přistupují.
Toto je riziko, se kterým jsem dokázal žít a byla to možnost, kterou jsem si nakonec vybral. Doufám, že to pomůže.
Toto je stará otázka, takže se podělím o své zkušenosti s S3FS za poslední rok.
Zpočátku měl řadu chyb a úniků paměti (prováděl jsem cron-job, abych jej restartoval každé 2 hodiny), ale s nejnovější verzí 1.73 byl velmi stabilní.
Nejlepší na S3FS je, že máte o jednu starost méně a získáte některé výhody výkonu zdarma.
Většina vašich požadavků S3 bude PUT (~5 %) a GET (~95 %). Pokud nepotřebujete žádné následné zpracování (například generování miniatur). Pokud nepotřebujete žádné následné zpracování, neměli byste na prvním místě zasahovat do svého webového serveru a nahrávat přímo do S3 (pomocí CORS).
Za předpokladu, že narazíte na server, pravděpodobně znamená, že musíte provést nějaké následné zpracování obrázků. S S3 API budete nahrávat na server a poté nahrávat na S3. Pokud chce uživatel oříznout, budete muset znovu stáhnout z S3, poté znovu nahrát na server, oříznout a poté nahrát do S3. Se zapnutým S3FS a místním ukládáním do mezipaměti se o tuto orchestraci postaráte za vás a šetří stahování souborů z S3.
Při ukládání do mezipaměti, pokud provádíte ukládání do mezipaměti na pomíjivý disk na EC2, získáte výhody výkonu, které přicházejí, a můžete vymazat mezipaměť, aniž byste se museli o cokoli starat. Pokud vám nedojde místo na disku, neměli byste mít důvod pročišťovat mezipaměť. To značně usnadňuje operace procházení, jako je vyhledávání a filtrování.
Jediná věc, kterou bych si přál, aby to bylo, byla plná synchronizace s S3 (styl RSync). To by z ní udělalo podnikovou verzi DropBoxu nebo Disku Google pro S3, aniž byste se museli potýkat s kvótami a poplatky, které s tím souvisí.