Gdy ilość składowanych danych zbliża się do maksymalnej pojemności lub wydajności systemu, firma stoi przed dylematem - pójść drogą rozbudowy platformy bazodanowej, czy skorzystać z narzędzi do archiwizacji optymalizujących pracę istniejącej bazy?

Typowy scenariusz w firmie składującej duże ilości danych zakłada rozbudowę istniejących zasobów, czyli zakup nowych maszyn, licencji serwerowych, pamięci masowej, modernizację magistrali danych. Jeśli wiadomo, że aplikacja ma krótki czas życia bądź inwestycja zapewni sprawne działanie w dającym się określić czasie, na przykład w perspektywie trzyletniej, rozbudowa infrastruktury jest prawdopodobnie najlepszym wyjściem. Nie zawsze jest to rozwiązanie najtańsze, ale na ogół najprostsze. Nie wymaga specjalistycznych prac przy bazie danych, dodatkowych analiz, jednocześnie rozwijane są zasoby pamięci, procesorów, węzłów i innych elementów przy zachowaniu struktury bazy. Ponadto w większości przypadków działania rozbudowy infrastruktury są dobrze wspierane przez dostawców sprzętu i oprogramowania.

Oparci o ścianę

Każdy rozwój infrastruktury serwerowej w tej samej koncepcji ma swoje granice. Jednym z ograniczeń są limity systemu operacyjnego, w środowisku którego pracuje baza danych. Limit może obejmować liczbę wspieranych procesorów, maksymalną ilość obsługiwanej pamięci operacyjnej, zasobów dyskowych lub węzłów. Gdy aplikacja działa przy użyciu bazy danych, która posiada wersje dla różnych systemów operacyjnych, firma może dokonać migracji do innej wersji bazy, pracującej w systemie operacyjnym pozbawionym tych ograniczeń. Jest to także rozbudowa sprzętu i oprogramowania, ale wiąże się ze zmianą w krytycznym obszarze systemu. Jest też bardziej kosztowna.

Jeszcze większe koszty czekają firmę, która zdecydowałaby się na migrację z jednej bazy danych do innej. Przykładem mogą być migracje z bazy Microsoft SQL Server do bazy Oracle. Nawet jeśli będzie wykorzystywała ten sam system operacyjny, aplikacja działająca w środowisku SQL Servera musi zostać gruntownie przekonstruowana w celu korzystania z Oracle. Jednocześnie należy przeszkolić personel, zapewnić wsparcie techniczne, przygotować się organizacyjnie do migracji. Decyzja taka jest bardzo trudna, proces wieloetapowy, każdy błąd powoduje wymierne straty. Są jednak przypadki, gdy firma jest zmuszona do takiej migracji z powodu niedostatków lub ograniczeń wykorzystywanej bazy lub środowiska. Przykładem może być migracja bazy serwisu Allegro do bazy Oracle pracującej w środowisku komputerów klasy mainframe (uprzednio serwis korzystał z baz MySQL).

Nieużywane dane - na bok

Gdy aplikacja pracuje przez dość długi czas, pewna część danych jest wykorzystywana znacznie rzadziej. Przykładem mogą być dane archiwalne, do których nie sięga się w codziennej pracy aplikacji. Bardzo dobrym pomysłem jest przeniesienie tych danych na tańszy, choć wolniejszy zasób storage - na przykład niedrogą macierz z dyskami SATA, zamiast wysokowydajnej macierzy obsługującej główny obszar danych. Typowym działaniem jest wtedy dołączenie nowego zasobu pamięci i odpowiednie partycjonowanie danych. W ten sposób wielu administratorów dokonuje optymalizacji pracy, przenosząc rzadko używane dane na inną przestrzeń tabel. Jeśli aplikacja jest dopracowana pod tym kątem, metoda ta przynosi bardzo dobre rezultaty. Tego typu działania dobrze sprawdzą się w prostych systemach ERP, gdzie można określić ramy czasowe rzadziej wykorzystywanych danych, znana jest struktura bazy i ważne relacje między danymi.

Przy planowaniu przenoszenia danych do innego urządzenia należy bardzo dokładnie poznać relacje, rządzące danymi składowanymi w bazie. Przenoszenie danych na wolniejszy zasób storage nie będzie miało sensu, jeśli baza będzie zmuszona bardzo często odczytywać z niego te dane. Każdą operację tego typu należy poprzedzić dokładną analizą. Należy w niej uwzględnić nie tylko same relacje, ale także najczęściej używane zapytania wykonywane przez aplikację do bazy danych. Czasami aplikacja wykonuje kwerendy zupełnie inaczej niż się to administratorom wydaje, dlatego dobra dokumentacja aplikacji jest podstawą do jakichkolwiek prac przygotowawczych w tej dziedzinie.

