W artykule ''Oprogramowanie klient/serwer'' (ComputerWorld nr 27) opisano usprawnienie obsługi bazy danych poprzez zastosowanie przetwarzania typu klient/serwer. Przypomnijmy tylko, że chodzi o rozdzielenie funkcji spełnianych przez program aplikacyjny pomiędzy maszynę zwaną serwerem bazy danych i stacje robocze, przy których pracują użytkownicy końcowi. Obecnie zajmiemy się różnymi metodami realizacji takiego podziału funkcji, a także omówimy bardziej szczegółowo pewne aspekty trybu przetwarzania klient/serwer.

Kiedy przetwarzanie klient/serwer jest korzystne?

Nie należy sądzić, że zastosowanie modelu klient/serwer zawsze okaże się korzystne, (w szczególności kiepsko skonstruowany program pozostanie kiepskim programem, niezależnie od środowiska, w jakim będzie uruchamiany). A oto kilka zagadnień, które warto wziąć pod uwagę podejmując decyzję o wyborze rodzaju przetwarzania. Często uważa się, że praca w środowisku klient/serwer zawsze zapewnia lepszą wydajność, niż zastosowanie pojedynczego komputera. Nie jest to prawda. Gdy wszystkie komponenty aplikacji są uruchamiane na tej samej maszynie, wydajność aplikacji jest ograniczona możliwościami maszyny. Przetwarzanie w trybie klient/serwer może poprawić wydajność aplikacji tylko wtedy, gdy zasoby pojedynczego komputera są zbyt małe dla danego programu - tzn. występuje nadmierne obciążenie takich elementów systemu, jak pamięć operacyjna, procesor itd.

Jeśli "wąskim gardłem" staje się dostęp do procesora, mamy dwie możliwości. Pierwsza z nich, to zamiana procesora (lub komputera) na maszynę wieloprocesorową. Druga możliwość, to podzielenie przetwarzania i przekazanie części pracy procesorowi innej maszyny. Często wyjście to daje w rezultacie lepszy współczynnik kosztu w stosunku do wydajności.

Chcąc zwiększyć zasoby pamięci dostępne dla programu aplikacyjnego, możemy albo powiększyć pamięć naszego komputera, albo rozdzielić przetwarzanie tak, by procedury związane z dostępem do bazy wykorzystywały pamięć serwera, a pozostała część przetwarzania była wykonywana na komputerze klienta.

Gdy występują problemy związane z komunikacją z dyskiem, mamy do dyspozycji dwa rozwiązania: podzielić bazę danych, rozmieszczając ją na kilku dyskach i zmniejszając przez to komunikację z pojedynczym dyskiem lub też rozdzielić przetwarzanie aplikacji, zlecając serwerowi obsługę komunikacji z dyskiem.

Przy konieczności jednoczesnego blokowania dostępu do wielu rekordów bazy danych sytuację można rozładować, zlecając obsługę tej samej liczby użytkowników kilku aktywnym procesom serwera. Korzystne jest przy tym podzielenie bazy na woluminy, rezydujące fizycznie na różnych dyskach (logicznie baza wielowoluminowa funkcjonuje na ogół identycznie jak jedna duża baza).

Jeśli nasza aplikacja pracuje na jednym komputerze, musi to być odpowiednio duża maszyna, a co za tym idzie, odpowiednio droga. Przy rozproszonym przetwarzaniu każda z funkcji może być wykonywana na optymalnie dobranej platformie. Tak więc większa (i droższa) maszyna może być zastosowana tam, gdzie jest to konieczne, natomiast dla pozostałej części przetwarzania przeznaczamy słabszy (i tańszy) komputer, często redukując przez to średni koszt jednej transakcji.

Model klient/serwer w kilku systemach obsługi baz danych

Funkcje spełniane przez typową aplikację obsługującą bazę danych można podzielić na cztery kategorie. Podział ten przedstawiono na rysunku. Wszystkie wymienione czynności mogą być wykonywane przez ten sam komputer. Często jednak korzystniej jest rozdzielić przetwarzanie pomiędzy komputer użyt-kownika (klienta) i komputer, na którym zainstalowany jest serwer. Maszyny te komunikują się ze sobą poprzez sieć.

Tabela 1 przedstawia, w jaki sposób przetwarzanie zostało podzielone między serwer i klienta w czterech systemach obsługi baz danych: Ingresie, Oracle, Progressie i Sybase. Literami A,B,C,D oznaczono funkcje spełniane przez aplikację zgodnie z rys. 1.

Progress Oracle Ingres, Sybase

KLIENT A, B, C A, B A, część B

SERWER część C, D C, D część B, C, D

W systemie Progress proces serwera odpowiedzialny jest jedynie za bezpośredni dostęp do bazy danych. Pozostała część przetwarzania jest wykonywana na stacji roboczej przez proces klienta. W niektórych przypadkach (takich jak nawiasowanie indeksów) serwer wykonuje część optymalizacji. W rezultacie serwer jest w stanie obsłużyć w krótkim czasie wiele zapytań do bazy, ponieważ nie zajmuje się ich optymalizacją ani czynnościami związanymi z wewnętrzną logiką aplikacji. Aplikacje pisane w Progressie na pojedynczą maszynę (np. na PC pod DOS-em) mogą być przenoszone bez żadnych zmian do środowiska klient/serwer (np. w sieci Novell).

W systemach Ingres i Sybase serwer odpowiada zarówno za dostęp do bazy danych, jak i łączenie i optymalizację zapytań. Poza tym w obu tych systemach projektant aplikacji ma możliwość przekazania procesowi serwera części procedur związanych z wewnętrzną logiką aplikacji (w formie skompilowanych procedur przechowywanych w bazie danych i wykonywanych przez serwer). Rozwiązanie to pozwala niekiedy na zmniejszenie częstotliwości komunikacji między klientem a serwerem.

W Oracle'u proces klienta zajmuje się interfejsem z użytkownikiem i wewnętrzną logiką aplikacji, natomiast serwer zajmuje się dostępem do bazy danych, a także łączeniem i optymalizacją zapytań.

Linia podziału pomiędzy czynnościami klienta i serwera przebiega różnie w różnych systemach. Nasuwa się pytanie: który model jest najlepszy? Wydaje się, że trudno jest odpowiedzieć na to pytanie jednoznacznie.

W systemach, w których optymalizacja zapytań jest wykonywana przez serwer (Ingres, Sybase, Oracle), prawdopodobnie mniej informacji jest przesyłanych pomiędzy klientem i serwerem. Z kolei możliwość przekazania serwerowi części procedur związanych z logiką aplikacji (Ingres, Sybase) daje projektantowi większą swobodę w kształtowaniu sposobu funkcjonowania programu.

W systemie Progress serwer zajmuje się tylko dostępem do bazy, pozostałe czynności pozostawiając klientowi. Ponieważ komputery typu desktop stają się coraz tańsze w stosunku do serwerów, rozwiązanie takie zapewnia często lepszy współczynnik kosztu w stosunku do wydajności. Pewną wadę może natomiast stanowić potrzeba komunikacji sieciowej podczas wykonywania optymalizacji zapytania przez klienta. Należy jednak zauważyć, że jeśli optymalizacja jest wykonywana przez serwer, to każde zapytanie jest przez proces serwera kompilowane, co może spowalniać obsługę odwołań do bazy.