Rozproszony DBMS - środowiska baz danych

W tej części samouczka przeanalizujemy różne aspekty pomocne w projektowaniu środowisk rozproszonych baz danych. Ten rozdział rozpoczyna się od typów rozproszonych baz danych. Rozproszone bazy danych można podzielić na jednorodne i niejednorodne bazy danych posiadające dalsze podziały. Następna sekcja tego rozdziału omawia rozproszone architektury, a mianowicie klient-serwer, każdy z każdym i multi-DBMS. Na koniec przedstawiono różne alternatywy projektowe, takie jak replikacja i fragmentacja.

Typy rozproszonych baz danych

Rozproszone bazy danych można ogólnie podzielić na jednorodne i heterogeniczne rozproszone środowiska baz danych, z których każde ma dalsze podziały, jak pokazano na poniższej ilustracji.

Jednorodne rozproszone bazy danych

W jednorodnej, rozproszonej bazie danych wszystkie witryny używają identycznego DBMS i systemów operacyjnych. Jego właściwości to -

• Witryny używają bardzo podobnego oprogramowania.

• Witryny używają identycznego DBMS lub DBMS od tego samego dostawcy.

• Każda witryna zna wszystkie inne witryny i współpracuje z innymi witrynami w celu przetwarzania żądań użytkowników.

• Dostęp do bazy danych uzyskuje się za pośrednictwem jednego interfejsu, tak jakby była to pojedyncza baza danych.

Typy jednorodnej rozproszonej bazy danych

Istnieją dwa typy jednorodnej rozproszonej bazy danych -

• Autonomous- Każda baza danych jest niezależna i funkcjonuje samodzielnie. Są one zintegrowane z aplikacją sterującą i wykorzystują przekazywanie komunikatów do udostępniania aktualizacji danych.

• Non-autonomous - Dane są dystrybuowane w jednorodnych węzłach, a centralny lub nadrzędny system DBMS koordynuje aktualizacje danych w lokalizacjach.

Heterogeniczne rozproszone bazy danych

W heterogenicznej rozproszonej bazie danych różne witryny mają różne systemy operacyjne, produkty DBMS i modele danych. Jego właściwości to -

• Różne witryny używają odmiennych schematów i oprogramowania.

• System może składać się z różnych systemów DBMS, takich jak relacyjne, sieciowe, hierarchiczne lub obiektowe.

• Przetwarzanie zapytań jest złożone z powodu różnych schematów.

• Przetwarzanie transakcji jest skomplikowane ze względu na różne oprogramowanie.

• Witryna może nie wiedzieć o innych witrynach, dlatego współpraca przy przetwarzaniu żądań użytkowników jest ograniczona.

Typy heterogenicznych rozproszonych baz danych

• Federated - Heterogeniczne systemy baz danych są z natury niezależne i zintegrowane razem, dzięki czemu działają jako jeden system baz danych.

• Un-federated - Systemy baz danych wykorzystują centralny moduł koordynujący, za pośrednictwem którego uzyskuje się dostęp do baz danych.

Rozproszone architektury DBMS

Architektury DDBMS są generalnie opracowywane w zależności od trzech parametrów -

• Distribution - Określa fizyczną dystrybucję danych w różnych lokalizacjach.

• Autonomy - Wskazuje podział kontroli nad systemem baz danych i stopień, w jakim każdy składowy DBMS może działać niezależnie.

• Heterogeneity - Odnosi się do jednolitości lub odmienności modeli danych, komponentów systemu i baz danych.

Modele architektoniczne

Niektóre z typowych modeli architektonicznych to -

• Architektura klient - serwer dla DDBMS
• Architektura peer-to-peer dla DDBMS
• Architektura Multi - DBMS

Architektura klient - serwer dla DDBMS

Jest to architektura dwupoziomowa, w której funkcjonalność jest podzielona na serwery i klientów. Funkcje serwera obejmują przede wszystkim zarządzanie danymi, przetwarzanie zapytań, optymalizację i zarządzanie transakcjami. Funkcje klienta obejmują głównie interfejs użytkownika. Mają jednak pewne funkcje, takie jak sprawdzanie spójności i zarządzanie transakcjami.

Dwie różne architektury klient-serwer to -

• Jeden serwer, wielu klientów
• Multiple Server Multiple Client (pokazany na poniższym diagramie)

Architektura peer-to-peer dla DDBMS

W tych systemach każdy peer działa zarówno jako klient, jak i serwer w celu przekazywania usług bazy danych. Rówieśnicy dzielą się swoimi zasobami z innymi rówieśnikami i koordynują swoje działania.

