9. Query Processing

Click here to load reader

  • date post

    15-Jan-2016
  • Category

    Documents

  • view

    42
  • download

    0

Embed Size (px)

description

Section 9 # 1. 9. Query Processing. SQL Queries in a high level language such as SQL are processed by Horizontal DBMSs in the following steps: 1. SCAN and PARSE (SCANNER-PARSER): The Scanner identifies the tokens or language elements. The Parser check for syntax or grammar validity. - PowerPoint PPT Presentation

Transcript of 9. Query Processing

  • 9. Query ProcessingSQL Queries in a high level language such as SQL are processed by Horizontal DBMSs in the following steps:

    1. SCAN and PARSE (SCANNER-PARSER): The Scanner identifies the tokens or language elements. The Parser check for syntax or grammar validity.

    2. VALIDATED: The Validator checks for valid names and semantic correctness.

    3. CONVERTER converts to an internal representation (usually a QUERY TREE)|4. QUERY OPTIMIZED: Query Optimzier devises a stategy for executing query (chooses among alternative Query trees).

    5. CODE GENERATION: generates code to implement each operator in the selected query plan (the optimizer-selected the query tree).

    6. RUNTIME DATABASE PROCESSORING: run plan code

  • The CONVERTER converts to an internal representation (usually a QUERY TREE). E.g., given the database: _S______________ _C___________ _E______ |S#|SNAME |LCODE | |C#|CNAME|SITE||S#|C#|GR| |25|CLAY |NJ5101| |8 |DSDE |ND | |32|8 |89| |32|THAISZ|NJ5102| |7 |CUS |ND | |32|7 |91| |38|GOOD |FL6321| |6 |3UA |NJ | |25|7 |68| |17|BAID |NY2091| |5 |3UA |ND .| |25|6 |76| |57|BROWN |NY2092| |32|6 |62|The SQL request:

    SELECT S.SNAME, C.CNAME, E.GRFROM S,C,E WHERE E.GR=68 and C.SITE="ND" and S.LCODE=NJ5101 and C.C#=E.C# and S.S#=E.S#;

    gets SCANNED, PARSED, VALIDATED, then may get CONVERTED to query tree following the sequencing of the WHERE-clause.

  • CONVERTER _S______________ _C___________ _E______ |S#|SNAME |LCODE | |C#|CNAME|SITE||S#|C#|GR| |25|CLAY |NJ5101| |8 |DSDE |ND | |32|8 |89| |32|THAISZ|NJ5102| |7 |CUS |ND | |32|7 |91| |38|GOOD |FL6321| |6 |3UA |NJ | |25|7 |68| |17|BAID |NY2091| |5 |3UA |ND .| |25|6 |76| |57|BROWN |NY2092| |32|6 |62|M=PROJ(L)[SNAME,CNAME,GR] | L=SELECT(K.GR=68) | K=SELECT(H.SITE="ND") | H=SELECT(G.LCODE="NJ5101") | G=JOIN(F.C#=C.C#) /\ / \ JOIN(S.S#=E.S#)=F C /\ / \ S E This is simplest CONVERTER (uses the ordering in WHERE clause) SELECT S.SNAME, C.CNAME, E.GRFROM S,C,E WHERE E.GR=68 and C.SITE="ND" and S.LCODE=NJ5101 and C.C#=E.C# and S.S#=E.S#;

  • CONVERTERS#|SNAME |LCODE 25|CLAY |NJ510132|THAISZ|NJ510238|GOOD |FL632117|BAID |NY209157|BROWN |NY2092M=PROJ(L)[SNAME,CNAME,GR] || L=SELECT(K.GR=68) || K=SELECT(H.SITE="ND") ||H=SELECT(G.LCODE="NJ5101") | | G=JOIN(F.C#=C.C#) /\ / \ JOIN(S.S#=E.S#)=F /\ / \ S ELet's see the resultsat each step.C#|CNAME|SITE8 |DSDE | ND 7 |CUS | ND 6 |3UA | NJ 5 |3UA | ND S#|C#|GR 32|8 |89 32|7 |91 25|7 |68 25|6 |76 32|6 |62S#|SNAME |LCODE |C#|GR25|CLAY |NJ5101|7 |6825|CLAY |NJ5101|6 |7632|THAISZ|NJ5102|8 |8932|THAISZ|NJ5102|7 |9132|THAISZ|NJ5102|6 |62 CS#|SNAME |LCODE |C#|GR|CNAME|SITE25|CLAY |NJ5101|7 |68|CUS |ND25|CLAY |NJ5101|6 |76|3AU |NJ32|THAISZ|NJ5102|8 |89|DSDE |ND32|THAISZ|NJ5102|7 |91|CUS |ND32|THAISZ|NJ5102|6 |62|3UA |NJS#|SNAME |LCODE |C#|GR|CNAME|SITE25|CLAY |NJ5101|7 |68|CUS |ND25|CLAY |NJ5101|6 |76|3AU |NJS#|SNAME |LCODE |C#|GR|CNAME|SITE25|CLAY |NJ5101|7 |68|CUS |NDS#|SNAME |LCODE |C#|GR|CNAME|SITE25|CLAY |NJ5101|7 |68|CUS |NDSNAME |CNAME|GRCLAY |CUS |68

  • The OPTIMIZER devises a stategy for executing the query (chooses among alternative Query trees). Is the query tree optimal? Is this tree better? M=PROJ(L)[SNAME,CNAME,GR] || G=JOIN(F.C#=K.C#) /\ / \ / \ JOIN(H.S#=L.S#)=F \ /\ \ / \ \ / \ \ SEL(S.LCODE=NJ5101)=H L=SEL(E.GR=68) K=SEL(C.SITE=ND)

    S#|SNAME |LCODE 25|CLAY |NJ510132|THAISZ|NJ510238|GOOD |FL632117|BAID |NY209157|BROWN |NY2092C#|CNAME|SITE8 |DSDE | ND 7 |CUS | ND 6 |3UA | NJ 5 |3UA | ND S#|C#|GR 32|8 |89 32|7 |91 25|7 |68 25|6 |76 32|6 |62CESC#|CNAME|SITE8 |DSDE | ND 7 |CUS | ND 5 |3UA | ND S#|C#|GR 25|7 |68 S#|SNAME |LCODE 25|CLAY |NJ5101S#|SNAME |LCODE |C#|GR 25|CLAY |NJ5101|7 |68S#|SNAME |LCODE |C#|GR|CNAME|SITE 25|CLAY |NJ5101|7 |68|CUS |NDSNAME |CNAME|GRCLAY |CUS |68YES! This tree is better since the intermediate files created are much smaller!!

  • Note that the following could be done: SITE attribute can be projected from K (doesn't require elimination of duplicates because it is not part of the key).The LCODE attrib can be projected off of H (doesn't require elimination of duplicates because it is not part of the key).S# could be projected off of F (it is part of the key but duplicate elimination could be deferred until M since it will have to be done again there anyway - thus this projection can be a "non duplicate-eliminating" projection also (which we will denote by [[ ]]). [[ ]]-projections take no time, whereas duplicate eliminating projections take a lot of time).C# can be (non-duplicate-eliminating) projected off G (just reordering attrs and eliminating duplicates, if any). M=PROJ(L)[SNAME,CNAME,GR] || G=JOIN(F.C#=K.C#) /\ / \ / \ JOIN(H.S#=L.S#)=F \ /\ \ / \ \ / \ \ H=SEL(S.LCODE=NJ5101)[[S#,SNAME]] L=SEL(E.GR=68) K=SEL(C.SITE=ND)[[C#,CNAME]]

    S#|SNAME |LCODE 25|CLAY |NJ510132|THAISZ|NJ510238|GOOD |FL632117|BAID |NY209157|BROWN |NY2092C#|CNAME|SITE8 |DSDE | ND 7 |CUS | ND 6 |3UA | NJ 5 |3UA | ND S#|C#|GR 32|8 |89 32|7 |91 25|7 |68 25|6 |76 32|6 |62CESC#|CNAME8 |DSDE 7 |CUS 5 |3UA S#|C#|GR 25|7 |68 S#|SNAME25|CLAYS#|SNAME |C#|GR 25|CLAY |7 |68SNAME |GR|CNAMECLAY |68|CUSSNAME |CNAME|GRCLAY |CUS |68Even better! The intermediate files created are even smaller!!

  • What have we learned about QP?GOOD RULES?a. Do SELECTS first (push to the bottom of the tree).b. Do attribute elimination part of PROJECT as soon as possible (push down).c. Only do duplicate elimination once (at top-most PROJECT only or in conjunction with a latter join step).

    QUERY OPTIMIZATION, then, is finding an efficient strategy to implement query requests (Automatically, Heuristically, not necessarily optimally) Note: In lower level languages, the user does the query optimization by writing the procedural code to specify all steps and order those steps. (of course there are optimizing compilers that will automatically alter your "procedures", but still you are mostly responsible for ordering).Relational queries are issued at a high level (SQL or ODBC), so that system has maximal oportunity to optimize them. HEURISTIC RULES are used to re-order query tree. (e.g., RULES a. b. c. above) . Some rules depend upon size and complexity estimates. ESTIMATION estimates the cost of different strategies and chooses the best. Challenge: Get acceptable performance (took 10 years to optimize join process acceptably so that the first viable Relational DBMSs could be successfully sold!).

  • Some SELECT implementations: (Each of S2 - S6 requires a special access path.)

    S1. Linear search: sequentially search every record. S2. Binary search: (for selections on a clustered or ordered attribute) S3. Using indexes (or hash structures) for an equality comparison S4. Using primary index for an inequality comparison on a key (clustered). S5. Using a clustering index for "=" comparison S6. Using a secondary B+-tree index for "=", use the index set.

    SELECTION methods with a WHERE conjunction (AND): S7. Of the many conjunctive attributes, select 1 attribute (usually involving an "=") S8. Intersection of Rrecord Pointers: Intersect RRN-sets then retrieve recordsS9. If there are Bitmapped Indexes, AND bitmapsCASE-1: SELECT is on an attribute with few distinct values.CASE-2: SELECT is on an attribute with uniqueness (key) or near uniqueness.S10. If there is a composite index on the attributes involved in condition, use it. S11. If there is a composite hash function, use it.

    SELECTION methods when there is a WHERE disjuntion (OR):S12. If there is no access path (indexes or hash functions), use S1 (brute force). S13. If there are access paths, use them and UNION the results.S14. If there are BitMaps, take the OR of the bitmaps. CODE GENERATION implements the operators above (e.g., SELECT, PROJECT, JOIN...)

  • S1. Linear search: sequentially search every record. Required for selections from an unordered relation with no index or access path. SELECT C#, GRFROM ENROLL WHERE S# = 32;S2. Binary search: For selections on a clustered (ordered) attribute (in this case, S#):SELECT C#, GR FROM ENROLL WHERE S# = 38;Go half way (to RRN=3), since S# < 38, go half way down what's left (to RRN= 5). Since S# < 38, go half way down what's left (to RRN= 6). Match! Output. Scan aheadand output until no match or EoF.

  • S3. Using Indexes: (or hash structures) for an equality comparison.SELECT C#, NAMEFROM STUDENT WHERE S# = 32S4. Using primary index for an inequality comparison on a key (clustered). (Find starting point with "=", then retrieve all records beyond that point).

    SELECT S#,NAME FROM STUDENT WHERE S# 32 RID| S# nondense Primary Index on S#3,0| 571,0| 172,0| 32Find startingpoint (firstS# 32) thenscan aheadtaking alluntil End

  • S5. Using a Clustered Index: for = comparison.SELECT C#, GRFROM ENROLL WHERE S# = 32

  • S7. Of the many conjunctive attributes, select on 1 attribute (usually 1 involving an "=") then check the other condition(s) for each retrieved record.SELECT NAME, CITYFROM STUDENT WHERE S#>25 and ST=NE

  • S7. Of the many conjunctive attributes, select on 1 attribute (neither involve =! taking S#) then check the other condition(s) for each retrieved record.SELECT NAME, CITYFROM STUDENT WHERE S#>38 and STNEtruetruetrue

  • S8. INTERSECTION OF RECORD POINTERS: Intersect RRN-sets then retrieve records. SELECT NAME,CITY FROM STUDENT WHERE S#>25 and (ST=NE or ST=NY);(This can be done in conjunction with any of the above methods. If the RRN-sets are stored ahead of time for