Coraz łatwiejsze migracje

W pewnych przypadkach możliwa jest nawet migracja bez przestoju aplikacji (zero downtime migration), ale taka procedura jest stosowana raczej przy migracji do wyższej wersji tego samego motoru. W tym przypadku wyłącza się jedną maszynę w sieci grid, przeprowadza aktualizację i testy, a następnie włącza z powrotem. Aktualizując po kolei wszystkie maszyny, można przejść do wyższej wersji podczas pracy aplikacji biznesowej, ale niezbędne są przy tym procedury i narzędzia, które zapewnią ciągłość działania usługi. Prace nad tą technologią trwają. Nadal jest to bardzo poważna operacja w przypadku programów, które mają pracować bez przerwy.

Inny motor - ten sam kod

Im mniej zmian w kodzie aplikacji podczas migracji do nowej bazy danych, tym sam proces będzie prostszy. Milowym krokiem w tej dziedzinie były prace, które w 2005 roku zaowocowały wydaniem biznesowej bazy danych Postgres Plus firmy EnterpriseDB. Technologia rozwinięta przez tę firmę umożliwia emulowanie w komercyjnej edycji Postgres Plus najważniejszych struktur i obiektów obecnych w bazach Oracle oraz SQL Server. "Tę technologię licencjonuje i rozwija firma IBM w swojej bazie DB2, wprowadzając kompilator PL/SQL. Do grudnia ubiegłego roku przeanalizowano 750 tysięcy linii kodu PL/SQL uzyskując zgodność na poziomie 98,43%, co oznacza, że w większości przypadków aplikacje biznesowe można przenieść z Oracle do DB2 bez zmian kodu (lub z bardzo niewielkimi zmianami)" - wyjaśnia Philip Howard. Różnice dotyczą oczywiście bibliotek odpowiedzialnych za połączenie do motoru bazodanowego, ale kod składowany pozostaje ten sam lub zmiany są niewielkie.

Kompresja danych

Kompresja danych staje się standardem w bazach klasy Enterprise, przyczyniając się do zmniejszenia zapotrzebowania na przestrzeń dyskową (a przez to także kosztów) oraz poprawy wydajności. Wzrost wydajności jest spowodowany mniejszą ilością danych pobieranych z dysków przy dużych tabelach, co przyczynia się także do lepszego wykorzystania kosztownych pamięci SSD. Zdaniem Philipa Howarda, "efektem ubocznym wprowadzenia kompresji jest zwiększenie o kilka procent zapotrzebowania na moc CPU, ale wydatek ten jest rekompensowany z nawiązką przez mniejsze wykorzystanie operacji wejścia/wyjścia. Istnieje trend do kompresowania wszystkiego, co tylko można: tabel, indeksów, obszarów tymczasowych, zapisów do dziennika transakcji i tak dalej".

Kompresję danych można wprowadzić na dwa sposoby - na poziomie wierszy lub kolumn. Pierwsza metoda, zaimplementowana w bazach SQL Server i Oracle, działa na poziomie krotki, kompresując każdy z wierszy. Jest to skuteczna metoda, ale wykorzystywanie jednego algorytmu dla danych o różnej charakterystyce, nie jest optymalne. Znacznie lepsze efekty przyniesie kompresja na poziomie kolumn, gdyż uwzględnia fakt składowania różnych rodzajów danych między kolumnami. Niektóre bazy posiadają opcję kompresji indeksów, wykorzystując przy tym inny algorytm, w którym stopień kompresji jest niższy, by nie ograniczać wydajności.

Przykładem aplikacji biznesowej, w której coraz częściej stosuje się kompresję danych jest pakiet firmy SAP. Tabele w tym oprogramowaniu są bardzo szerokie, posiadają wiele kolumn, a czasami tylko część informacji z rekordu jest potrzebna. Bazy dzisiejszych systemów ERP bardzo szybko rosną, przy czym ujednolicenie bazy do unikodu jeszcze zwiększa ilość danych składowanych na dyskach. W większości przypadków dane są bardzo dobrze kompresowalne i ta opcja przynosi wymierne korzyści wydajnościowe. Gdy firma kupuje bazę DB2 na podstawie licencji OEM razem z pakietem SAP, otrzymuje kompresję w cenie licencji.

Autonomia bazy

Bardzo ważnym trendem rozwoju baz, który daje się zauważyć wśród kolejnych wersji motorów różnych producentów, jest coraz większa autonomia baz danych. W produktach kierowanych do sektora MSP jest to tendencja do automatyzacji wszystkich czynności, by baza danych była możliwie bezobsługowa. Oznacza to implementację w motorze wszystkich najważniejszych czynności, takich jak kopia bezpieczeństwa, kontrola pracy czy podstawowe strojenie wydajnościowe. W przypadku baz danych klasy Enterprise, takich czynności nie można w pełni automatyzować, ale można wyręczyć administratora w niektórych analizach i procesach. "System sam analizuje pracę bazy, a następnie przedstawi administratorowi problem i sugestie jego rozwiązania. Takie podejście przynosi najlepsze efekty przy strojeniu wydajnościowym, gdzie wąskie gardła są odnajdywane automatycznie, administrator otrzymuje raport, w którym proponuje się podjęcie pewnych działań. Po akceptacji, będą one zrealizowane automatycznie" - tłumaczy Philip Howard.