it-swarm-eu.dev

Zobrazování obrázků mimo SQL server vs. systém souborů vs. S3 atd

Moje aplikace (klasická asp yay!) Má asi 2,1 milionu obrázků @ 25 GB, což představuje pouze 90 dnů dat a rád bych si vybral minimálně 365. Musím je dostat pod kontrolu a zvažuji všechny možnosti. Jaké jsou vaše názory na výhody a nevýhody následujících praktik:

  • Výhody serveru SQL: Snadné zálohování Nevýhody: Výkon?
  • Výhody systému souborů: Rychlost Nevýhody: Redundance, Zálohování je pomalé (v současné době zkoumá syntetické plné zálohy, které by to mohly zlepšit)
  • S3 a podobně Pros: Šířka pásma je přesunuta z mého datového centra do Amazonu, prakticky neomezeného úložiště. Nevýhody: náklady, analýza nákladů je ošidná (odhadem 80% mé šířky pásma jsou obrázky pro účely návratnosti investic), obtížné/nákladné, aby poskytovatelé služeb mohli vyměnit služby, pokud to bude nutné

Zabývá se někdo s výzvou pro více milionů obrázků a jak jste se s ní vypořádali?

12
Webjedi

Nemáme miliony obrázků, ale máme stovky tisíc a používáme hybridní přístup - mysql pro metadata, obrázky uložené na místním disku pro zálohování a tlačené na Amazon s3, kde jsou doručovány uživatelům. Neměli jsme problémy s Amazonkou a dostupností. Přechod na cloudfront je v našich plánech, stačí si najít čas.

Tato diskuse vám může pomoci při vašem rozhodování:
http://ask.metafilter.com/59635/Millions-of-images

Chtěl bych jít s metadaty na serveru SQL a se soubory na souborovém systému (nebo s3 nebo cloudfront). Nejlepší odpověď však závisí na některých dalších způsobech použití:

  • obrázky se často mění
  • můžete obrázky obsluhovat přímo ze souborového systému (tj. img src="...") nebo potřebujete, aby byly kontrolovány přístupem. Pokud je to druhé, pak je nejlepší řešení databáze
  • zobrazujete většinu času malému počtu obrázků (posledních 10%) nebo je distribuce poměrně rozšířená.

Zálohy pro miliony obrázků budou složité bez ohledu na to, jak je uspořádáte - je to jen spousta dat. Chtěl bych najít dobrou případovou studii o zálohování blobů na serveru SQL, než jsem se zavázal k tomuto řešení. (Zde je článek, který by mohl být užitečný: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part -4.htm )

6
mooreds

Ignorujte lidi, kteří říkají: „ Neukládejte obrázky/binární data do databáze “, protože své odpovědi zakládají na starých informacích (za předpokladu, že budete ukládání dat do sloupce typu VarBinary). Obavy o výkon pomocí SQL Server pro ukládání obrázků lze nyní zmírnit pomocí datového typu FILESTREAM v SQL Server 2008. Datový typ FILESTREAM v podstatě umožňuje kombinovat snadné ukládání dat v databáze s výkonem, který získáte při poskytování souborů z úložiště souborů NTFS.

Citace SQL Mag :

„Nová podpora FILESTREAM serveru SQL Server 2008 kombinuje výhodu přístupu k LOB přímo ze systému souborů NTFS s referenční integritou a snadným přístupem, který nabízí relační databázový stroj SQL Server.“

Pro více informací přečtěte tento blog od Ravi S.Maniam na MSDN .

3
Dan Diplo

Pokud se rozhodnete pro jejich uložení v souborovém systému, možná si budete chtít přečíst tuto otázku ServerFault pro některé úkoly, které nejsou a nejsou: ložení milionu obrázků do souborového systém .

3
Mark Henderson

I když se nezabývám výzvou pro více milionů obrázků, používal bych Amazon CloudFront. Všechny soubory jsou uloženy v kbelíku S3, ale jsou serverem prostřednictvím systému doručování obsahu Amazonu. Nepoužil bych S3 sám.

Moje druhá volba by byla systém souborů. Jednoduchý a snadný, jediný problém je, pokud všechny tyto soubory skončí v jednom adresáři, celá věc se zhroutí, tvrdě.

SQL by pro mě nebyl takový systém. Nejenže se vám účtuje poplatek za přenos šířky pásma, ale také vám bude účtováno zpracování dotazu - to bude velmi záležet na hostování, ale předpokládám, že používáte dedikovaný server nebo alespoň vps, kde vám bude účtován poplatek. pro cykly. Poté, pokud použije stejnou databázi jako obrazový server, zpomalí celý váš web. Pokud ne, přidáte celou tuto složitost nutnosti spravovat dvě databázová připojení.

2

Databáze jsou navrženy pro transakční data/konzistenci a zabezpečení.

Mediální soubory (obrázky, audio, video) bývají vytvářeny a možná smazány, ale velmi zřídka aktualizovány. Obecně tedy není potřeba udržovat je transakčně konzistentní s jinými daty a databáze vám tam nebude poskytovat žádný skutečný přínos. Obsah textu možná jiná záležitost.

Pokud nemáte problém s konceptem, že někdo soubor vytáhne přímo, pokud má adresu URL souboru, je systém souborů v pořádku. Pokud jste provozovali něco jako knihovnu fotografií, kde se očekává, že vám bude účtováno dříve, než lidé soubor stáhnou, je to pravděpodobně jiná záležitost. To znamená, že jakmile uživatel zaplatí, může získat adresu URL specifickou pro daného uživatele nebo platnou pouze na krátkou dobu a aplikace zpracovává více nebo dočasné adresy URL směřující na stejný obrázek. To by stále mohlo být řešeno aplikací a souborovým systémem, ale nakonec skončíte obsluhováním médií prostřednictvím aplikace, nikoli přímým stahováním souborů (což většinou vylučuje jakékoli výhody S3) a je menší rozdíl mezi DB a souborovým systémem .

1
Gary