Dnes: 24. února 2017    | Registrace | Hledáme | Redakce | Info | Testy | Školení | Ocenění | Nápověda | Čtenář: nepřihlášen

Rychlé odkazy
  • Hlavní stránka
  • Seznam rubrik
  • Ankety
  • Editoriály
  • TOP 15
  • KONFERENCE 2008
  • KONFERENCE 2007
  • KONFERENCE 2006
  • KONFERENCE 2005
  • KONFERENCE 2004
  • Sborník
  • Testy
  • Virtuální školení
  • Personalizace


  • Hledáte práci?
    Hledáme redaktora - pojďte s námi tvořit Databázový svět!

    Vyhledávání

    Hledej
    na Databázovém světě!



    Rozšířené vyhledávání

    Rubriky
    Aktuality
    Bezpečnost
    Business
    Česká scéna
    Datové sklady
    Dokumentace
    Dotazovací jazyky
    Hardware
    Historie
    Komentáře
    Literatura
    Metodologie
    Nondb
    Open Source
    Poradna
    Produkty
    Případové studie
    Redakce
    Rozhovory
    Standardy
    Technologie
    Tipy - triky
    Tiskové zprávy
    Vývoj
    Vývojové nástroje
    Zajímavosti

    Co je to?
    SŘBD
    (Systém řízení báze dat)

    Programový systém umožňující vytváření, údržbu a použití báze dat. Podle komplexnosti je možné SŘBD rozdělit na nižší (např. PC Fand), střední (FoxPro) a vyspělé (Oracle 9i).

    Akce
    Dynamická Datová Centra
    - na semináři se seznámíte s komplexním řešením a koncepcí Dynamických Datových Center od Fujitsu Siemens Computers se speciálním důrazem na řešení FlexFrame.

    Textová inzerce
    IBPhoenix - Vše o InterBase a Firebirdu.

    Smějete se rádi? - Pak je pro vás Vtipník to pravé!

    Prodejce reklamy - Hledáme schopného prodejce reklamního prostoru, možnost i externí spolupráce.

    Přihlášený čtenář
    Nepřihlášený čtenář

    O portálu
    Databázový svět
    ISSN: 1213-5933

    Web je optimalizován pro rozlišení 1024x768, nicméně kromě větších rozlišení podporujeme i 800x600. Podrobnosti najdete zde.

    Chcete-li mít kdykoliv možnost zkontrolovat obsah našeho portálu, můžete využít podporu rss. Podrobnosti najdete zde.
    Rozvrhy a transakce


    [Technologie] - Databázové platformy jsou z pohledu správy dat velmi inteligentní. Zajišťují mnoha způsoby konzistenci dat, správu dat na disku či třeba řízení současného přístupu více uživatelů.



    Základním stavebním prvkem jsou transakce. ACID koncepce, kterou nám transakce pomáhají naplnit, nám zajišťuje mnoho pozitivních vlastností, se kterými by databáze byly jen tupá úložiště. Pokud uvažujeme o jedné transakci v daný čas, situace není obtížná. Jakmile však začneme uvažovat více souběžných transakcí, dostaneme se do velmi zajímavé oblasti.

    Snahou databázového stroje je provádět transakce – respektive operace v nich tak, aby výsledek dopadl, jako by byly spuštěny za sebou. A zároveň maximalizovat propustnost, tedy mít v daný okamžik co nejvíce zároveň běžících transakcí. Není těžké domyslet, že tyto dva požadavky jdou proti sobě. Abychom mohli některé operace v transakci lépe uchopit, používáme při popisu posloupnosti akcí tzv. rozvrhy.

    Zajímá nás, jaké rozvrhy jsou dobré – takové, po jejichž skončení budou data v konzistentním stavu i při souběhu transakcí – bez ohledu na původní stav a význam transakcí. Ve zjednodušeném modelu se díváme pouze na pořadí operací čtení (r) a zápisu (w). Také definujeme tzv. konfliktní akce. Jedná se o r1(A),w2(A); w2(A),r1(A); w1(a),w2(a), kde rX(Y), respektive wX(Y) představuje čtení, respektive zápis položky Y transakcí X. Pokud se akce transakcí neprolínají, dostáváme tzv. sériový rozvrh.

    Základní operací, kterou může engine v rámci "optimalizace" souběhu provádět, je výměna nekonfliktních akcí. Nový rozvrh je poté konfliktně ekvivalentní původnímu rozvrhu. S touto definicí můžeme vystavět tzv. konfliktně serializovatelný rozvrh – je konfliktně ekvivalentní sériovému rozvrhu.

    Velmi vhodné pro sledování těchto závislostí jsou grafové struktury. V závislostním grafu G uzly reprezentují transakce a orientovaná hrana Tx → Ty závislost mezi Tx a Ty. Pokud například w2(A) < r1(A), w1(C) < r2(C), w2(B) < r3(B), w2(C) < r3(C), potom T2 → T1, T1 → T2, T2 → T3, T2 → T3.

    Graf nám pak pomůže určit vlastnost rozvrhů. S1 a S2 jsou konfliktně ekvivalentní, pokud G(S1) == G(S2) (opačný směr neplatí obecně). Pokud je závislostní graf G acyklický (neobsahuje smyčky), je rozvrh konfliktně serializovatelný (platí oběma směry).

    Otázkou nyní zůstává, jak serializovatelné rozvrhy zajistit. Základní, a velmi starou, myšlenkou je protokol zámků. Konkrétně se jedná o Two-Phase Locking (neplést s Two-Phase Commit). V první fázi je povoleno pouze zamykat a v druhé fázi je povoleno pouze odemykat. Existují také rozšířené Strict Two-Phase Locking , respektive Strong Strict Two-Phase Locking. Vzhledem k tomu, že takto jednoduché zamykání neposkytuje příliš dobrou propustnost, dělí se zámky dále jemněji, pro lepší granularitu – například shared- respektive exclusive-lock, incremental lock apod. Naopak pro zvýšení výkonu se často nezamykají jen pouhé záznamy, ale větší celky, například databázové stránky. Podrobný popis ponechme čtenáři jako cvičení.

    Přidáme-li si do našich akcí dále operace commit (c) a rollback/abort (a), zjistíme, že se situace ještě více komplikuje. Pokud totiž můžeme změny, které jsme provedli, zrušit, můžeme vyvolat kaskádní rollback. Případně rozvrh nemusí být obnovitelný. Obnovitelný rozvrh je rozvrh v případě, kdy všechny transakce vydají příkaz commit až po commitu všech transakcí ze kterých čtou. Například striktní Two-Phase Locking zajišťuje obnovitelnost rozvrhu. Aby bylo zabráněno kaskádnímu rollbacku, potřebujeme ještě silnější podmínku, a to, že každá transakce čte pouze hodnoty dokončených transakcí. Nakonec ještě tzv. striktní rozvrh je takový rozvrh, kde transakce čtou a zapisují hodnoty pouze dokončených transakcí. Matematicky zapsáno je tedy: sériový ⊂ striktní ⊂ zamezující kaskádnímu rollbacku ⊂ obnovitelný.

    Ačkoli se za začátku mohlo zdát, že správa dat v databázi není zas až tak obtížná, vidíme, že zajištění dobré propustnosti a zároveň konzistence dat (ve smyslu interakce mezi transakcemi) není vůbec jednoduchý úkol, neboť se nám spojuje mnoho faktorů (a to pomíjíme například uváznutí, volbu oběti, správu běžících transakcí apod.)

    Samozřejmě "jednoduché" zamykání pomocí zámků není jediný způsob, jak zajistit "nepomíchání" změn dat. Zamykat lze také za pomocí zámků ve stromových strukturách apod. Dokonce nemusíme využívat ani zámky. Jednou z oblíbených, a velmi chytrých alternativ (poprvé implementovanou Jimem Starkeym v Jrd (předchůdce IB/FB)), je multigenerační architektura (MGA, MVCC, …), o které jste si mohli přečíst i u nás.

    ( Celý článek! | Autor: Jiří Činčura | Počet komentářů: 0 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

    Anketa
    Kolik ročně utratíte za dovolené?

    Nic 
     (958 hl.)
    Do 1 000,- Kč 
     (757 hl.)
    Do 10 000,- Kč 
     (718 hl.)
    Do 25 000,- Kč 
     (852 hl.)
    Do 50 000,- Kč 
     (745 hl.)
    Do 75 000,- Kč 
     (777 hl.)
    Více než 75 000,- Kč 
     (732 hl.)

    Celkem hlasovalo: 5539


    Poslední komentáře
    frontierd@126.com
    frontierd@126.com
    frontierd@126.com
    c
    http://www.coachoutl

    Newsletter
    Přihlaste si nezávazně - i bez registrace - odběr informačního newsletteru. Podrobné informace najdete zde.

    Emailová adresa:


    Kalendář
    <<  Únor  >>
    PoÚtStČtSoNe
      12345
    6789101112
    13141516171819
    20212223242526
    2728     

    Redakci připojuje


    Nejčtenější

    Databáze je prázdná!


    Nejvíce komentářů

    Databáze je prázdná!


    Reklama






    Nenechte si ujít články na dalších webech




    Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
    nebo registrovanými ochrannými známkami příslušných vlastníků.

    Databázový svět | dfKlub - digitální fotografie | Vtipník - vtipy přímo k Vám | Reminder - přestaňte zapomínat | Databázový svět

    Copyright (c) 2004 AVRE Publishing, spol. s r.o. Všechna práva vyhrazena