Dnes: 26. června 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?
    Databázový stroj
    (Database Engine)

    Pod pojmem Database Engine (tedy pod databázovým strojem) se obvykle rozumí jádro databázového serveru a základní obslužné programy tohoto jádra (například zajišťující vzdálené připojení uživatelů). Lze tedy říci, že databázový stroj je podmnožinou databázového serveru, přičemž pod pojmem databázový server je nutné vidět vybavení (typicky softwarové) pracující nad danou databází a zajišťující veškeré činnosti (včetně všech potřebných komunikací), které nad danou databází mají být zajišťovány.

    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.
    Firebird – pomocí plánu k lepším časům


    [Tipy - triky] - Ruční plánování dotazů patří mezi způsoby, po kterých obvykle sáhneme, až již nic jiného nepomáhá. V tomto příspěvku si ukážeme, jak může tohoto plánování použít člověk, který není zcela detailně obeznámen se strukturou databáze a třeba se i dosud klauzuli PLAN podvědomě – pln strachu – vyhýbal.



    Položení dotazu můžeme rozdělit do tří částí:

    1. Příprava (Prepare)
    2. Vykonaní (Execute)
    3. Přenos dat, načítaní dat (Fetch).

    Celkový čas je dán součtem všech tří časů. My se budeme snažit zrychlit pouze čas přípravy, nikoliv čas vykonání. Na první pohled by se mohlo zdát, že čas přípravy je zanedbatelný, ale jak si ukážeme není a může tvořit podstatnou část celkového času. Bývá tomu obvykle v případě, že existuje více různých indexů na tabulkou. Tento jev lze podstatně omezit přípravou dotazu, ale ne vždy je toto možné (například při využití PHP cgi modulu).

    Ukázka vykonání s (optimalizátor nemusí nic dělat) a bez (optimalizátor musí sestavit plán) PLAN klauzule:

    order by iddevice, edate
    
    PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
    select first 1 edate from products where iddevice=1 
    
                   EDATE 
    ==================== 
    
    29-JUN-2002 15:16:49 
    
    Current memory = 1899688
    Delta memory = 0
    Max memory = 1989764
    Elapsed time= 0.11 sec
    Buffers = 2048
    Reads = 0
    Writes 0
    Fetches = 247
    

    select first 1 edate from products where iddevice=1 
    PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
    order by iddevice, edate
    PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
    
                   EDATE 
    ==================== 
    
    29-JUN-2002 15:16:49 
    
    Current memory = 844536
    Delta memory = 0
    Max memory = 1989764
    Elapsed time= 0.01 sec
    Buffers = 2048
    Reads = 0
    Writes 0
    Fetches = 41
    

    Celý trik spočívá v tom, že nebudeme vymýšlet vlastní plán, ale necháme optimalizátor, aby nám plán sestavil a ten plán použijeme. Tím dojde k tomu, že příprava dotazu se podstatně urychlí (celkový čas v našem případě zhruba 10x!)

    Ukázka zrychlení původního dotazu:

    select min((
      select first 1 edate 
        from products where iddevice=D.id 
        order by iddevice, edate))
      from Devices D
    
    PLAN (D NATURAL)
    PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
    
                     MIN 
    ==================== 
    
    29-JUN-2002 15:16:49 
    
    Current memory = 1915184
    Delta memory = 1071740
    Max memory = 1989932
    Elapsed time= 0.72 sec
    Buffers = 2048
    Reads = 0
    Writes 0
    Fetches = 1702
    

    Po přidání plánu (toho, který vrací optimalizátor dotazu):

    select min((
      select first 1 edate 
        from products 
        where iddevice=D.id 
          PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
         order by iddevice, edate))
      from Devices D
        PLAN (D NATURAL)
    
    PLAN (D NATURAL)
    PLAN (PRODUCTS ORDER PRODUCTSDEVCNT)
    
                     MIN 
    ==================== 
    
    29-JUN-2002 15:16:49 
    
    Current memory = 860504
    Delta memory = 0
    Max memory = 1989932
    Elapsed time= 0.01 sec
    Buffers = 2048
    Reads = 0
    Writes 0
    Fetches = 131
    

    Tento dotaz obchází skutečnost chybějícího indexu na polem eDate s tím, že existuje index nad polem idDevice (zároveň cizí klíč) a eDate. Původní dotaz vypadal takto:

    select MIN(eDate) FROM Products
    
    PLAN (PRODUCTS NATURAL)
    
                     MIN 
    ==================== 
    
    29-JUN-2002 15:16:49 
    
    Current memory = 843444
    Delta memory = 0
    Max memory = 1989932
    Elapsed time= 9.31 sec
    Buffers = 2048
    Reads = 16814
    Writes 0
    Fetches = 4182504
    

    Celkově se mi podařilo zrychlit dotaz téměř 1000x.

    Tento způsob byl testován na platformě FB 1.5.1. Výsledné časy byly měřeny při 2.1 milionu záznamů na při CPU Intel Celeron@550 MHz. V praxi se mi osvědčilo vkládat PLAN pouze tehdy, pokud byl dotaz kritický. Technika zrychlení přípravy má smysl pouze tehdy, pokud příprava zabere více jak cca 30% celkového času a nelze rozumě využít možnosti prepare.

    Na závěr jedna dobrá zpráva – vývojáři FB připravují "Statament cache", která by měla podstatným způsobem eliminovat čas potřebný na přípravu dotazu (o to bude moci být příprava důkladnější) tím, že budou vykonávací plány již sestaveny.

    Prosím podělte se s ostatními o vlastními zkušenostmi s optimalizací dotazů pro (nejen) Firebird.

    O autorovi
    Slavomír Skopalík vystudoval kybernetiku na VUT Brno se zaměřením na měření a systémové inženýrství. Podílel se na návrhu tvorbě regresních testů pro Firebird. V současné době je jednatelem firmy Elekt Labs, která se zaměřuje především na dodávky malých informačních systémů s vysokou přidanou hodnotou postavených na SQL databázi Firebird. Autor pracuje s databázemi Interbase a Firebird od roku 1994, posledních pět let především v průmyslu při řešení plánování a monitorování výroby.

    ( Celý článek! | Autor: Slavomír Skopalík | Počet komentářů: 1 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

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

    Nic 
     (1292 hl.)
    Do 1 000,- Kč 
     (911 hl.)
    Do 10 000,- Kč 
     (856 hl.)
    Do 25 000,- Kč 
     (1114 hl.)
    Do 50 000,- Kč 
     (875 hl.)
    Do 75 000,- Kč 
     (1012 hl.)
    Více než 75 000,- Kč 
     (851 hl.)

    Celkem hlasovalo: 6911


    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ář
    <<  Červen  >>
    PoÚtStČtSoNe
       1234
    567891011
    12131415161718
    19202122232425
    2627282930  

    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