Dnes: 20. srpna 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?
    Konkurenční přístup
    Situace, kdy k jednomu zdroji dat (nejčastěji stejným záznamům v tabulce) přistupuje současně více uživatelů. Jedním z úkolů vyspělého SŘBD je zajistit, aby nedošlo k porušení konzistence dat (například aby uživatel z tabulky četl vždy aktuální data).

    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 
     (1400 hl.)
    Do 1 000,- Kč 
     (984 hl.)
    Do 10 000,- Kč 
     (927 hl.)
    Do 25 000,- Kč 
     (1184 hl.)
    Do 50 000,- Kč 
     (941 hl.)
    Do 75 000,- Kč 
     (1081 hl.)
    Více než 75 000,- Kč 
     (925 hl.)

    Celkem hlasovalo: 7442


    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ář
    <<  Srpen  >>
    PoÚtStČtSoNe
     123456
    78910111213
    14151617181920
    21222324252627
    28293031   

    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