Serwery relacyjnych DBMS

Sercem wielu instalacji o architekturze klient/serwer jest oprogramowanie, obsługujące relacyjne bazy danych. W architekturze tej proces klienta (reprezentowany przez aplikację czołową typu front-end, dostarczającą interfejs z użytkownikiem), wysyła zlecenie usługi do procesu serwera (realizowane przez oprogramowanie zaplecza, tzw. back-end aplikacji lub DataBase engine). Oprogramowanie zaplecza zarządza przetwarzaniem danych, tzn. może je uaktualniać, przeszukiwać, dbać o integralność danych, sterować kolejno wieloma zleceniami (kolejkowanie). Otrzymane rezultaty pracy zostaną przesłane do procesu klienta w formie komunikatu.

Sercem wielu instalacji o architekturze klient/serwer jest oprogramowanie, obsługujące relacyjne bazy danych. W architekturze tej proces klienta (reprezentowany przez aplikację czołową typu front-end, dostarczającą interfejs z użytkownikiem), wysyła zlecenie usługi do procesu serwera (realizowane przez oprogramowanie zaplecza, tzw. back-end aplikacji lub DataBase engine). Oprogramowanie zaplecza zarządza przetwarzaniem danych, tzn. może je uaktualniać, przeszukiwać, dbać o integralność danych, sterować kolejno wieloma zleceniami (kolejkowanie). Otrzymane rezultaty pracy zostaną przesłane do procesu klienta w formie komunikatu.

Proces klienta kontaktuje się z procesem serwera tylko w czasie wysyłania zlecenia usługi lub odbioru komunikatu, za pośrednictwem języka SQL, wbudowanego w system zarządzania bazą danych. Język ten został opracowany w latach 70. przez IBM.

Zaletą niektórych relacyjnych DBMS jest ich skalowalność. Gdy przybywa informacji w bazie danych lub gdy rośnie liczba użytkowników z niej korzystających, możemy przenieść bazę z małego systemu NetWare na silniejszą wieloprocesorową platformę sprzętową. Jest to możliwe wtedy, gdy serwer DBMS może współpracować z systemami wieloprocesorowymi. Dla systemów operacyjnych takich jak OS/2 czy NetWare można dodać więcej pamięci operacyjnej RAM lub więcej pamięci masowej - nie można za to zwiększyć mocy przetwarzania danych poprzez zwielokrotnienie liczby procesorów.

Niektóre wersje Unixa zapewniające skalowalność umożliwiają zwiększenie mocy obliczeniowej systemu przez zwiększenie liczby procesorów. Jednakże nie każdy system zarządzania bazami danych potrafi to wykorzystać. Podobnie skalowalny jest system Windows NT. Większość systemów prezentowanych w aktualnym zestawieniu już współpracuje (albo będzie to robić w najbliższej przyszłości) z systemem Windows NT.

Praktyczny wpływ rozmiarów bazy danych na wybór platformy systemowej jest następujący. Bazy danych o wielkości 10-15 GB mogą używać serwerów pracujących pod kontrolą NetWare lub IBM OS/2. Większe - do 100 GB - korzystają z systemów Unix lub VMS. Bazy danych o większych rozmiarach zwykle korzystają z komputerów typu mainframe z ich własnego systemu operacyjnego.

Wśród prezentowanych w bieżącym zestawieniu programów zaplecza są trzy, które korzystają ze wszystkich, wymienionych w tabeli platform systemowych. Są to Oracle 7, Intelligent DataBase firmy Ingres i 4GL/RDBMS firmy Progress Corp. Są i takie pakiety, które korzystają tylko z jednej platformy systemowej - np. Rdb, Database 2/6000 czy NetWare SQL.

W miarę rozrastania się sieci komputerowej może być konieczne dołączenie jej do sieci rozległej lub połączenie ze sobą kilku sieci lokalnych w jedną. Dzięki zdolności DBMS do posługiwania się wieloma protokołami komunikacyjnymi można łączyć rozproszone zasoby sieci niejednorodnych.

Kolejna ważna właściwość bazy danych to rodzaj języka SQL, stosowanego do wymiany informacji z programem frontowym. Ściśle rzecz biorąc w języku SQL jest zwykle formułowane zapytanie (polecenie wykonania usługi), zaś odpowiedzią są dane. Podstawą tego języka jest standard ANSI SQL, ale w użyciu są także i inne "dialekty" SQL, z których najczęściej spotykane to SQL 89, SQL Level 1, SQL Level 2 i SQL Level 2 rozszerzony (with Integrity Enhancement).

