BLOB i FILESTREAM

BLOB i FILESTREAM to zestawienie dwóch mechanizmów SQL Server umożliwiających przechowywanie dużych, nieustrukturyzowanych danych.

BLOB i FILESTREAM – czym jest przechowywanie dużych danych

BLOB i FILESTREAM odnoszą się do dwóch sposobów obsługi dużych, nieustrukturyzowanych danych w środowisku SQL Server. Do tej grupy zalicza się między innymi zdjęcia, nagrania, dokumenty PDF, pliki projektowe, archiwa, skany, materiały audio oraz inne obiekty, których zawartość nie pasuje do klasycznego modelu tabel z krótkimi wartościami tekstowymi i liczbowymi. Sam skrót BLOB oznacza duży obiekt binarny. W praktyce jest to wartość przechowywana w kolumnie tabeli, zwykle z użyciem typu varbinary(max), która może zawierać dowolny ciąg bajtów.

FILESTREAM stanowi rozszerzenie tego podejścia. Pozwala przechowywać zawartość pliku w systemie plików, a jednocześnie zachować jej powiązanie z rekordem bazy danych. W tabeli pozostają informacje opisujące obiekt, na przykład identyfikator, nazwę, typ dokumentu, autora, datę dodania lub status procesu, natomiast sama duża zawartość może znajdować się poza klasycznymi stronami danych. Dzięki temu uzyskuje się połączenie mechanizmów relacyjnych z właściwościami systemu plików.

Nie jest to więc proste zestawienie dwóch całkowicie niezależnych technologii. BLOB opisuje sposób reprezentowania dużej zawartości binarnej, a FILESTREAM jest konkretnym mechanizmem SQL Server przeznaczonym do efektywniejszej obsługi wybranych danych tego rodzaju. Dobór rozwiązania powinien wynikać z wielkości obiektów, liczby operacji odczytu i zapisu, wymagań dotyczących transakcji, kopii zapasowych oraz sposobu korzystania z plików przez aplikację.

BLOB i FILESTREAM w kontekście bazy danych oraz systemu plików

W klasycznym wariancie BLOB znajduje się bezpośrednio w bazie. Aplikacja przesyła bajty podczas zapisu, a później pobiera je razem z zapytaniem lub przez osobną operację. Takie rozwiązanie ułatwia zachowanie spójności, ponieważ opis dokumentu i jego zawartość mogą być objęte jedną transakcją. Upraszcza się także kontrola dostępu, tworzenie logicznych powiązań oraz wykonywanie zapytań dotyczących metadanych. Każdy plik jest traktowany jako część danych zarządzanych przez silnik bazy.

Przy dużych obiektach pojawiają się jednak koszty takiego modelu. Rozmiar bazy może szybko rosnąć, kopie zapasowe stają się większe, a intensywny transfer danych może obciążać pamięć operacyjną, przestrzeń dyskową oraz połączenia aplikacyjne. Nie oznacza to, że BLOB jest rozwiązaniem niewłaściwym. Dobrze sprawdza się przy mniejszych plikach, gdy ważna jest prosta administracja, spójność transakcyjna i jednolity model przechowywania.

FILESTREAM wykorzystuje specjalny obszar danych powiązany z bazą, w którym pliki mogą być przechowywane w systemie plików. Relacja z rekordem nie znika, ponieważ SQL Server nadal kontroluje metadane, transakcje i uprawnienia. Dostęp do zawartości może odbywać się przez standardowy interfejs bazy albo przez mechanizm strumieniowania przeznaczony do pracy z większymi obiektami. W określonych scenariuszach ogranicza to konieczność przenoszenia całego pliku przez klasyczne operacje na kolumnach.

Warto odróżnić FILESTREAM od luźnego zapisywania plików w dowolnym katalogu obok bazy. Niezależny katalog nie zapewnia automatycznego powiązania dokumentu z rekordem, wspólnego cyklu transakcji ani jednolitej polityki odtwarzania. W przypadku FILESTREAM system korzysta z określonej struktury zarządzanej przez SQL Server. Nadal trzeba jednak zaplanować miejsce na dane, ochronę dostępu, kopie zapasowe, monitorowanie i procedurę odtworzeniową.

BLOB i FILESTREAM – typowe problemy podczas pracy

Jednym z częstszych problemów jest nieprawidłowe oszacowanie wielkości danych. W tabeli może znajdować się niewiele rekordów, lecz każdy z nich może zawierać duży dokument. W rezultacie rozmiar bazy rośnie szybciej, niż wynikałoby to z liczby wierszy. Znaczenie ma także sposób aktualizacji. Zastąpienie całego pliku nową wersją może generować większy transfer i więcej operacji niż zapisanie zmian w metadanych lub utworzenie kolejnej wersji dokumentu.

Problemy mogą wynikać również z niewłaściwego modelu aplikacji. Pobieranie dużych obiektów razem z listą dokumentów, bez filtrowania i bez stronicowania, powoduje niepotrzebne obciążenie. Podobny skutek może mieć automatyczne ładowanie zawartości pliku w widoku, który powinien prezentować tylko nazwę, typ i datę modyfikacji. Zaleca się rozdzielenie zapytań dotyczących metadanych od operacji pobierających właściwy BLOB.

