Jednym z istotnych, obserwowanych w ostatnim czasie trendów jest wprowadzanie gotowych rozwiązań bazodanowych przeznaczonych do wykonywania konkretnego zadania. "W porównaniu do tradycyjnego modelu, gdzie motor jest instalowany w systemie operacyjnym w środowisku klienta, appliance wygrywa pod względem szybkości wdrożenia. Gotowe rozwiązanie może także łatwiej osiągać lepszą wydajność, gdyż może być dostrojone pod kątem sprzętu i systemu operacyjnego przez producenta" - mówi Philip Howard, Research Director w firmie Bloor.

W przypadku tradycyjnej instalacji, integrator musi zadbać o zgodność oprogramowania i sprzętu, a nie zawsze można wykorzystać niektóre rozwiązania techniczne, takie jak np. karty akcelerujące. Czasami nawet instalacja oprogramowania jest kłopotliwa, gdy pakiet zajmuje kilkadziesiąt nośników i wymaga specjalnych procedur instalacji, konfiguracji i strojenia.

Appliance ma także wady, między innymi przywiązanie do jednego dostawcy rozwiązania. Skutkuje to wyższymi kosztami wyjścia z danej technologii, a ponadto rozwiązanie zamknięte może utrudniać integrację z innymi aplikacjami biznesowymi. Jest także mniej elastyczne i przeważnie drożej się skaluje.

Pamięci półprzewodnikowe

Pomysł wykorzystania pamięci półprzewodnikowych w rozwiązaniach bazodanowych nie jest nowy. Na rynku są już produkty, które posiadają SSD, na przykład Oracle Database Machine v2. Chociaż pamięć ta jest bardzo szybka, jest również kosztowna. Philip Howard wyjaśnia: "Przestrzeń składowania danych zrealizowana za pomocą SSD jest zbliżona w cenie do zasobów o takich samych parametrach wydajnościowych, ale wykonanych w tradycyjnej technologii dysków magnetycznych. Typowo, producenci wyposażają swoje serwery w stosunkowo niewielką ilość bardzo szybkiej pamięci półprzewodnikowej, by na tych zasobach przechowywać "najgorętsze" dane. Jest to uzasadnione ekonomicznie, przy czym użycie kompresji danych jeszcze podwyższa wydajność".

W integracji pamięci SSD z rozwiązaniami bazodanowymi można wyróżnić dwa podejścia: wykorzystanie najszybszego tieru storage w technologii SSD lub głębsza integracja z systemem serwera za pomocą kart rozszerzeń. Tę pierwszą drogę wybrała firma Teradata w swoim Extreme Performance Appliance 4555, z drugiej korzysta Oracle w Database Machine v2. Zaletą pamięci SSD, podłączonych do kontrolerów storage, jest prostsze równoważenie obciążenia, natomiast SSD w formie wielu modułów PCI Express zapewni szersze pasmo.

Od bazy do bazy

Dotychczas migracja bazy danych systemu ERP była traktowana jako operacja wysokiego ryzyka. Wykonywano ją jedynie do wyższej wersji lub edycji motoru tego samego producenta, i to najczęściej przy wymianie sprzętu. Dane przenoszono na nowy serwer lub macierz, dokonując przy tym niezbędnych konwersji, a cała operacja musiała się zakończyć w czasie okna serwisowego, które zazwyczaj jest dość krótkie. Jedną z niewielu aplikacji biznesowych posiadających sprawdzone procedury producenta, zapewniające wykonanie bezpiecznej migracji do motoru innego dostawcy, jest pakiet firmy SAP. "Firmy do dziś boją się migracji do motoru innego producenta, przy czym obawy te dotyczą aż 72% organizacji, które odniosłyby znane im, pozytywne efekty biznesowe. Obawy tradycyjnie dotyczą czasu migracji i ewentualnych problemów po przeniesieniu wszystkich informacji do nowej platformy" - mówi Philip Howard.

Obecnie operacje migracji do motoru bazodanowego innej firmy są obarczone niższym ryzykiem niż jeszcze trzy lata temu, gdyż dostępne są dużo lepsze narzędzia. Znacznie lepiej rozumiemy procesy, które mają wtedy miejsce - opracowano stosowną metodologię, a rynek jest lepiej przygotowany. Znane są wszystkie najważniejsze czynniki ryzyka i dostępne są narzędzia, które umożliwiają zmniejszenie go do akceptowalnego przez biznes poziomu. Dotyczy to nie tylko zmiany platformy bazodanowej, ale także migracji do wyższej wersji motoru tego samego producenta.