Równie ważną cechą systemu DBMS - jest optymalizacja kolejności operacji na rekordach bazy. Realizowana jest ona za pomocą odpowiednich reguł - tzw. syntax based lub na zasadzie bezalgorytmowej - tzw. cost-based.

Niezawodność systemów DBMS i bezpieczeństwo danych łączy się ze stosowaniem backupu danych. Omawiane systemy zarządzania bazami danych stosują backup automatyczny lub warunkowy. W tym ostatnim przypadku archiwizacji podlega tylko część bazy danych, np. z ostatniego dnia. Bezpieczeństwo danych zapewnia także lustrzany, podwojony zapis na dodatkowym dysku - lokalnym lub zdalnym.

Użytkownicy, którzy chcą rozmieścić swe dane na kilku serwerach powinni zwrócić uwagę na cechy, które charakteryzują zarządzanie rozproszonymi, relacyjnymi DBMS.

Fragmentacja danych pozwala na rozszczepienie bazy danych i przesłanie (ale nie kopiowanie) jej rzędów lub kolumn na inne węzły sieci. Replikacja to czynność kopiowania danych (lub ich części) do innych węzłów, bez naruszenia spójności bazy danych. Obie te metody udoskonalają przestrzenne ułożenie danych - tak, aby znalazły się one w miejscach, gdzie najczęściej się z nich korzysta. Obniża to koszty transmisji i zwiększa wydajność systemów.

W wypadku rozproszonych baz danych (położonych na co najmniej dwóch węzłach sieci), stosuje się często dwufazowe blokowanie (twophase commit). Użycie go pozwala uniknąć wieloznaczności i sytuacji konfliktowych przy wykonywaniu transakcji przez serwer DBMS. Transakcja zostaje uznana za ważną, gdy każdy z węzłów wykonał zadanie zgłoszone do realizacji. Jeżeli jakikolwiek z węzłów nie zrealizował usługi, cała transakcja ulega wymazaniu. Jest to więc działanie wg zasady - all-or-nothing - wszystko albo nic.

Replikacja jako metoda zapewniania integralnosci bazy rywalizuje z dwufazowym blokowaniem. Kiedy dane jednej z kopii replikowanej bazy danych są aktualizowane, zmiana taka powinna natychmiast być przeniesiona na inne kopie. Jest to tzw. replikacja synchroniczna. W rzeczywistości użytkownicy DBMS mogą się umówić, że dane takie jak tabela cen mogą być aktualizowane raz na dzień. Jest to replikacja asynchroniczna.

Kolejna ważna cecha systemów DBMS jest posiadanie ogólnego wykazu, słownika danych (global data dictionaries). Serwer, który dostał polecenie wykonania usługi konsultuje się z globalnym wykazem w celu zlokalizowania właściwych danych, odnalezienia ich i dostępu do nich.

Cena podstawowego oprogramowania zaplecza, w zależności od konfiguracji może się wahać od kilkuset USD do kilkuset tys. USD. Koszt samego oprogramowania jest tylko częścią ponoszonych wydatków. Dalsze z nich idą na narzędzia do tworzenia aplikacji frontowych (przy tej okazji warto zwrócić uwagę, że rekordzistą pod względem liczby związanych z serwerem DBMS narzędzi typu "front-end" jest firma Sybase, która - współpracując z innymi firmami - oferuje ponad 600 takich narzędzi), aplikacje, usługi współpracujące, itp. Koszt pełnego DBMS, obsługującego tysiące użytkowników dużych baz danych może przekroczyć 1 mln USD. Podane ceny pochodzą z katalogów producentów - na rynku polskim należy doliczyć do nich także cło i VAT.

Na zakończenie wspomnimy o testach wydajności systemów, obsługujących bazy danych. Powiązanie serwerów DBMS ze sprzętem daje okazję do oceny wydajności pracy całego systemu. W tym celu używa się testów organizacji TPC (Transaction Processing Council). O testach TPC-A, TPC-B i TPC-C pisaliśmy (łącznie z podaniem szczegółowych tabel wyników) w CW nr 40/117.

Zestawienie "Serwery relacyjnych DBMS" opracowano na podstawie materiałów zamieszczonych w periodykach Network World w kwietniu i maju br.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200