Bardzo dobre pytanie, ale w zasadzie nie ma na nie prostej odpowiedzi - wszystko zależy od konkretnego przypadku i używanych technologii. Istotne informacje to np.:
- Czy serwis jest obsługiwany przez jeden serwer na którym stoi baza, czy raczej jest to bardziej skomplikowana architektura wielo-serwerowa?
- Jeśli baza danych jest na innym serwerze, to czy połączenie sieciowe między nimi jest szybsze od dysku, czy wolniejsze?
- Jakie są specyfikacje serwerów? Czy np. mają dużo RAMu? A może mają dysku SSD?
- Czy odnalezienie konkretnych plików musi być szybkie? Czy sam odczyt ma być szybki? A może jest to ostatecznie nieistotne?
- Czy pliki są tylko-do-odczytu? A może całe będą zmieniane? A może tylko ich fragmenty?
- Czy dostęp do nich powinien być w jakiś sposób kontrolowany? (ACL? audytowanie (logowanie dostępu do zasobu)?)
- itd. itp.
W oryginalnym pytaniu wspomniałeś konkretnie o zdjęciach, więc użyje je jako przykładu.
Zdjęcia można scharakteryzować następująco:
- Jeden plik waży kilkadziesiąt kilobajtów do kilku megabajtów (więc to raczej dłuższe kawałki danych).
- Można je traktować jako read-only, tj. o ile może będą usuwane, to raczej edycja fragmentów nigdy się nie zdarzy.
- Praktycznie zawsze będą strumieniowane w całości; random-access jest niepotrzebny.
- Dobrze jest, jeśli zdjęcia się wyświetlają w miarę szybko, ale ostatecznie nie jest to krytyczne dla serwisu.
- Załóżmy też, że rozmawiamy o publicznych zdjęciach (brak ACL / audytowania).
I teraz można to rozważyć dla dalszych trzech przypadków:
1. Mały serwis (jeden serwer) z niskim obłożeniem
Przy dobrej konfiguracji bazy/FS (cache/prefetch) i sporej ilości RAMu jest prawie nieistotne gdzie trafią zdjęcia, tj. czy do bazy, czy do systemu plików. Jeśli komuś zależy na prędkość, można zrobić benchmark dla konkretnej technologii (tj. np. kilku różnych rodzajów baz, kilku różnych rodzajów systemów plików). Osobiście stawiam na drobną przewagę FS w tym miejscu z uwagi na przystosowanie do tego typu operacji, chociaż jeśli musisz trzymać jakieś metadane dodatkowo w bazie (i po nie sięgać), to sytuacja może się odwrócić.
Jeśli baza danych nie będzie mogła trzymać takiej ilości danych w pamięci z jakiegoś powodu, będzie wolniejsza, ponieważ będzie musiała doczytać dodatkowe dane z dysku, a potem je przesłać po jakichś socketach/IPC do web aplikacji. Dla porównania, gdyby pliki leżały na dysku, krok "przesłać po jakichś socketach/IPC" by nie istniał (a więc byłoby szybciej).
2. Mały serwis na którym zdjęcia mają się szybko pokazywać, ale jest ich niewiele
W takim wypadku w zasadzie można je trzymać wszystkie cały czas w pamięci. Tego typu rozwiązanie oszczędza jednego transferu danych (np. z systemu plików do pamięci, lub z bazy via sockety/IPC), ale wymaga więcej RAMu.
Szczerze przyznaję, że jak mogę to właśnie tak robię.
3. Większy (kilku serwerowy) serwis z większą liczbą zdjęć (tu wpada FB/Instagram)
W takim wypadku sprawa się komplikuje i pytaniem jest jeszcze ile jest serwerów ze zdjęciami (jeden? kilka?) i jak są połączone z web serwerem, etc. Ostatecznie celem w takim wypadku jest umieszczenie przesyłania statycznych zdjęć jak najbliżej samych web serwerów (czyli okolice server-side'owego front-endu). A potem stajemy przed wyborem czy:
- Zdjęcia powinny być w bazie danych na osobnych serwerach?
- Czy może na jakimś pojedynczym FS sieciowym?
- Czy może powinny być zwielokrotniane na każdym serwerze (tj. cache'owane lokalnie / prefetchowane przy uruchomieniu aplikacji)?
Dużo zależy od ilości zdjęć (setki? tysiące? miliony? miliardy?) i prędkości dysków/sieci; czym więcej zdjęć, tym bardziej zatrze się granica pomiędzy FS a bazą danych, ponieważ oba te zasoby będą de facto musiały stać na wielu osobnych serwerach, i dostęp do nich będzie tylko po sieci. Pewnie lokalny FS będzie użyty co najwyżej jako cache.
W zasadzie w całym tym ostatnim punkcie słowem kluczowym będą "benchmarki" - tj. po prostu będzie trzeba posprawdzać kilka różnych scenariuszy i zobaczyć gdzie czasy wyglądają najlepiej. Pomaga też dobra znajomość środowiska (dostępnych rozwiązań / konfiguracji sprzętowych / etc) na których będzie się stawiać system (wtedy można lepsze decyzje podejmować).
Więęęc... zdaję sobie sprawę, że nie odpowiedziałem Ci na pytanie :). Ale może powyższe chociaż trochę wytłumaczy, czemu trudno jest odpowiedzieć na to pytanie w oderwaniu od konkretnego przypadku.
