Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Query Processing in DBMS

Lipyeow
November 20, 2015

Query Processing in DBMS

Query processing and optimization

Lipyeow

November 20, 2015
Tweet

More Decks by Lipyeow

Other Decks in Education

Transcript

  1. ICS  321  Data  Storage  &  Retrieval   Overview  of  Query

     Processing   Prof.    Lipyeow  Lim   InformaBon  &  Computer  Science  Department   University  of  Hawaii  at  Manoa   1   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa  
  2. Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   2

      Parse  Query   Enumerate   Plans   EsBmate   Cost   Choose     Best  Plan   Evaluate   Query  Plan   Result   Query   SELECT  *  FROM  Reserves  WHERE  sid=101   σSid=101 Reserves SCAN (sid=101) Reserves IDXSCAN (sid=101) Reserves Index(sid) fetch 32.0   25.0   Pick  B   A B                        Evaluate    Plan  A   Optimizer
  3. Query  Processing   •  Query  Execu=on  Plan  (QEP):  tree  of

     database  operators.   –  At  high-­‐level,  relaBonal  algebra  operators  are  used   –  At  low-­‐level,    RA  operators  with  parBcular  implementaBon   algorithm.   •  Plan  enumera=on:  find  equivalent  plans   –  Different  QEPs  that  return  the  same  results   –  Query  rewriBng  :  transformaBon  of  one  QEP  to  another   equivalent  QEP.   •  Cost  es=ma=on:  a  mapping  of  a  QEP  to  a  cost   –  Cost  Model:  a  model  of  what  counts  in  the  cost  esBmate.  Eg.   Disk  accesses,  CPU  cost  …   •  Query  Op=mizer:     –  Explores  the  space  of  equivalent  plan  for  a  query   –  Chooses  the  best  plan  according  to  a  cost  model   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   3  
  4. Query  ExecuBon  Plans   •  A  tree  of  database  operators:

     each  operator  is   a  RA  operator  with  specific  implementaBon   •  SelecBon  σ:  Index  Scan  or  Table  Scan   •  ProjecBon  π:     – Without  DISTINCT  :  Table  Scan   – With  DISTINCT  :  requires  sorBng  or  index  scan   •  Join              :     – Nested  loop  joins  (naïve)   – Index  nested  loop  joins   – Sort  merge  joins   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   4  
  5. EnumeraBng  Plans:  Access  Paths   •  An  access  path  is

     a  method  of  retrieving  tuples.   Eg.  Given  a  query  with  a  selecBon  condiBon:   –  File  or  table  scan   –  Index  scan   •  Index  matching  problem:  given  a  selecBon   condiBon,  which  indexes  can  be  used  for  the   selecBon,  i.e.,  matches  the  selecBon  ?   –  SelecBon  condiBon  normalized  to  conjuncBve  normal   form  (CNF),  where  each  term  is  a  conjunct   –  Eg.  (day<8/9/94  AND  rname=‘Paul’)  OR  bid=5  OR   sid=3   –  CNF:  (day<8/9/94  OR  bid=5  OR  sid=3  )  AND                       (rname=‘Paul’  OR  bid=5  OR  sid=3)     Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   5  
  6. Index  Matching   •  A  tree  index  matches  a  selecBon

     condiBon  if  the   selecBon  condiBon  is  a  prefix  of  the  index  search   key.   •  A  hash  index  matches  a  selecBon  condiBon  if  the   selecBon  condiBon  has  a  term  a)ribute=value  for   every  alribute  in  the  index  search  key   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   6   I1: Tree Index (a,b,c) I2: Tree Index (b,c,d) I3: Hash Index (a,b,c) Q1: σ a=5 AND b=3 Q2: σ a=5 AND b>6 Q3: σ b=3 Q4: σ a=5 AND b=3 AND c=5 Q5: σ a>5 AND b=3 AND c=5
  7. One  Approach  to  SelecBons   •  The  selec=vity  of  an

     access  path  is  the  size  of  the   result  set  (in  terms  of  tuples  or  pages).   –  SomeBmes  selecBvity  is  also  used  to  mean  reduc=on   factor:  fracBon  of  tuples  in  a  table  retrieved  by  the   access  path  or  selecBon  condiBon.   •  Eg.  Consider  the  selecBon:        day<8/9/94  AND  bid=5  AND  sid=3   –  Tree  Index(day)     –  Hash  index  (bid,sid)   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   7   1.  Find  the  most  selec3ve  access  path,  retrieve  tuples  using  it   2.  Apply  remaining  terms  in  selecBon  not  matched  by  the   chosen  access  path  
  8. Nested  Loop  Join   For each data page PS1 of

    S1 For each tuple s in PS1 For each data page PR1 of R1 For each tuple r in PR1 if (s.sid==r.sid) then output s,r     •  Worst  case  number  of  disk  reads        =    Npages(S1)  +  |S1|*Npages(R1)   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   8   sid   bid   day   22   101   10/10/96   58   103   11/12/96   sid   sname   ra=ng   age   22   DusBn   7   45.0   31   Lubber   8   55.5   58   Rusty   10   35.0   R1 S1
  9. Index  Nested  Loop  Join   For each data page PS1

    of S1 For each tuple s in PS1 if (s.sid ∈ Index(R1.sid)) then fetch r & output <s,r>     •  Worst  case  number  of  disk  reads  with  tree  index      =    Npages(S1)  +  |S1|*(  1  +  logF  Npages(R1))   •  Worst  case  number  of  disk  reads  with  hash  index      =    Npages(S1)  +  |S1|*  2   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   9   sid   bid   day   22   101   10/10/96   58   103   11/12/96   sid   sname   ra=ng   age   22   DusBn   7   45.0   31   Lubber   8   55.5   58   Rusty   10   35.0   R1 S1 Index(R1.sid)  
  10. Sort  Merge  Join   1.  Sort S1 on SID 2. 

    Sort R1 on SID 3.  Compute join on SID using Merging algorithm •  If  join  alributes  are  relaBvely  unique,  the  number  of  disk   pages        =  Npages(S1)  log  Npages(S1)        +  Npages(R1)  log  Npages(R1)        +  Npages(S1)  +  Npages(R1)   •  What  if  the  number  of  duplicates  is  large?     –  the  number  of  disk  pages  approaches  that  of  nested  loop  join.   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   10   sid   bid   day   19   100   8/8/99   22   101   10/10/96   22   99   10/12/95   58   103   11/12/96   sid   sname   ra=ng   age   22   DusBn   7   45.0   31   Lubber   8   55.5   58   Rusty   10   35.0   R1 S1
  11. Example   •  Nested  Loop  Join  cost  1K+   100K*500

      •  On  the  fly  selecBon  and  project   does  not  incur  any  disk  access.   •  Total  disk  access  =  500001K   (worst  case)   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   11   SELECT    S.sname   FROM    Reserves  R,  Sailors  S   WHERE    R.sid=S.sid  AND      R.bid=100  AND  S.raBng>5   σS.rating>5 AND R.bid=100 Reserves Sailors R.sid=S.sid π S.sname Nested Loop Join On the fly On the fly (SCAN) (SCAN) Reserves   40  bytes/tuple   100  tuples/page   1000  pages   Sailors   50  bytes/tuple   80  tuples/page   500  pages  
  12. Example:  Predicate  Pushdown   •  Nested  Loop  Join  requires  materializing

     the   inner  table  as  T1.   •  With  50%  selecBvity,  T1  has  250  pages   •  With  10%  selecBvity,  outer  “table”  in  join  has   10K  tuples   •  Disk  accesses  for  scans  =  1000  +  500   •  WriBng  T1  =  250   •  NLJoin  =  10K  *  250   •  Total  disk  access  =  2500.175  K  (worst  case)   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   12   SELECT    S.sname   FROM    Reserves  R,  Sailors  S   WHERE    R.sid=S.sid  AND      R.bid=100  AND  S.raBng>5   σS.rating>5 Reserves Sailors R.sid=S.sid π S.sname Nested Loop Join On the fly σR.bid=100 (SCAN) (SCAN) Reserves   40  bytes/tuple   100  tuples/page   1000  pages   Sailors   50  bytes/tuple   80  tuples/page   500  pages   Temp T1 10%   50%   What  happens  if  we  make   the  lex  leg  the  inner  table   of  the  join  ?  
  13. Example:  Sort  Merge  Join   •  Sort  Merge  Join  requires

     materializing    both  legs     for  sorBng.   •  With  10%  selecBvity,  T1  has  100  pages   •  With  50%  selecBvity,  T2  has    250  pages   •  Disk  accesses  for  scans  =  1000  +  500   •  WriBng  T1  &  T2  =  100  +  250   •  Sort  Merge  Join  =  100  log  100  +  250  log  250  +   100+250  (assume  10  way  merge  sort)   •  Total  disk  access  =  52.8  K   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   13   SELECT    S.sname   FROM    Reserves  R,  Sailors  S   WHERE    R.sid=S.sid  AND      R.bid=100  AND  S.raBng>5   σS.rating>5 Reserves Sailors R.sid=S.sid π S.sname Sort Merge Join On the fly σR.bid=100 (SCAN) (SCAN) Reserves   40  bytes/tuple   100  tuples/page   1000  pages   Sailors   50  bytes/tuple   80  tuples/page   500  pages   Temp T2 10%   50%   What  happens  if  we  make   the  lex  leg  the  inner  table   of  the  join  ?   Temp T1
  14. Example:  Index  Nested  Loop  Join   •  With  10%  selecBvity,

     selecBon   on  R  has    10K  tuples   •  Disk  accesses  for  scan  =  1000   •  Index  Nested  Loop  Join  =  10K*(  1   +  log10  500)    =  37K   •  Total  disk  access  =  38  K   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   14   SELECT    S.sname   FROM    Reserves  R,  Sailors  S   WHERE    R.sid=S.sid  AND      R.bid=100  AND  S.raBng>5   Reserves Sailors R.sid=S.sid π S.sname Index nested Loop Using Index on S.sid On the fly σR.bid=100 (SCAN) Reserves   40  bytes/tuple   100  tuples/page   1000  pages   Sailors   50  bytes/tuple   80  tuples/page   500  pages   10%   50%   What  happens  if  we  make   the  lex  leg  the  inner  table   of  the  join  ?   σS.rating>5 On the fly
  15. Join  Ordering   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at

     Manoa   15   A B C C A B Rela=ons   Tuples   Pages   A   10K   1000   B   20K   2000   C   30K   3000   A  join  B   10K   1000   B  join  C   1K   100   10K 20K 30K 500 10K 20K 30K 10K •  Independent  of  what  join  algorithm  is  chosen,   the  order  in  which  joins  are  perform  affects  the   performance.   •  Rule  of  thumb:  do  the  most  “selecBve”  join  first   •  In  pracBce,  lex  deep  trees  (eg.  the  right  one   above)  are  preferred  -­‐-­‐-­‐  why  ?  
  16. StaBsBcs  &  Cost  EsBmaBon   •  Page  size   • 

    Data  StaBsBcs:   –  Record  size  -­‐>  number  of  records  per  data  page   –  Cardinality  of  relaBons  (including  temporary  tables)   –  SelecBvity  of  selecBon  operator  on  different  columns   of  a  relaBon   •  (Tree)  Index  StaBsBcs   –  number  of  leaf  pages,  index  entries   –  Height   •  StaBsBcs  collecBon  is  user  triggered   –  DB2:  RUNSTATS  ON  TABLE  mytable  AND  INDEXES  ALL   –  Oracle:  analyze  table  command  or  dbms_stats   package   Lipyeow  Lim  -­‐-­‐  University  of  Hawaii  at  Manoa   16