Těch možností je víc, jak už to zaznělo. Ale za mě, pokud tam není nějaká vstupní konverze obrázků na jednotný formát (což může mít také své výhody, byť by se třeba vstupní soubor někam zálohoval) a měl tam v jednom adresáři mix formátů, asi bych se nezdráhal jít tím nejjednodušším způsobem a nechal tam přípony.
Jinak, vím že jste se na to neptal a už to máte hotové
, ale taky bych tak nějak spíš inklinoval k tomu, neukládat všechny obrázky jako BLOBy do databáze a servírovat je klientům přes tuhle lazy cache.
Chápu, že to někdy může mít své výhody a samozřejmě nevím, co je to za systém, ale pokud db začne velikostně bobtnat, může to přinést řadu praktických problémů. Takže pokud bych tam už něco měl ukládat, tak né originální uploady, ale pokud to bude dávat výkonostně smysl, tak třeba jen ty malé náhledy, kde se dá dobrat k někjaké predikovatelné velikosti a všechno bude mít jeden formát.
Ukládání souborů samotných pak dělat do podadresářů podle prvních znaků hashe, třeba jako Git. Mezi nimi se to bude víceméně automaticky dělit a na filesystému nevzniknou hotspoty, ani když tam bude opravdu hodně souborů a bude k tomu přistupovat víc procesů/vláken.
U toho pojmenování to pak jde samozřejmě udělat tak, jak to máte - podle nějakého GUIDu z databáze, nebo se to dá udělat také podle hashe z obsahu souboru. Což může mít výhodu v tom, že pokud tam budou ukládat data uživatelé, můžu to rovnou deduplikovat, když tam budou opakovaně sypat ty samé soubory.. V db pak dvě tabulky - např. pro obrázky (s těmi guidy, metadaty, origo názvem) a pak pro soubory (na disku), mezi kterými je vazba.
Celé tohle pak poskytuje vcelku široké možnosti, jako to v provozu optimalizovat, když bude potřeba. Statické soubory můžou být na jiném hostu než databáze, v extrému i ty jednotlivé podadresáře. Ukládat můžu jak do disku, případně to pak to i po nějaké době s relativně minimálními úpravami přesunout třeba do nějaké S3 storage (kde ty původní podadresáře budou jen prefixy).
Pokud bude potřeba další cachování, můžu to dělat klasicky přes reverzní proxy někde na edge serverech.. což jde samozřejěmě i s tou lazy cache, ale je to db -> lazy cache -> druhá cache.. A pokud to třeba nahodím na jiném stroji bez cache, a přesměruju tam provoz, tak tam budu mít na úvod poměrně velké vytížení db, než se ta lazy cache naplní.
Asi i proto bych měl tendenci se spíš držet té klasické architektury.
16 Odpovědí
2392 Zhlédnutí