[Firebird] BLOB - porady

Witam,
Dawno temu (Firebird 1.5) pisałem w pracy program którego zadaniem było przechowywanie plików (głównie JPG ~4MB). Wówczas odradzano mi trzymanie plików w bazie (BLOB), zamiast tego tylko ścieżki do katalogów w któych ów pliki były przechowywane. Powód jaki usłyszałem to "baza sie wysypie przy tak dużej ilości dużych plików". Od tamtego czasu z dystansem podchodzę do BLOB'ów, właściwie jeszcze nigdy nie miałem okazji sprawdzić ich w praktyce.
Obecnie sam piszę aplikację która będzie przechowywać pliki i postanowiłem sprawdzić jak to jest naprawdę z tymi blobami. Otóż znalazłem same superlatywy: http://www.firebirdfaq.org/faq277/

• it makes it easy to do backup and restore

• aviods the need to keep the database and disk directory in sync - which can be tricky if someone (beside your application) is allowed the directory access

• simplifies the true client-server applications, since file transfer is done by Firebird - just like other data and you don't have to implement some other file transfer protocol (FTP, Windows networking, etc.). This is especially important if application works in distributed environment with many network layers (firewalls, switches, routing, etc.) in between.

• removes the need for users to keep the file names unique

Tak więc moje pytanie brzmi. Jak sprawują się bloby na froncie? Ktoś już miał z nimi doświadczenie (najlepiej Lazarus + ZEOS). Moje obawy:

1. Jak mocno, ale naprawdę, JAK MOCNO stabilna jest taka baza? Wiadomo, że baza się szybko rozpycha, nawet przy usuwaniu pliku nie znika on z bazy tylko jest oznaczany do usunięcia i fizycznie zostaje usunięty podczas robienia backupu. Co jak baza ma kilkadziesiąt GB? Ile trwa backup? Czy spada wydajność zapytań do tablic które nie mają nic wspólnego z blobami?
2. Czy można taką bazę podzielić na 2? Osobna np. dla tablic zawierających tylko pliki i osobna dla pozostałych? Chodzi mi o to żeby można było dalej szybko robić backupy ważnych danych (faktury, itd) a backup plików tylko raz na jakiś czas
3. Czy jest jakieś ograniczenie co do wielkości dodawanego pliku? Czy można bez obaw dodać plik który ma kilkaset MB?
4. Czy można monitorować strumień danych które baza wysyła/odbiera? Chodzi mi tu o możliwość zrobienia czegoś w rodzaju paska postępu, np. jak plik ma kilkadziesiąt MB to żeby było widać ile danych pobrano/wysłano

Pozdrawiam

Bloby mają zarówno zady jak i walety ;)

Tak jak napisałeś, baza ze zdjęciami zajmuje więcej miejsca, znacznie zwiększa czas robienia backupu oraz po usunięciu zdjęcia nie zwalnia zajmowanego przez niego miejsca. Ponadto zapytania na tabeli ze zdjęciami są bardzo powolne z oczywistych powodów.

Co do możliwości podzielenia bazy na dwie to nie słyszałem o takiej możliwości chyba, że mówimy o dwóch fizycznie odrębnych bazach. Trzymanie zdjęć w osobnej bazie to porażka, ponieważ tracisz wszystkie zalety trzymania obrazków w bazie i ciężko zachować spójność.

Osobiście preferuje trzymanie samych ścieżek do obrazków. Niestety te wyjście powoduje konieczność osobnego wykonywania backupu dla danych i osobnego dla plików, tak samo z resztą jak w przypadku podzielenia bazy.

Firebird radzi sobie z BLOB'ami całkiem spoko.

Ad1. Kiedyś gdzieś czytałem, że FB trzyma BLOB'y na trzy sposoby w zależności od rozmiaru. Tabelki z tymi blob'ami powinny mieć pozakładane indeksy na pola o które będziesz pytał. Kiedyś przyobserwowałem zjawisko że brak indeksu powodował odczyt całej tabeli co działało strasznie wolno. Może lepiej trzymać dane w dwóch tabelach w relacji 1-1. W jednej dane, w drugiej blob'y wyciągane OnDemand.
Ad2. Możesz mieć dwie bazy, ale o ile wiem zapytania do dwóch baz naraz można dopiero od wersji 2.5, więc w Twoim przypadku się nie da. Choć z drugiej strony zawsze to jakieś wyjście. Firebird oferuje możliwość podziału pliku bazy, ale nie wpływasz na to w jaki sposób, dla Ciebie to jedna baza.
Ad3. Nie robiłem harcorowych testów, ale kiedyś wcisnąłem 88Mb plik i poszło, ale trwało sakramencko długo (kilka minut). Wydaje mi się iż teoretycznie ograniczeń nie ma. Problemem jest czas na to potrzebny. Czym większy plik, tym większy czas. A jak to jeszcze idzie po sieci ...
Ad4. Chyba nie. Chociaż jak tak się zastanowię, to w zasadzie może by się dało pogrzebać przy metodach zapisu/odczytu ze strumienia, i może by coś z tego wyszło.

Zależy jakie będziesz miał te pliki, i jaka to będzie aplikacja. Może jednostanowiskowa ? Polecam wtedy FB Embeded ze względu na speed.