Często zmieniające się pliki i ich zapis do bazy

Zacząłem budowanie aplikacji mobilnej, w której użytkownik przy każdym rozpoczęciu sesji (uruchomienie głównej funkcjonalności w aplikacji) musi wykonać zdjęcie, które będzie przechowywane tylko na czas trwania tej sesji czyli w założeniu jakieś kilkadziesiąt minut (nieistotne po co takie coś, ot taki pewien pomysł :P ) i musi być dostępne dla innych więc wysłane na serwer.
I teraz pytanie do osób bardziej obeznanych w tematach bazodanowych: czy takie zdjęcia, które będą niewielkie bo myślę, że po kilkadziesiąt kB (obrazki jpg ok. 500x500px, ten rząd wielkości w każdym razie) ale często dodawane i usuwane (założenie jest takie, że po zakończeniu sesji info o niej jest usuwane z bazy, ewentualnie po prostu będzie oznaczane jako "do usunięcia" a osobny proces zajmie się tym w swoim czasie jeśli tak będzie wydajniej) lepiej trzymać w samym rekordzie czy jednak w folderze na dysku, poza bazą i tylko zapisywać link do nich?
Chciałbym rozważyć przypadki przy różnym obciążeniu:

1. mały ruch - kilku użytkowników na minutę (na razie bardziej realny ale i tak optymistyczny scenariusz :P )
2. duży ruch - kilkaset/tysiące użytkowników na minutę (bo trzeba optymistycznie patrzyć na przyszłość swojego produktu :D )

Baza, którą wybrałem to Postgresql, ale ponieważ wszystko jest na bardzo wczesnym etapie to nie ma problemu zmienić jej na inną.

Czemu musisz dodawać je koniecznie do bazy?
Możesz stworzyć plik o wygenerowanej losowej nazwie, zaś do bazy dodać tylko wylosowaną nazwę.

Właśnie tego dotyczy pytanie co bardziej się opłaca, bo często się okazuje, że powszechna praktyka nie zawsze jest najbardziej optymalna :) Niby większość poradników o wysyłaniu plików na serwer zaleca trzymać je osobno, ale tutaj mam właśnie o tyle inny przypadek, że te pliki są "krótkoterminowe" i zawsze niewielkie.

tym bardziej.

Jest to niebanalna kwestia i zależy od konkretnego zastosowania. Przechowując obrazki w bazie danych masz zapewnioną integralność danych (obrazek i metadane), mniej martwisz się o backupy tj. o to, że przykładowo nie odzyskasz obrazków, których linki masz w bazie (lub odwrotnie), prostsza jest też replikacja danych.

Jak pisałem w pierwszym poście zdjęcia będą przechowywane przez krótki okres czasu liczony maksymalnie w godzinach, potem mogą spokojnie przestać istnieć, sama utrata zdjęcia w trakcie sesji użytkownika nie jest też krytycznym problemem dlatego jeśli chodzi o backupy to w tym wypadku nie martwię się o to. Za przechowywaniem ich w bazie jeszcze przemawia prostsze zarządzanie obciążeniem, w końcu rozdzielenie samej bazy na kilka serwerów (w sporym uproszczeniu) jest czymś względnie często stosowanym i odpada problem osobnej obsługi rozproszonych plików, chyba, że się mylę?

Na podstawie przedstawionego opisu ciężko mi jednoznacznie odpowiedzieć czy zapisywania obrazków w bazie na pewno będzie lepszym rozwiązaniem. Jestem zdania, że możesz to spokojnie zrobić w bazie, a ewentualnie po sukcesie aplikacji przemyśleć zagadnienie jeszcze raz. Zauważ, że każdy większy startup np. Facebook, Twitter, Reddit ewoluował w trakcie zdobywania kolejnych użytkowników i modyfikował swoje podejście co do tego gdzie i jak przechowywać dane użytkowników. Przykładowo Twitter był napisany w Ruby on Rails oraz przechowywał początkowo tweety użytkowników w bazie MySQL, która była horyzontalnie partycjonowana. Z czasem od tego odeszli i doszli do własnych, najlepszych dla nich rozwiązań.

W tym przypadku nie trzymałbym tych plików w bazie tylko w osobnym folderze. Jeżeli one będą szybko usuwane to nie ma co rzeźbić po bazie, wystarczy folder.

Ja akurat użył bym quasi-bazy SQLite w RAMie. Dzięki temu będzie szybkość. Integralność nas absolutnie nie interesuje w takim wypadku, więc sądzę, że to rozwiązanie było by optymalne. Problemem jest tutaj ilość dostępnego RAMu. Pamiętajmy, że dyskowe IO jest dość powolne, więc i tak ile się by dało było by trzymane w jakimś z mmapowanym pliku lub coś podobnego.

Innym rozwiązaniem jest całkowite olanie serwera i DB. Przechowuj plik u użyszkodnika i serwuj go przez BT innym użytkownikom aplikacji. Następnie tylko jakiś ping w celu ustalenia czy dalej trzymać plik na dysku i masz rozwiązanie, które się samo skaluje (ale zabiera upload).