Przechowywanie załączników a baza danych

Sposób przechowywania załączników - temat rzeka przewijający się przez setki forów i blogów podobnych do tego, aczkolwiek ze względu na pytania ze strony kolegi z Indii opiszę to również tutaj.

Skupmy się na dwóch możliwych (i najczęściej spotykanych) zastosowaniach załączania plików :

• przechowywanie dokumentów stanowiących integralną część danych (np. wzory podań, wypełnione deklaracje) - mały rozmiar, mało dokumentów, brak przeszukiwania
• przechowywanie dużych plików (filmy, zdjęcia, muzyka) i/lub intensywne przeszukiwanie

W przypadku pierwszej możliwości nie potrzebujemy zbyt dużych nakładów na utrzymanie bazy danych ani specjalnych zabiegów. Dla niezbyt dużego obciążenia, powinno sprawnie działać. Wadą jest duży rozmiar bazy. W jednym z rozwiązań, które odziedziczyłem, przechowywanie załączników było zrobione właśnie w ten sposób, dokumenty stanowiły 50% objętości bazy. Przy dzisiejszych kosztach storage "zwykły" kontra bazodanowy (wliczając w to, że baza sama z siebie też zajmuje RAM), zdecydowanie taniej wychodzi pierwsza opcja. Plusem rozwiązania jest łatwy dostęp do plików, brak dodatkowej logiki (lub warstwy w aplikacji) zapewniającej ich obsługę.
SQL Server od wersji 2008 posiada wsparcie dla FILESTREAM (trzeba manualnie włączyć). FILESTREAM to nic innego jak zapis pliku fizycznie na dysku, zamiast przechowywania danych bezpośrednio w tabeli w bazie danych. Wymogiem koniecznym jest włączenie tej funkcjonalności w konfiguracji SQL Server. Patrząc na tą funkcjonalność z punktu widzenia programisty, kolumna zawierająca pliki musi być typu varbinary(MAX). Więcej na temat tej funkcjonalności i ograniczeń z nią związanych możecie przeczytać na tej stronie.

W drugim przypadku architektura system jest bardziej złożona. FILESTREAM nie wchodzi w grę, gdyż nie poradzi sobie z dużymi filmami (powyżej 2 GB). Można je teoretycznie ciąć w tle na mniejsze, tylko po co? W takiej sytuacji jedyną opcją jest zapisanie filmu prosto na serwer plików, a w bazie zapisać ścieżkę do pliku i metadane. Należy pamiętać o konieczności zmiany nazwy pliku na GUID/unikalny string, gdyż w innym przypadku ktoś może nam go nadpisać. Gdybyśmy sobie to rozrysowali, to od razu widać, iż dokładamy dodatkową warstwę do systemu, która może spowodować dużo komplikacji (zapewnienie pojemności, czas dostępu, sposób dostępu, kopie zapasowe). Do optymalizacji przeszukiwania metadanych można skorzystać z dodatkowego silnika wyszukiwania jak np. open source'owy Solr. Co prawda to jeszcze troszkę bardziej komplikuje architekturę, ale niesamowicie przyśpiesza przeszukiwanie w dużych zbiorach danych.

Do tego rozwiązania można podciągnąć również pewne rozwiązania dostępne w chmurach jak Amazon S3. Jeżeli jednak korzystamy z usług innego providera niż Amazon, to raczej nie traktowałbym tego jako opcji ze względu na opóźnienia sieciowe.