![]() |
![]() |
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:
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> |