1 / 14

Deco Query Processing

Deco Query Processing. Scoop — The Stanford – Santa Cruz Project for Cooperative Computing with Algorithms, Data, and People . Hector Garcia-Molina, Aditya Parameswaran, Hyunjung Park, Alkis Polyzotis, Jennifer Widom Stanford and UCSC. Valid Instance of Database. Given:

wyome
Download Presentation

Deco Query Processing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deco Query Processing Scoop — The Stanford – Santa Cruz Project for Cooperative Computing with Algorithms, Data, and People Hector Garcia-Molina, Aditya Parameswaran, Hyunjung Park, Alkis Polyzotis, Jennifer Widom Stanford and UCSC

  2. Valid Instance of Database • Given: • Current contents of Deco tables (actual schema) • Fetch Rules and Resolution Rules • Valid instance (conceptual schema) is any state of relations obtained by: 1. Fetch— add tuples to Deco tables by invoking FR procedures 2. Resolve— resolve dependent attributes using RR functions 3. Join — full outerjoin of Deco tables for each relation Schema designer End user relations and other stuff relations Conceptual schema automatic (system) Actual schema RDBMS

  3. Query Semantics • Deco query Q • Relational query (over the conceptual schema) • Result of a Deco query Q • Result of Q (using relational semantics) over some valid instance of the database • Which valid instance? • “Current” one (no fetch step): result may be empty • Factors restricting valid instances for Q: • Number of result tuples, Quality of results • Running time, Monetary cost

  4. Query Processing Objective • For now: • The user specifies the minimum number of tuples in the result of Q • Query processor minimizes a combination of running time and monetary cost • Alternative: • Given upper bounds of running time and monetary cost, maximize the number of result tuples and their quality

  5. Rest of This Presentation • Four example query plans demonstrating: • Query operators • Placing FRs in query plans

  6. Example Schema R (restaurant, address, [rating], [cuisine]) • Resolution Rules • restaurant,address rating • restaurant cuisine • Fetch Rules • restaurant,address  rating • restaurant  cuisine • restaurant,address  rating,cuisine • cuisine  restaurant,address •   restaurant,address

  7. Example #1: Query Operators SELECT rest, addr FROM R WHERE rating=4 MINTUPLES 5 MinTuples [5] • Retrieves tuples from its child operator • Feeds retrieved tuples to the RR function until the resolved value is good enough Filter [rating=4] • Retrieves tuples in the underlying Deco table • Then, fetches more tuples from external source • Stores externally obtained tuples in the Deco table Join Resolve [conf≥0.8] Fetch [rest,addr] Fetch [rest,addrrating] A1+MTurk A2+MTurk

  8. Example #1: Query Operators SELECT rest, addr FROM R WHERE rating=4 MINTUPLES 5 MinTuples [5] • Waits until placeholders are replaced by actual values Filter [rating=4] Sync [rating] • Initiate FR procedure • Returns “incomplete” tuple with placeholders Join Resolve [conf≥0.8] Sync [rest,addr] Fetch [rest,addr] Fetch [rest,addrrating] A1+MTurk A2+MTurk

  9. Example #2: FR Scheduling SELECT * FROM R WHERE rating=4 MINTUPLES 5 FRs operate in parallel Shorter running time More $$ MinTuples [5] Filter [rating=4] Sync [rating,cuisine] Join Join Fetch & Sync [rest,addr] Fetch & Resolve [rest,addrrating] Fetch & Resolve [restcuisine]

  10. Example #2: FR Scheduling MinTuples [5] SELECT * FROM R WHERE rating=4 MINTUPLES 5 FRs operate serially Longer running time Less $$ Sync [cuisine] Join Filter [rating=4] Sync [rating] Join Fetch & Sync [rest,addr] Fetch & Resolve [rest,addrrating] Fetch & Resolve [restcuisine]

  11. Example #3: FR Composition SELECT * FROM R MINTUPLES 5 One FR for each dependent attribute group More FR invocations MinTuples [5] Sync [rating,cuisine] Join Join Fetch & Sync [rest,addr] Fetch & Resolve [rest,addrrating] Fetch & Resolve [restcuisine]

  12. Example #3: FR Composition SELECT * FROM R MINTUPLES 5 Composite FR for both dependent attribute groups Fewer FR invocations MinTuples [5] Sync [rating, cuisine] Join Fetch & Sync [rest,addr] Fetch & Resolve [rest,addrrating,cuisine]

  13. Example #4: Reverse FR SELECT rest, addr FROM R WHERE cuisine=‘French’ MINTUPLES 5 What if there are few French restaurants? MinTuples [5] Filter [cuisine=‘French’] Sync [cuisine] Join Fetch & Sync [rest,addr] Fetch & Resolve [restcuisine]

  14. Example #4: Reverse FR SELECT rest, addr FROM R WHERE cuisine=‘French’ MINTUPLES 5 Shorter running time using Reverse FR MinTuples [5] Filter [cuisine=‘French’] Sync [cuisine] Join Fetch & Sync [cuisine:French rest,addr] Fetch & Resolve [restcuisine]

More Related