Końcowym etapem procesu jest stan, w którym starsze dane zostaną pomyślnie zmigrowane do innego zasobu storage, aplikacja rzadko wykonuje odwołania do nich i baza zostanie dostrojona do stanu po ich przeniesieniu. Wadą takiego podejścia polegającego na przenoszeniu danych jest to, że proces ten musi być wykonany ręcznie, z dużym nakładem pracy i wiedzy administratorów. Archiwizacja rzadko wykonuje się automatycznie, nawet jeśli jest ona przeprowadzana za pomocą skryptów, nadal wymaga pracy przy kontroli i parametryzacji. Zaletą archiwizacji podzielonych danych na innym zasobie storage jest niższy koszt od rozbudowy całego systemu składowania danych i potencjalnie lepsza wydajność typowych zapytań.

Na dłuższą metę

Gdy aplikacja obsługująca główną gałąź biznesową firmy albo zarządzająca całą pracą przedsiębiorstwa jest eksploatowana w długim horyzoncie czasowym, proste środki w postaci sprzętowej i programowej rozbudowy systemu nie przyniosą długoterminowych efektów. Ilość danych może być na tyle duża, że tradycyjne rozwiązania, polegające na zakupie nowych zasobów nie przyniosą oczekiwanego efektu. Aplikacje takie są na tyle skomplikowane, że nie zawsze jest możliwe ręczne przeniesienie danych do innego zasobu pamięci albo rozbudowa bazy danych.

W takich przypadkach rozwiązaniem jest specjalizowane oprogramowanie, które pomaga dostosować bazę do archiwizacji, dokonuje jej oraz zarządza archiwum. Przykładem takiego pakietu jest Optim firmy IBM. Program ten potrafi analizować transakcje w bazie danych systemu zarządzania firmą (albo innej aplikacji), na podstawie ustalonych kryteriów oddziela on dane historyczne od bieżącej aktywności i umożliwia przeniesienie ich do archiwum. Do utworzenia reguł rządzących archiwizacją służą informacje o samej bazie i aplikacji, a także uwarunkowania biznesowe, takie jak czas życia danych lub kryteria związane z pracą firmy.

Oprócz archiwizacji system Optim umożliwia klasyfikację danych, oddzielając dane aktywne od nieaktywnych. Na podstawie klasyfikacji można stosować obostrzenia dostępu oraz zasady obsługi danych. W ten sposób łatwo można klasyfikować dane, które powinny być archiwizowane przez czas regulowany przepisami prawa. Umożliwia także audyt zgodności z regulacjami prawnymi. Jest to bardzo ważne w niektórych branżach, takich jak finanse i bankowość. Archiwum jest tworzone z użyciem sprawnej kompresji, by zminimalizować niezbędną przestrzeń dyskową. Po utworzeniu archiwum, program umożliwia nałożenie obostrzeń dostępu, obejmujących dane aktywne, nieaktywne i takie, które są danymi odniesienia. Dane archiwalne, niezbędne dla raportowania, można przenieść na nośniki WORM (jednokrotnego zapisu).

Aby takie narzędzie mogło zadziałać, wymagana jest dokładna wiedza na temat danej aplikacji oraz odpowiednie opracowanie relacji rządzących danymi. Przygotowanie reguł relacji jest najbardziej pracochłonną częścią wdrożenia. Ważną opcją, ściśle związaną z klasyfikacją rekordów, jest możliwość maskowania danych. Gdy firma przygotowuje wersję testową, względnie wykorzystuje dane produkcyjne do strojenia bazy testowej, należy zapewnić dane, które pochodzą z bazy produkcyjnej, ale posiadają zamaskowane, wrażliwe informacje. W ten sposób można zapewnić dobre wyniki prac deweloperskich, a jednocześnie chronić wrażliwe dane (transakcyjne, finansowe, osobowe) przed wydostaniem się poza bezpieczne środowisko. Aby ułatwić wdrożenie, IBM przygotował gotowe pakiety dla popularnych aplikacji ERP i CRM: JD Edwards EnterpriseOne, Oracle E-Business suite, PeopleSoft Enterprise, Amdocs CRM oraz Siebel Applications. Trzeba jednak mieć na uwadze, że nie wszystkie bazy nadają się do przeprowadzonej tym sposobem optymalizacji.

Zarządzanie danymi za pomocą narzędzia takiego jak Optim jest długoterminowym rozwiązaniem, które zapewni ciągłą pracę długo eksploatowanej aplikacji. Zatem inwestycja ma sens tylko wtedy, gdy da się przewidzieć, że aplikacja będzie pracowała przez długi czas i będzie na tyle istotna dla biznesu, by uzasadnić koszt zakupu i wdrożenia narzędzia. W przypadku dużych systemów konieczne jest przeprowadzenie szczegółowej analizy kosztów utrzymania systemu, która wykaże czy właściwe jest archiwizowanie danych, czy rozbudowa infrastruktury sprzętowej.