Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

  • Be the first to comment

  • Be the first to like this


  1. 1. Memory Constrained DBMS with Updates Ashwini G. Rao Guide Prof. Krithi Ramamritham
  2. 2. Outline of the talk <ul><li>Need for Handheld DBMS </li></ul><ul><li>New Issues in Implementation </li></ul><ul><li>Project Goals </li></ul><ul><li>Review of Existing Work </li></ul><ul><li>Compression in Storage </li></ul><ul><li>Transaction Management </li></ul><ul><li>Synchronization </li></ul><ul><li>Current Implementation Status </li></ul><ul><li>Conclusions and Future work </li></ul>
  3. 3. Handhelds <ul><li>Small, Convenient, Carry anywhere </li></ul><ul><li>Powerful </li></ul><ul><ul><li>E.g. Simputer- 206MHz, 32MB SDRAM, 24 MB Flash memory, LCD display, Smart card </li></ul></ul><ul><li>Applications </li></ul><ul><ul><li>Personal Info Management </li></ul></ul><ul><ul><ul><li>E-dairy </li></ul></ul></ul><ul><ul><li>Enterprise Applications </li></ul></ul><ul><ul><ul><li>Health-care, Micro-banking </li></ul></ul></ul>
  4. 4. Need for Handheld DBMS <ul><li>Handheld applications </li></ul><ul><ul><li>Volume of data is high </li></ul></ul><ul><ul><li>Simple and Complex Queries </li></ul></ul><ul><ul><ul><li>select, project, aggregate </li></ul></ul></ul><ul><ul><li>ACID properties of transactions </li></ul></ul><ul><ul><li>Require Data Privacy </li></ul></ul><ul><ul><li>Need Synchronization </li></ul></ul><ul><li>Database management techniques are needed to meet the above requirements </li></ul>
  5. 5. New Issues in Implementation <ul><li>Handheld DBMS vs. Disk DBMS </li></ul><ul><ul><li>Handheld DB is Flash memory based </li></ul></ul><ul><ul><ul><li>Disk read time is very small </li></ul></ul></ul><ul><ul><li>Storage model should consider small memory and computation power </li></ul></ul><ul><ul><li>Transaction management and synchronization have to consider disconnections, mobility and communication cost </li></ul></ul><ul><ul><li>Handheld Operating System provides lesser facilities </li></ul></ul><ul><ul><ul><li>E.g. no multi-threading support in PalmOS </li></ul></ul></ul><ul><ul><li>Better security measures are required as handhelds are easily stolen, damaged and lost </li></ul></ul>
  6. 6. Project Goals <ul><li>Existing work </li></ul><ul><ul><li>Storage models </li></ul></ul><ul><ul><li>Query processing & optimization </li></ul></ul><ul><ul><li>Executor </li></ul></ul><ul><li>My work </li></ul><ul><ul><li>Compression in Storage </li></ul></ul><ul><ul><li>Transaction management </li></ul></ul><ul><ul><li>Synchronization </li></ul></ul>
  7. 7. Existing Work – Review <ul><li>Storage Management </li></ul><ul><ul><li>Aim at compactness in representation of data </li></ul></ul><ul><ul><li>Limited storage could preclude any additional index </li></ul></ul><ul><ul><ul><li>Data model should try to incorporate some index information </li></ul></ul></ul><ul><li>Query Processing </li></ul><ul><ul><li>Minimize writes to secondary storage </li></ul></ul><ul><ul><li>Efficient usage of limited main memory </li></ul></ul>
  8. 8. Storage Management <ul><li>Existing storage models </li></ul><ul><ul><li>Flat Storage </li></ul></ul><ul><ul><ul><li>Tuples are stored sequentially. Duplicates not eliminated </li></ul></ul></ul><ul><ul><li>Pointer-based Domain Storage </li></ul></ul><ul><ul><ul><li>Values partitioned into domains which are sets of unique values </li></ul></ul></ul><ul><ul><ul><li>Tuples reference the attribute value by means of pointers </li></ul></ul></ul><ul><ul><ul><li>One domain shared among multiple attributes </li></ul></ul></ul>
  9. 9. Storage Management (cont) Flat Storage Domain Storage <ul><li>In Domain Storage, pointer of size p (typically 4 bytes) points to the domain value. Can we further reduce the storage cost? </li></ul>10 20 30 40 p q s r IIT12 Flat Relation CSE11 CSE11 CSE11 CSE11 10 20 30 40 p q r s Domain Relation 4 bytes IIT12
  10. 10. ID Based Storage Relation R ID Values 0 1 2 1 n 0 n v0 v1 vn Domain Values Positional Indexing
  11. 11. ID Based Storage <ul><li>ID Storage </li></ul><ul><ul><li>An identifier for each of the domain values </li></ul></ul><ul><ul><li>Store the smaller identifier instead of the pointer </li></ul></ul><ul><ul><li>Identifier is the positional value in the domain table. Use it as an offset into the domain table </li></ul></ul><ul><ul><li>D domain values can be distinguished by identifiers of length log 2 D /8 bytes. </li></ul></ul>
  12. 12. ID Storage (cont) <ul><ul><li>Extendable IDs are used. Length of the identifier grows and shrinks depending on the number of domain values </li></ul></ul><ul><ul><li>Starting with 1 byte identifiers, the length grows and shrinks. </li></ul></ul><ul><ul><li>To reduce reorganization of data, ID values are projected out from the rest of the relation and stored separately maintaining Positional Indexing. </li></ul></ul>
  13. 13. ID Storage (cont) <ul><li>Ping Pong Effect </li></ul><ul><ul><li>At the boundaries, there is reorganization of ID values </li></ul></ul><ul><ul><li>when the identifier length changes </li></ul></ul><ul><ul><li>Frequent insertions and deletions at the boundaries might </li></ul></ul><ul><ul><li>result in a lot of reorganization </li></ul></ul><ul><ul><li>Phenomena should be avoided </li></ul></ul><ul><li>No deletion of Domain values </li></ul><ul><ul><li>Domain structure means a future insertion might reference </li></ul></ul><ul><ul><li>the deleted value </li></ul></ul><ul><ul><li>Do not delete a domain value even it is not referenced </li></ul></ul><ul><li>Setting a threshold for deletion for domain values </li></ul><ul><ul><li>Delete only if number of deletions exceeds a threshold </li></ul></ul><ul><ul><li>Increase the threshold when boundaries are being crossed to reduce ping pong effect </li></ul></ul>
  14. 14. ID Storage (cont) <ul><li>Primary Key-Foreign Key relationship </li></ul><ul><ul><li>Primary key is a domain in itself </li></ul></ul><ul><ul><li>IDs for primary key values </li></ul></ul><ul><ul><li>Values present in child table are the corresponding primary key IDs </li></ul></ul><ul><ul><li>Projected foreign key column forms a Join Index </li></ul></ul>Figure: Primary Key-Foreign Key Join Index 0 1 2 1 n 0 n v0 v1 vn Parent Table Relation R Child Table
  15. 15. ID Storage (cont) <ul><li>ID based Storage wins over Domain Storage when pointer size > log 2 D /8 </li></ul><ul><li>Relations in a small device do not have a very high cardinality Above condition true for most of the data. </li></ul><ul><li>Advantages of ID storage </li></ul><ul><ul><li>Considerable saving in storage cost. </li></ul></ul><ul><ul><li>Efficient join between parent table and child table </li></ul></ul>
  16. 16. Query Processing <ul><li>Considerations </li></ul><ul><ul><li>Minimize writes to secondary storage </li></ul></ul><ul><ul><li>Use Main memory as write buffer </li></ul></ul><ul><li>Need for Left-deep Query Plan </li></ul><ul><ul><li>Reduce materialization in flash memory. If absolutely necessary use main memory </li></ul></ul><ul><ul><li>Bushy trees use materialization </li></ul></ul><ul><ul><li>Left deep tree is most suited for pipelined evaluation </li></ul></ul><ul><ul><li>Right operand in a left-deep tree is always a stored relation </li></ul></ul>
  17. 17. Query Processing (cont) <ul><li>Need for optimal memory allocation </li></ul><ul><ul><li>Using nested loop algorithms for every operator ensures that minimum amount of memory used to execute the plan </li></ul></ul><ul><ul><li>Nested loop algorithms are inefficient </li></ul></ul><ul><ul><li>Different devices come with different memory sizes </li></ul></ul><ul><ul><li>Query plans should make efficient use of memory. Memory must be optimally allocated among all operators </li></ul></ul><ul><li>Need to generate the best query execution plan depending on the available memory </li></ul>
  18. 18. Query Processing (cont) <ul><li>Operator evaluation schemes </li></ul><ul><ul><li>Different schemes for an operator </li></ul></ul><ul><ul><li>Schemes conform to left-deep tree query plan </li></ul></ul><ul><ul><li>All have different memory usage and cost </li></ul></ul><ul><ul><li>Cost of a scheme is the computation time </li></ul></ul>
  19. 19. Query Processing (cont) <ul><li>2-Phase optimizer </li></ul><ul><ul><li>Phase 1: Query is first optimized to get a query plan </li></ul></ul><ul><ul><li>Phase 2: Division of memory among the operators </li></ul></ul><ul><ul><li>Scheme for every operator is determined in phase 1 and remains unchanged after phase 2, memory allocation in phase 2 is on the basis of the cost functions of the schemes </li></ul></ul><ul><ul><li>Memory is assumed to be available for all the schemes, this may not be true for a resource constrained device </li></ul></ul><ul><li>Traditional 2-phase optimization cannot be used </li></ul>
  20. 20. Query Processing (cont) <ul><li>1-Phase optimizer </li></ul><ul><ul><li>Query optimizer is made memory cognizant </li></ul></ul><ul><ul><li>Modified optimizer takes into account division of memory among operators while choosing between plans </li></ul></ul><ul><ul><li>Ideally, 1-phase optimization should be done but the optimizer becomes complex. </li></ul></ul>
  21. 21. Query Processing (cont) <ul><li>Modified 2-phase optimizer </li></ul><ul><ul><li>Optimal division of memory involves the decision of selecting the best scheme for every operator </li></ul></ul><ul><ul><li>Phase 1: </li></ul></ul><ul><ul><ul><li>Determine the optimal left-deep join order using dynamic programming approach </li></ul></ul></ul><ul><ul><li>Phase 2: </li></ul></ul><ul><ul><ul><li>Divide memory among the operators </li></ul></ul></ul><ul><ul><ul><li>Choose the scheme for every operator depending on the memory allocated </li></ul></ul></ul>
  22. 22. Query Processing (cont) <ul><li>Memory allocation algorithms </li></ul><ul><ul><li>Exact memory allocation </li></ul></ul><ul><ul><li>Heuristic memory allocation </li></ul></ul><ul><li>Conclusions </li></ul><ul><ul><li>Response times highest with minimum memory and least with maximum memory </li></ul></ul><ul><ul><li>Computing power of the handheld affects the response time in a big way </li></ul></ul><ul><ul><li>Heuristic memory allocation differed from exact algorithm in a few points only </li></ul></ul>
  23. 23. Compression in DB <ul><li>Advantages </li></ul><ul><ul><li>Saves space </li></ul></ul><ul><ul><li>Reduces read time and write time as less data is processed </li></ul></ul><ul><ul><li>Logging consumes less space and time </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>CPU intensive </li></ul></ul><ul><ul><li>Competes with other CPU intensive DBMS tasks. </li></ul></ul><ul><ul><li>May slow down the DBMS </li></ul></ul>
  24. 24. Compression in Disk DB <ul><li>Main assumption </li></ul><ul><ul><li>The high disk read time compensates for the extra time required for compression and decompression </li></ul></ul><ul><ul><li>E.g. Let time taken to read 10 blocks of data from the disk be 10ms. Let the time taken for compression and decompression be 5ms. After compression 10 blocks occupy only 1 block. </li></ul></ul><ul><ul><li>Processing time with compression/decompression </li></ul></ul><ul><ul><ul><li> = ( 1ms + 5ms) = 6ms </li></ul></ul></ul><ul><li>Handheld DB is Flash memory based </li></ul><ul><ul><li>Read time is very less. Above assumption is no longer valid!! </li></ul></ul>
  25. 25. Compression in Handhelds <ul><li>Techniques can exploit high write time of flash memory </li></ul><ul><li>Logging </li></ul><ul><ul><li>Compressed records consume lesser log space </li></ul></ul><ul><ul><li>Writing time is reduced </li></ul></ul><ul><ul><li>Decompression done when recovery is initiated </li></ul></ul><ul><ul><ul><li>Highly beneficial if failures are rare </li></ul></ul></ul><ul><li>Saves communication cost when log records have to be sent over the network </li></ul><ul><ul><li>E.g., Transaction management </li></ul></ul>
  26. 26. Compression in Handhelds (cont) <ul><li>Data compression in Smart cards </li></ul><ul><ul><li>Consider Handheld with Smart card support </li></ul></ul><ul><ul><li>Data stored in smart cards is accessed and updated </li></ul></ul><ul><ul><ul><li>E.g., Personal database </li></ul></ul></ul><ul><ul><li>Memory in smart cards is limited </li></ul></ul><ul><ul><li>Compression will save space </li></ul></ul><ul><ul><li>Data can be decompressed and processed in the handheld </li></ul></ul>
  27. 27. Transaction Management <ul><li>Ensure ACID properties of local and global transactions </li></ul><ul><ul><li>Local transaction - Update address book entry in Simputer </li></ul></ul><ul><ul><li>Global transaction - Transfer money from a bank account to an epurse in a smart card attached to a Simputer </li></ul></ul><ul><li>Issues </li></ul><ul><ul><li>Frequent disconnections, resource constraints, mobility, loss or damage to handheld </li></ul></ul>
  28. 28. <ul><li>We will Look into </li></ul><ul><ul><li>Concurrency control </li></ul></ul><ul><ul><li>Atomicity </li></ul></ul><ul><ul><ul><li>Local </li></ul></ul></ul><ul><ul><ul><li>Global </li></ul></ul></ul><ul><ul><li>Consistency </li></ul></ul><ul><ul><li>Durability </li></ul></ul>Transaction Management (cont)
  29. 29. Concurrency control <ul><li>Concurrency in handhelds depends on </li></ul><ul><ul><li>Multi-tasking support from the handheld OS </li></ul></ul><ul><ul><ul><li>E.g., Linux in Simputer, PalmOS </li></ul></ul></ul><ul><ul><li>User requirements </li></ul></ul><ul><ul><ul><li>Several tasks may have to execute concurrently </li></ul></ul></ul><ul><ul><ul><li>E.g., A periodic synchronization task, address book access and an aggregation operation may run concurrently. </li></ul></ul></ul><ul><li>Strict 2PL, table level locks can be used </li></ul><ul><ul><li>Small number of concurrent processes </li></ul></ul><ul><ul><li>Very few data conflicts </li></ul></ul><ul><ul><li>Table level locking has small overhead and allows non conflicting processes to continue execution </li></ul></ul>
  30. 30. Atomicity <ul><li>Ensure the All or nothing property </li></ul><ul><li>Local atomicity </li></ul><ul><ul><li>E.g., enter name, email, phone number in the address book of Simputer </li></ul></ul><ul><ul><li>Shadow based update vs. In place update </li></ul></ul><ul><li>Global atomicity </li></ul><ul><ul><li>E.g., In an epurse application the updates are made at the bank's server, the Simputer and the smart card </li></ul></ul><ul><ul><li>2PC, optimizations to 2PC, 1PC </li></ul></ul>
  31. 31. Local atomicity <ul><li>Shadow based update </li></ul><ul><ul><li>Advantages </li></ul></ul><ul><ul><ul><li>No disk locality problem in handheld DB </li></ul></ul></ul><ul><ul><ul><li>Simplifies recovery </li></ul></ul></ul><ul><ul><li>Disadvantages </li></ul></ul><ul><ul><ul><li>Poorly adopted to Pointer based storage models </li></ul></ul></ul><ul><ul><ul><li>Cost increases with increase in size of flash memory </li></ul></ul></ul><ul><li>In place update </li></ul><ul><ul><li>Uses WAL </li></ul></ul><ul><ul><li>Accommodates Pointer based storage models </li></ul></ul><ul><ul><li>Cost does not increase with size of flash memory </li></ul></ul><ul><ul><li>Buffer replacement policy is Steal </li></ul></ul><ul><ul><ul><li>Dirty blocks can be written to Smart card storage to avoid Undo </li></ul></ul></ul>
  32. 32. <ul><li>Two Phase Commit (2PC) </li></ul><ul><ul><li>Most commonly used atomic commit protocol </li></ul></ul><ul><ul><li>Shortcomings in handheld scenario </li></ul></ul><ul><ul><ul><li>Two rounds (decision and voting) of messages imposes high communication overhead </li></ul></ul></ul><ul><ul><ul><li>Requires the handheld to be connected during the voting and decision phase </li></ul></ul></ul><ul><ul><ul><li>Large number of forced writes </li></ul></ul></ul><ul><li>Optimizations to 2PC </li></ul><ul><ul><li>Presumed commit </li></ul></ul><ul><ul><li>Presumed abort </li></ul></ul>Global atomicity
  33. 33. <ul><li>One Phase Commit (1PC) </li></ul><ul><ul><li>Advantages </li></ul></ul><ul><ul><ul><li>Only one round of messages- no voting phase </li></ul></ul></ul><ul><ul><ul><li>Handheld can disconnect as soon as log records are transferred to fixed server </li></ul></ul></ul><ul><ul><ul><li>Lesser number of forced writes </li></ul></ul></ul><ul><ul><ul><li>Transactions involving Smart card and Handheld can use 1PC </li></ul></ul></ul><ul><ul><li>Disadvantages </li></ul></ul><ul><ul><ul><li>Requires participants to enforce 2PL. Will work with weak levels of consistency under certain conditions. In heterogeneous environment it is difficult to control the local DBMS concurrency control policies. </li></ul></ul></ul>Global atomicity (cont)
  34. 34. Consistency and Durability <ul><li>Consistency </li></ul><ul><ul><li>Local consistency can be ensured by defining integrity constraints </li></ul></ul><ul><li>Durability </li></ul><ul><ul><li>Either the changes of the transaction or enough information about the changes are written to stable storage before the transaction commits </li></ul></ul><ul><ul><li>Network durability- transfer log records to a server on the fixed network. </li></ul></ul><ul><ul><li>1PC ensures network durability </li></ul></ul><ul><ul><li>Pointer based logging </li></ul></ul><ul><ul><li>Extended ephemeral logging </li></ul></ul>
  35. 35. Synchronization <ul><li>Access data Anytime and Anywhere using the handheld </li></ul><ul><ul><li>Mobile sales person, Wireless ware house </li></ul></ul><ul><li>Problem – Not possible to remain connected always </li></ul><ul><li>Solution- Replicate data in the handheld </li></ul><ul><ul><li>Download a copy of the data into the handheld from the remote server and process it offline. Periodically merge the changes with the server </li></ul></ul>
  36. 36. Synchronization -Issues <ul><li>Data replication can lead to conflicts </li></ul><ul><ul><li>Update-update, Update-delete, Unique key violation, Integrity constraint violation </li></ul></ul><ul><li>Maintain global consistency between replicated copies </li></ul><ul><ul><li>Strict consistency with Data partitioning </li></ul></ul><ul><ul><li>Strict consistency with Reservation protocols or Leases </li></ul></ul><ul><ul><ul><li>Efficient when data is rarely shared </li></ul></ul></ul><ul><ul><li>Weak consistency with Eventual consistency </li></ul></ul><ul><ul><ul><li>leases restrictive when data is shared between many copies </li></ul></ul></ul><ul><ul><ul><li>Independently access and update data </li></ul></ul></ul><ul><ul><ul><li>only tentative commits possible </li></ul></ul></ul><ul><ul><ul><li>Actual commit when transaction is executed at the server </li></ul></ul></ul>
  37. 37. Synchronization – Issues (cont) <ul><li>Application specific conflict detection and resolution </li></ul><ul><ul><li>Maximum flexibility </li></ul></ul><ul><li>Device, network and backend agnostic </li></ul><ul><ul><li>XML, Unicode </li></ul></ul><ul><li>Incremental maintenance </li></ul><ul><ul><li>Save communication cost </li></ul></ul><ul><li>Download parts of relations, i.e., views </li></ul>
  38. 38. Synchronization –Existing Models <ul><li>Publish Subscribe Model </li></ul><ul><ul><li>Three tier </li></ul></ul><ul><ul><li>Enterprise applications </li></ul></ul><ul><ul><li>Independent updates </li></ul></ul><ul><ul><li>Eventual consistency </li></ul></ul><ul><ul><li>Conflict detection, resolution and merge </li></ul></ul><ul><li>PC to Handheld Model </li></ul><ul><ul><li>Two tier </li></ul></ul><ul><ul><li>Personal information </li></ul></ul>
  39. 39. Publish Subscribe Model <ul><li>Eventual consistency model </li></ul><ul><ul><li>Merge replication in Win SQL CE, Oracle Lite </li></ul></ul><ul><li>Publish Subscribe Process </li></ul><ul><ul><li>Publication and article </li></ul></ul><ul><ul><li>Publishing </li></ul></ul><ul><ul><li>Subscribing </li></ul></ul><ul><ul><li>Subscription </li></ul></ul><ul><ul><li>Synchronization </li></ul></ul><ul><ul><li>Merging </li></ul></ul>
  40. 40. Publish Subscribe Architecture <ul><li>Application </li></ul><ul><li>SQL DB Engine </li></ul><ul><li>SQL Database </li></ul><ul><li>Client Agent </li></ul><ul><li>Server Agent </li></ul><ul><li>Merge Agent </li></ul><ul><ul><li>Conflict Detection </li></ul></ul><ul><ul><li>Conflict Resolution </li></ul></ul><ul><li>Replication Provider </li></ul><ul><li>SQL Server Database </li></ul><ul><li>Communication Link </li></ul>
  41. 41. Conflict Detection and Resolution <ul><li>Conflict detection </li></ul><ul><ul><li>Row level tracking </li></ul></ul><ul><ul><li>Associate RowID and Version with each row </li></ul></ul><ul><ul><li>RowID is used to uniquely identify each row </li></ul></ul><ul><ul><li>Version is used to check whether the a given row has changed in the server </li></ul></ul><ul><li>Conflict resolution </li></ul><ul><ul><li>A conflict resolution procedure is invoked when a conflict is detected. The resolution procedure is created when the article is published </li></ul></ul><ul><ul><li>output can be server wins or handheld wins. Here the server always wins </li></ul></ul>
  42. 42. Row level tracking STEP 1 STEP 2 Row ID VER TID 0 1 0 IIT 0 CSE SERVER Row ID VER TID 0 1 0 IIT 0 CSE HANDHELD 1 Row ID VER TID 0 1 0 IIT 0 CSE SERVER Row ID VER TID 0 1 0 IIT 0 EE Handheld1 changes CSE to EE Row ID VER TID 0 1 0 IIT 0 CSE HANDHELD 2 Row ID VER TID 0 1 0 IIT 0 ME Handheld2 changes CSE to ME
  43. 43. Row level tracking (cont) STEP 3 STEP 4 Row ID VER TID 0 1 0 IIT 1 EE SERVER merges with Handheld 1 Row ID VER TID 0 1 0 IIT 1 EE HANDHELD 1 Row ID VER TID 0 1 0 IIT 1 EE SERVER merges with Handheld 2 Row ID VER TID 0 1 0 IIT 1 EE Handheld1 Row ID VER TID 0 1 0 IIT 1 EE Handheld 2 Row ID VER TID 0 1 0 IIT 0 ME HANDHELD 2
  44. 44. Current Implementation Status <ul><li>Two Synchronization tools have been implemented for the Simputer </li></ul><ul><ul><li>First Sync tool assumes that no updates are done in the handheld database </li></ul></ul><ul><ul><li>Second sync tool is based on Merge replication in Windows SQL CE. It allows independent updates in the handhelds. </li></ul></ul>
  45. 45. Conclusions <ul><li>Handheld DBMS techniques have to consider the resource constraints, mobility, frequent disconnections, and security aspects of the handheld </li></ul><ul><li>The techniques used for one component will influence the choice of the technique used in another component. There is a very strong interdependence between the components of the handheld DBMS </li></ul><ul><li>Techniques rejected for the disk environment may be explored in the handheld environment </li></ul>
  46. 46. Future work <ul><li>Enhance the Sync tool </li></ul><ul><li>Transaction management component </li></ul><ul><li>Recovery management component </li></ul><ul><li>Concurrency control component </li></ul><ul><li>Performance analysis of existing compression techniques in handheld environment </li></ul>
  47. 47. References
  48. 48. References (cont)
  49. 49. References (cont)
  50. 50. References (cont)
  51. 51. <ul><li>Thank You </li></ul>
  52. 52. Query Processing (cont) <ul><li>Benefit/Size of a scheme </li></ul><ul><ul><li>Every scheme is characterized by a benefit/size ratio which represents its benefit per unit memory allocation </li></ul></ul><ul><ul><li>Minimum scheme for an operator is the scheme that has max. cost and min. memory </li></ul></ul><ul><ul><li>Assume n schemes s 1 , s 2 ,…s n to implement an operator o </li></ul></ul><ul><ul><li>min(o)=s min </li></ul></ul><ul><ul><li>i, 1≤i≤n : Cost(s i ) ≤ Cost(s min ) , </li></ul></ul><ul><ul><li>Memory(s i ) ≥ Memory(s min ) </li></ul></ul><ul><ul><li>s min is the minimum scheme for operator o </li></ul></ul><ul><ul><li>Benefit(s i )=Cost(s min ) – Cost(s i ) </li></ul></ul><ul><ul><li>Size(s i ) =Memory(s i ) – Memory(s min </li></ul></ul>
  53. 53. Query Processing (cont) <ul><li>Every operator is a collection of (size, benefit) points, n points for n schemes </li></ul><ul><li>Operator cost function is the collection of (cost, memory) points of its schemes </li></ul>Benefit (0,0) (s1,b1) (s2,b2) Figure: (Size, Benefit) points for an operator Size Memory Cost (0,c1) (m2,c2) (m3,c3) (0,0) Figure: Operator cost function