COMPUTERWORLD
pod kapotou
Distribuované databázové systémy

Distribuované databázové systémy (DDBS) kombinují dvě technologie: databáze a komunikace. Vznik těchto architektur byl iniciován praxí, kdy v typickém případě obsahoval podnikový informační systém izolované ostrůvky dat, které bylo pro určité uživatelské požadavky nutné zpracovávat najednou, tj. jakoby šlo o jednu databázi. Jinými slovy řečeno, databáze je v takovém případě rozložena na více výpočetních zařízeních se samostatnými procesory, magnetickými disky atd. Její vznik je obvykle dán zdola-nahoru, směřuje se k integraci. Vedle toho existuje způsob shora-dolů, kdy projektant začíná jakoby “na zelené louce”, pracuje s globálním konceptuálním schématem, navrhuje distribuci dat atd. Tento, bohužel dnes méně častý způsob, nabízí naopak bohatou teorii, jeho aplikace v praxi však není příliš rozšířená.

Více procesorů ovšem není jedinou charakteristikou DDBS. Jsou-li procesory umístěny fyzicky pohromadě, hovoří se o paralelních architekturách a dále pak o paralelních databázových systémech. Účel těchto systému je také jiný než u DDBS. Místo o integraci dat jde spíše o zvýšená výkonu centralizovaného počítače. Zde se budeme věnovat případu DDBS, tj. variantě, kdy jednotlivé procesory jsou fyzicky vzdálené, tj. umístěné na jednotlivých místech, a s každým procesorem je svázána nějaká dílčí databáze s eventuálně nezávislým, tj. autonomním provozem. Místa jsou propojena telekomunikačními linkami. Je zřejmé, že i některé varianty architektury klient-server s daty distribuovaným mezi server a klienty, lze považovat za jistý druh DDBS. SŘBD, který zabezpečuje řízení DDBS se nazývá distribuovaný SŘBD (DSŘBD).

Přístupy k DDBS

Způsobů jak navrhnout či hodnotit DDBS je mnoho. Někdy je užitečné je charakterizovat ve třech dimenzích: autonomie, transparence distribuce a heterogennost.

Autonomie se týká distribuce řízení. Může jít o těsné zapojení, volnější autonomii či úplnou izolaci. V těsném spojení je distribuovaná databáze vybudována nad lokálními databázemi. Každé místo má úplnou znalost o datech v celém DDBS a může řídit či zpracovávat požadavky využívající data na různých místech. Při volnější autonomii participují jednotlivá místa ve federaci, tj. jen část jejich dat je sdílena. Typicky, lokální systém potřebuje jisté modifikace, aby si byl vědom ostatních míst ve federaci. V úplné izolaci jsou místa autonomní, neví i o sobě. DSŘBD tvoří speciální vrstvu nad lokálními systémy. Schopnosti takového systému koordinovat a optimalizovat činnosti nad více místy jsou dost omezené, často se pracuje pouze s read-only požadavky. Každá z těchto variant vyžaduje jiný přístup ke schématu, prostřednictvím kterého lze klást globální požadavky.

Transparence distribuce znamená, do jaké míry je distribuce dat v jednotlivých místech viditelná uživatelům, či aplikacím. Existuje několik možností, jak distribuovat data:

  • distribuce základních relací databáze, tj. jednotkou distribuce je tabulka, která je vždy celá umístěna v místě, kde se nejčastěji používá (obr. 1).
  • distribuce odvozených dat, tj. jednotkou distribuce je tabulka, která vznikne jako výsledek dotazu (obr. 2). Je-li vytvořena a umístěna v daném místě, nemá již žádné napojení na základní relace databáze (databází).
  • distribuce typu momentka (snapshot), která vzniká podobně jako v předchozím případě, pouze s tím rozdílem, že data v momentce jsou periodicky aktualizována znovuprovedením zdrojového dotazu na aktuálních základních relacích (obr. 3). Jde o mechanismus podobný pojmu pohled v SQL, data jsou zde však materializovaná, tj. na daném místě skutečně existují.
  • replikované relace, kdy vícenásobné kopie jedné (logické) tabulky jsou umístěny na různých místech v DDBS (obr. 4).
  • fragmentované relace, které vzniknou buď horizontálním, vertikálním či kombinovaným rozdělením základních relací. V prvním případě se relace rozloží do několika množin řádků, v druhém případě do několika množin sloupců, poslední případ využívá aplikaci obou technik (obr. 5). V případě horizontální fragmentace se použije pro rozdělení řádků do skupin obvykle nějaká podmínka (může zapojit do procesu rozdělování i vztažená data s další relace). Důležité kritérium pro vertikální fragmentaci je, aby projekce základní relace vedly k bezztrátové dekompozici relace. Jde o to, aby relační spojení fragmentů dalo opět původní tabulku. Toho lze dosáhnout např. tak, že všechny vertikální fragmenty obsahují klíč původní tabulky.


místo 1 místo 1

DB R1 DB R3 R3=f (R1,R2)

R1 R1

R2 místo 2 R2 místo 2