Ta architektura ma ogólnie cztery poziomy schematów -

• Global Conceptual Schema - Przedstawia globalny logiczny widok danych.

• Local Conceptual Schema - Przedstawia logiczną organizację danych w każdym miejscu.

• Local Internal Schema - Przedstawia fizyczną organizację danych w każdej lokalizacji.

• External Schema - Przedstawia widok danych użytkownika.

Architektury Multi - DBMS

Jest to zintegrowany system baz danych utworzony przez zbiór dwóch lub więcej autonomicznych systemów baz danych.

Multi-DBMS można wyrazić za pomocą sześciu poziomów schematów -

• Multi-database View Level - Przedstawia wiele widoków użytkowników składających się z podzbiorów zintegrowanej rozproszonej bazy danych.

• Multi-database Conceptual Level - Przedstawia zintegrowaną wiele baz danych, która zawiera globalne logiczne definicje struktur wielu baz danych.

• Multi-database Internal Level - Przedstawia dystrybucję danych w różnych lokalizacjach i mapowanie wielu baz danych do lokalnych danych.

• Local database View Level - Przedstawia publiczny widok danych lokalnych.

• Local database Conceptual Level - Przedstawia lokalną organizację danych w każdym miejscu.

• Local database Internal Level - Przedstawia fizyczną organizację danych w każdej lokalizacji.

Istnieją dwie alternatywy projektowe dla wielu DBMS -

• Model z poziomem koncepcyjnym obejmującym wiele baz danych.
• Model bez poziomu koncepcyjnego obejmującego wiele baz danych.

Alternatywy projektowe

Alternatywy projektu dystrybucji dla tabel w DDBMS są następujące -

• Brak replikacji i fragmentacji
• W pełni zreplikowane
• Częściowo zreplikowane
• Fragmented
• Mixed

Brak replikacji i fragmentacji

W tej alternatywnej konstrukcji różne tabele są umieszczane w różnych miejscach. Dane są umieszczane tak, aby znajdowały się blisko miejsca, w którym są najczęściej używane. Jest najbardziej odpowiedni dla systemów baz danych, w których odsetek zapytań potrzebnych do połączenia informacji w tabelach umieszczonych w różnych witrynach jest niski. Jeśli zostanie przyjęta odpowiednia strategia dystrybucji, ta alternatywa projektowa pomaga zmniejszyć koszty komunikacji podczas przetwarzania danych.

W pełni zreplikowane

W tym alternatywnym projekcie w każdej lokacji przechowywana jest jedna kopia wszystkich tabel bazy danych. Ponieważ każda witryna ma swoją własną kopię całej bazy danych, zapytania są bardzo szybkie i wymagają znikomych kosztów komunikacji. Wręcz przeciwnie, ogromna nadmiarowość danych wymaga ogromnych kosztów podczas operacji aktualizacji. Dlatego jest to odpowiednie dla systemów, w których wymagana jest obsługa dużej liczby zapytań, podczas gdy liczba aktualizacji baz danych jest niska.

Częściowo zreplikowane

Kopie tabel lub części tabel są przechowywane w różnych witrynach. Dystrybucja tabel odbywa się zgodnie z częstotliwością dostępu. Uwzględnia to fakt, że częstotliwość uzyskiwania dostępu do tabel różni się znacznie w zależności od lokalizacji. Liczba kopii tabel (lub ich części) zależy od częstotliwości wykonywania zapytań dostępu oraz od witryny, która je generuje.

Fragmentowane

W tym projekcie tabela jest podzielona na dwie lub więcej części zwanych fragmentami lub partycjami, a każdy fragment może być przechowywany w różnych miejscach. Uwzględnia to fakt, że rzadko zdarza się, że wszystkie dane przechowywane w tabeli są wymagane w danej witrynie. Ponadto fragmentacja zwiększa równoległość i zapewnia lepsze odzyskiwanie po awarii. Tutaj jest tylko jedna kopia każdego fragmentu w systemie, czyli brak zbędnych danych.

Trzy techniki fragmentacji to -

• Fragmentacja pionowa
• Pozioma fragmentacja
• Fragmentacja hybrydowa

Dystrybucja mieszana

Jest to połączenie fragmentacji i częściowych replikacji. Tutaj tabele są początkowo pofragmentowane w dowolnej formie (poziomej lub pionowej), a następnie te fragmenty są częściowo replikowane w różnych miejscach zgodnie z częstotliwością uzyskiwania dostępu do fragmentów.