Istotne jest sprawdzenie zgodności wersji SQL Server, sterowników i bibliotek używanych przez aplikację. Mechanizm może być poprawnie skonfigurowany po stronie bazy, a mimo tego nie działać prawidłowo w programie z powodu nieobsługiwanego interfejsu, błędnej ścieżki logicznej albo niewłaściwego sposobu otwierania transakcji. Przy analizie bierze się pod uwagę również uprawnienia konta aplikacyjnego, konfigurację puli połączeń, limity przesyłania oraz zachowanie podczas zerwania połączenia.

Nie należy pomijać kopii zapasowych. Dane opisowe, właściwa zawartość plików i konfiguracja obszaru FILESTREAM muszą być objęte spójną procedurą backupu. Sama kopia tabeli może nie wystarczyć do odtworzenia pełnego zbioru dokumentów. Po przygotowaniu kopii warto wykonać próbne odtworzenie na odseparowanym środowisku, sprawdzić kompletność plików i potwierdzić, że aplikacja może ponownie odczytać rekordy oraz powiązane dane.

BLOB i FILESTREAM – praktyczne wskazówki projektowe

Na początku powinno się określić charakter danych: średni i maksymalny rozmiar pliku, przewidywaną liczbę obiektów, częstotliwość odczytów, udział zapisów oraz wymagany czas przechowywania. Pomocne jest rozdzielenie dokumentów często używanych od archiwalnych. Dla pierwszej grupy ważne będą szybkie odczyty i sprawne strumieniowanie, dla drugiej zaś kontrola kosztu przestrzeni, retencji i odtwarzania.

W tabeli warto przechowywać przejrzyste metadane: identyfikator obiektu, nazwę wyświetlaną, rozszerzenie, typ MIME, rozmiar, sumę kontrolną, datę utworzenia, datę zmiany oraz identyfikator właściciela lub sprawy. Suma kontrolna ułatwia wykrywanie uszkodzeń i potwierdzanie, że pobrany plik odpowiada zapisanej wersji. Przy wielu wersjach przydatne jest także przechowywanie numeru rewizji, informacji o statusie oraz relacji między wersją roboczą i zatwierdzoną.

Należy ograniczać niepotrzebne operacje na zawartości. Lista plików powinna pobierać wyłącznie kolumny potrzebne do prezentacji, a pobieranie pełnego obiektu powinno następować dopiero po świadomym żądaniu. Dla większych dokumentów korzystne bywa strumieniowanie fragmentami zamiast tworzenia jednej dużej kopii w pamięci. W aplikacji powinno się obsłużyć przerwane przesyłanie, ponowienie operacji, anulowanie odczytu i odpowiednie zamknięcie zasobów.

Ważna jest też polityka bezpieczeństwa. Typ pliku nie powinien być ustalany wyłącznie na podstawie rozszerzenia, a dokumenty pochodzące z zewnątrz powinny być sprawdzane pod kątem złośliwej zawartości. Uprawnienia do rekordu i do samej zawartości muszą tworzyć spójny model. Sam fakt, że plik znajduje się w obszarze zarządzanym przez SQL Server, nie zastępuje kontroli dostępu w aplikacji. Przy planowaniu zmian przydatne jest wykonanie testów wydajnościowych na danych o rozmiarze zbliżonym do docelowego.

BLOB i FILESTREAM – kiedy zgłosić się do serwisu

Wsparcie serwisowe może być potrzebne, gdy baza zaczyna zajmować nietypowo dużo miejsca, operacje na dokumentach wyraźnie zwalniają, pojawiają się błędy odczytu, aplikacja traci połączenie podczas przesyłania plików albo kopie zapasowe nie obejmują całego zakresu danych. Warto zgłosić problem także wtedy, gdy po migracji systemu nie można otworzyć części dokumentów, rekordy nie odpowiadają plikom lub obszar przechowywania wymaga uporządkowania.

W ramach analizy można sprawdzić strukturę tabel, sposób użycia typów binarnych, konfigurację FILESTREAM, uprawnienia, ścieżki logiczne, logi aplikacji oraz wyniki kopii i odtworzeń. Pozwala to odróżnić problem z samą bazą od błędu programu, niewłaściwej konfiguracji dysku, braku miejsca lub niekompletnej procedury backupu. Przed przekazaniem urządzenia albo nośnika zaleca się przygotowanie opisu objawów, informacji o momencie wystąpienia problemu i listy ostatnio wykonanych zmian. W Warszawie takie czynności może przeprowadzić Warszawskie Pogotowie Komputerowe 24/7.

Nie powinno się samodzielnie usuwać plików z obszaru używanego przez FILESTREAM ani przenosić ich poza mechanizmy zarządzane przez SQL Server. Pozornie szybka zmiana może zerwać powiązania z rekordami i utrudnić późniejsze odtworzenie. Bezpieczniejsze jest najpierw wykonanie kopii, zebranie logów, sprawdzenie dostępnej przestrzeni oraz ustalenie, czy problem dotyczy pojedynczych obiektów, całej tabeli, aplikacji czy procedury administracyjnej. Dopiero na tej podstawie można dobrać sposób naprawy, migracji albo reorganizacji danych.