R2 R4 R 4=g(R1,R2)

 

Obr.1: Distribuce relací Obr. 2: Distribuce odvozených dat

místo 1 místo 1

DB f R3 DB R1

R1 R1 R2

R2 R2 místo 2

g R4 R1

R2

Obr. 3: Distribuce typu momentka

Obr. 4. Replikované relace

místo 1

DB R11

R1 R21

R2 místo 2 R1 = R11 È R12

R12 R2 = R21 * R22

R22

Obr. 5: Fragmentované relace

Heterogennost lze v DDBS chápat různě. Může jít o různý hardware v jednotlivých místech, lokální SŘBD mohou být také různých typů, nebo dokonce nad různými databázovými modely. Různé mohou být i příslušné operační systémy, či komunikační protokoly

Architektura schémat v DDBS

Původní přístup k DDBS vedený návrhem shora dolů nabízí rozsáhlou obecnou architekturu schémat (obr. 6), která je možné při návrhu využít. Globální dotaz je formulován nad globálním konceptuálním schématem (resp. globálním externím schématem), globální schéma distribuce říká, na kterých místech a v jakých kopiích jsou data distribuována, schéma lokální reprezentace definuje, co se vlastně exportuje z míst do celku, lokální konceptuální schémata (v event. různých modelech) popisují konceptuálně data v  místech, lokální interní schéma lze v místě ztotožnit např. s databázovým schématem.

 

místo 1 místo n

 

Globální externí schéma ... Globální externí schéma

 

 

Globální konceptuální schéma

 

 

Globální schéma distribuce

 

 

Schéma lokální reprezentace Schéma lokální reprezentace

 

 

Lokální konceptuální schéma Lokální konceptuální schéma

 

 

Lokální interní schéma Lokální interní schéma

 

Obr. 6 Schémata v DDBS

Charakteristiky DSŘBD

Jaké charakteristiky by měl splňovat “opravdový” DSŘBD, popsal v roce 1987 snad nejznámější databázový konzultant a publicista Chris Date. Jeho 12 pravidel lze rozložit podle výše uvedených dimenzí, tj. autonomie (A), distribuce (D) a heterogennosti (H).

A1. Lokální autonomie. V každém místě jsou data řízena lokálním SŘBD, včetně integrity, utajení apod.

A2. Ve všech službách se nespoléhá se na žádné centrální místo. Vše je distribuované.

A3. Kontinuálnost. Provoz v jednom místě (např. upgrade SŘBD, odstranění jedné tabulky apod.) by neměl příliš narušovat provoz DDBS jako celku.

D4. Nezávislost na místě. Uživatel nemusí vědět, kde jsou uložena potřebná data.

D5. Nezávislost na fragmentaci. Uživatel nemusí vědět, kde jsou uloženy fragmenty relací, realizuje-li svůj požadavek. (Toto pravidlo může být v konfliktu s A1).

D6. Nezávislost na replikaci. Jde o podobné zásady jako D5.

D7. Možnost distribuovaného zpracování dotazu. Nemělo by být nutné přesouvat zbytečně data ke zpracování dotazu do jednoho místa.

D8. Distribuované zpracování transakcí. Používá se dvoufázový potvrzovací protokol (2PC) - viz Databázová abeceda CW51, 1996). Opět může dojít ke konfliktu s A1. Je totiž zvýšený tlak na blokování dat v daném místě kvůli čekání na potvrzení dílčích transakcí v jiných místech.

H9. Nezávislost na hardware.

H10. Nezávislost na operačním systému.

H11. Nezávislost na síti.

H12. Nezávislost na SŘBD.

Vznik pojmu distribuovaného SŘBD se datuje do počátku 70. let, do doby vývoje výzkumného projektu IBM - systému R* . Další dodávkou distribuované architektury IBM je DRDA (distributed relational data architecture). Jde o pokus integrovat data rozmístěna na počítačích pod různými verzemi SŘBD DB2. Prvním produktem v této oblasti byl zřejmě INGRES/Star, ohlášený v r. 1987. I když ORACLE používal distribuované rysy koncem 80. let, skutečná podpora distribuovaného databázového zpracování je až ve verzi ORACLE 7 z r. 1993.

Praxe ukázala, že tak jak jsou DDBS koncipovány v Dateových pravidlech a v teorii 70. a 80. let, vzniká řada problémů, jejichž důsledkem je implementace pouze torza původních idejí. Patří mezi ně např.: řízení katalogu dat, umístění (distribuce) schématu, detekce či předcházení uváznutí, synchronizace aktualizací. S posledním bodem souvisí již zmíněný populární mechanismus 2PC, který zamyká synchronně všechny kopie nutné pro splnění požadavku až do okamžiku, kdy odpovědné místo neobdrží zprávu o potvrzení. Současné tzv. replikační servery řeší daný problém mnohem volněji a pro většinu praxe postačujícím způsobem. Zaslouží si samostatné heslo v některé z příštích pokračování databázové abecedy.



<seznam dílů seriálu>   <COMPUTERWORLD>