ppt format


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ppt format

  1. 1. Recap of Feb 25: Physical Storage Media <ul><li>Issues are speed, cost, reliability </li></ul><ul><li>Media types: </li></ul><ul><ul><li>Primary storage (volatile): Cache, Main Memory </li></ul></ul><ul><ul><li>Secondary or On-line storage (non-volatile): Flash Memory, Mag Disk </li></ul></ul><ul><ul><li>Tertiary or Off-line storage (non-volatile): Optical Storage, Tape Storage </li></ul></ul><ul><li>Mag disk issues </li></ul><ul><ul><li>definitions: sector, track, cylinder </li></ul></ul><ul><ul><li>disk controllers, multiple disks </li></ul></ul><ul><ul><li>disk performance measures (seek time, rotational latency, data transfer rate, MTTF) </li></ul></ul><ul><li>Now we start with Optimization of Disk-Block Access </li></ul>
  2. 2. Optimization of Disk-Block Access: Motivation <ul><li>Requests for disk I/O are generated both by the file system and by the virtual memory manager </li></ul><ul><li>Each request specifies the address on the disk to be referenced in the form of a block number </li></ul><ul><ul><li>a block is a contiguous sequence of sectors from a single track on one platter </li></ul></ul><ul><ul><li>block sizes range from 512 bytes to several K (4 -- 16K is typical) </li></ul></ul><ul><ul><li>smaller blocks mean more transfers from disk; larger blocks makes for more wasted space due to partially filled blocks </li></ul></ul><ul><ul><li>block is the standard unit of data transfer between disk to main memory </li></ul></ul><ul><li>Since disk access speed is much slower than main memory access, methods for optimizing disk-block access are important </li></ul>
  3. 3. Optimization of Disk-Block Access: Methods <ul><li>Disk-arm Scheduling: requests for several blocks may be speeded up by requesting them in the order they will pass under the head. </li></ul><ul><ul><li>If the blocks are on different cylinders, it is advantageous to ask for them in an order that minimizes disk-arm movement </li></ul></ul><ul><ul><li>Elevator algorithm -- move the disk arm in one direction until all requests from that direction are satisfied, then reverse and repeat </li></ul></ul><ul><ul><li>Sequential access is 1-2 orders of magnitude faster; random access is about 2 orders of magnitude slower </li></ul></ul>
  4. 4. Optimization of Disk-Block Access: Methods <ul><li>Non-volatile write buffers </li></ul><ul><ul><li>store written data in a RAM buffer rather than on disk </li></ul></ul><ul><ul><li>write the buffer whenever it becomes full or when no other disk requests are pending </li></ul></ul><ul><ul><li>buffer must be non-volatile to protect from power failure </li></ul></ul><ul><ul><ul><li>called non-volatile random-access memory (NV-RAM) </li></ul></ul></ul><ul><ul><ul><li>typically implemented with battery-backed-up RAM </li></ul></ul></ul><ul><ul><li>dramatic speedup on writes; with a reasonable-sized buffer write latency essentially disappears </li></ul></ul><ul><ul><li>why can’t we do the same for reads? (hints: ESP, clustering) </li></ul></ul>
  5. 5. Optimization of Disk-Block Access: Methods <ul><li>File organization ( Clustering ): reduce access time by organizing blocks on disk in a way that corresponds closely to the way we expect them to be accessed </li></ul><ul><ul><li>sequential files should be kept organized sequentially </li></ul></ul><ul><ul><li>hierarchical files should be organized with mothers next to daughters </li></ul></ul><ul><ul><li>for joining tables (relations) put the joining tuples next to each other </li></ul></ul><ul><ul><li>over time fragmentation can become an issue </li></ul></ul><ul><ul><ul><li>restoration of disk structure (copy and rewrite, reordered) controls fragmentation </li></ul></ul></ul>
  6. 6. Optimization of Disk-Block Access: Methods <ul><li>Log-based file system </li></ul><ul><ul><li>does not update in-place, rather writes updates to a log disk </li></ul></ul><ul><ul><ul><li>essentially, a disk functioning as a non-volatile RAM write buffer </li></ul></ul></ul><ul><ul><li>all access in the log disk is sequential, eliminating seek time </li></ul></ul><ul><ul><li>eventually updates must be propogated to the original blocks </li></ul></ul><ul><ul><ul><li>as with NV-RAM write buffers, this can occur at a time when no disk requests are pending </li></ul></ul></ul><ul><ul><ul><li>the updates can be ordered to minimize arm movement </li></ul></ul></ul><ul><ul><li>this can generate a high degree of fragmentation on files that require constant updates </li></ul></ul><ul><ul><ul><li>fragmentation increases seek time for sequential reading of files </li></ul></ul></ul>
  7. 7. Storage Access (11.5) <ul><li>Basic concepts (some already familiar): </li></ul><ul><ul><li>block-based. A block is a contiguous sequence of sectors from a single track; blocks are units of both storage allocation and data transfer </li></ul></ul><ul><ul><li>a file is a sequence of records stored in fixed-size blocks (pages) on the disk </li></ul></ul><ul><ul><li>each block (page) has a unique address called BID </li></ul></ul><ul><ul><li>optimization is done by reducing I/O, seek time, etc. </li></ul></ul><ul><ul><li>database systems seek to minimize the number of block transfers between the disk and memory. We can reduce the number of disk accesses by keeping as many blocks as possible in main memory. </li></ul></ul><ul><ul><li>Buffer - portion of main memory used to store copies of disk blocks </li></ul></ul><ul><ul><li>buffer manager - subsystem responsible for allocating buffer space in main memory and handling block transfer between buffer and disk </li></ul></ul>
  8. 8. Buffer Management <ul><li>The buffer pool is the part of the main memory alocated for temporarily storing disk blocks read from disk and made available to the CPU </li></ul><ul><li>The buffer manager is the subsystem responsible for the allocation and the management of the buffer space (transparent to users) </li></ul><ul><li>On a process (user) request for a block (page) the buffer manager: </li></ul><ul><ul><li>checks to see if the page is already in the buffer pool </li></ul></ul><ul><ul><li>if so, passes the address to the process </li></ul></ul><ul><ul><li>if not, it loads the page from disk and then passes the address to the process </li></ul></ul><ul><ul><li>loading a page might require clearing (writing out) a page to make space </li></ul></ul><ul><li>Very similar to the way virtual memory managers work, although it can do a lot better (why?) </li></ul>
  9. 9. Buffer Replacement Strategies <ul><li>Most operating systems use a LRU replacement scheme. In database environments, MRU is better for some common operations (e.g., join) </li></ul><ul><ul><li>LRU strategy: replace the least recently used block </li></ul></ul><ul><ul><li>MRU strategy: replace the most recently used block </li></ul></ul><ul><li>Sometimes it is useful to fasten or pin blocks to keep them available during an operation and not let the replacement strategy touch them </li></ul><ul><ul><li>pinned block is thus a block that is not allowed to be written back to disk </li></ul></ul><ul><li>There are situations where it is necessary to write back a block to disk even though the buffer space it occupies is not yet needed. This write is called the forced output of a block; useful in recovery situations </li></ul><ul><li>Toss-immediate strategy: free the space occupied by a block as soon as the final tuple of that block has been processed </li></ul>
  10. 10. Buffer Replacement Strategies <ul><li>Most recently used (MRU) strategy: system must pin the block currently being processed. After the final tuple of that block has been processed the block is unpinned and becomes the most recently used block. This is essentially “toss-immediate” with pinning, and works very well with joins. </li></ul><ul><li>The buffer manager can often use other information (design or statistical) to predict the probability that a request will reference a particular page </li></ul><ul><ul><li>e.g., the data dictionary is frequently accessed -- keep the data dictionary blocks in main memory buffer </li></ul></ul><ul><ul><li>if several pages are available for overwrite; choose the one that has the lowest number of recent access requests to replace </li></ul></ul>
  11. 11. Buffer Management (cont) <ul><li>Existing OS affect DBMS operations by: </li></ul><ul><ul><li>read ahead, write behind </li></ul></ul><ul><ul><li>wrong replacement strategies </li></ul></ul><ul><ul><li>Unix is not good for DBMS to run on top </li></ul></ul><ul><ul><li>Most commercial systems implement their own I/O on a raw disk partition </li></ul></ul><ul><li>Variations of buffer allocation </li></ul><ul><ul><li>common buffer pool for all relations </li></ul></ul><ul><ul><li>separate buffer pool for each relation </li></ul></ul><ul><ul><li>as above but with relations borrowing space from each other </li></ul></ul><ul><ul><li>prioritized buffers for very frequently accessed blocks, e.g. data dictionary </li></ul></ul>
  12. 12. Buffer Management (cont) <ul><li>For each buffer the manager keeps the following: </li></ul><ul><ul><li>which disk and which block it is in </li></ul></ul><ul><ul><li>whether the block is dirty (has been modified) or not (why?) </li></ul></ul><ul><ul><li>information for the replacement strategy </li></ul></ul><ul><ul><ul><li>last time block was accessed </li></ul></ul></ul><ul><ul><ul><li>whether it is pinned </li></ul></ul></ul><ul><ul><ul><li>possible statistical information (access frequency etc.) </li></ul></ul></ul>
  13. 13. Buffer Management and Disk-block Access Optimization (end) <ul><li>Disk-block access methods must take care of some information within each block, as well as information about each block: </li></ul><ul><ul><li>allocate records (tuples) within blocks </li></ul></ul><ul><ul><li>support record addressing by address and by value </li></ul></ul><ul><ul><li>support auxiliary (secondary indexing) file structures for more efficient processing </li></ul></ul><ul><li>These concerns are linked in to our next topic: </li></ul><ul><li>file organization. </li></ul>