Layers of a DBMS Query optimization Execution engine Files and access methods Buffer management Disk space management Query Processor Query execution plan

The Memory Hierarchy Main Memory Disks Tapes Volatile limited address spaces expensive average access time: nanoseconds 5-10 MB/S transmission rates 2-10 GB storage average time to access a block: msecs. Need to consider seek, rotation, transfer times. Keep records “close” to each other. 1.5 MB/S transfer rate 280 GB typical capacity Only sequential access Not for operational data

Disk Space Manager Task: manage the location of pages on disk (page = block) Provides commands for: allocating and deallocating a page on disk reading and writing pages. Why not use the operating system for this task? Portability Limited size of address space May need to span several disk devices. Platters Spindle Disk head Arm movement Arm assembly Tracks Sector

Buffer Management in a DBMS Data must be in RAM for DBMS to operate on it! Table of pairs is maintained. DB MAIN MEMORY DISK disk page free frame Page Requests from Higher Levels BUFFER POOL choice of frame dictated by replacement policy

When a Page is Requested... If requested page is not in pool: –Choose a frame for replacement –If frame is dirty, write it to disk –Read requested page into chosen frame Pin the page and return its address. * If requests can be predicted (e.g., sequential scans) pages can be pre-fetched several pages at a time!

Buffer Manager Manages buffer pool: the pool provides space for a limited number of pages from disk. Needs to decide on page replacement policy. Enables the higher levels of the DBMS to assume that the needed data is in main memory. Why not use the Operating System for the task?? - DBMS may be able to anticipate access patterns - Hence, may also be able to perform prefetching - DBMS needs the ability to force pages to disk.

Record Formats: Fixed Length Information about field types same for all records in a file; stored in system catalogs. Finding i’th field requires scan of record. Base address (B) L1L2 L3L4 F1F2 F3F4 Address = B+L1+L2

Files of Records Page or block is OK when doing I/O, but higher levels of DBMS operate on records, and files of records. FILE : A collection of pages, each containing a collection of records. Must support: –insert/delete/modify record –read a particular record (specified using record id) –scan all records (possibly with some conditions on the records to be retrieved)

Alternative File Organizations Many alternatives exist, each ideal for some situation, and not so good in others: –Heap files: Suitable when typical access is a file scan retrieving all records. –Sorted Files: Best if records must be retrieved in some order, or only a `range’ of records is needed. –Hashed Files: Good for equality selections. File is a collection of buckets. Bucket = primary page plus zero or more overflow pages. Hashing function h: h(r) = bucket in which record r belongs. h looks at only some of the fields of r, called the search fields.

Unordered (Heap) Files Simplest file structure contains records in no particular order. As file grows and shrinks, disk pages are allocated and de-allocated. To support record level operations, we must: –keep track of the pages in a file –keep track of free space on pages –keep track of the records on a page There are many alternatives for keeping track of this.

Cost Model for Our Analysis We ignore CPU costs, for simplicity: –B: The number of data pages –R: Number of records per page –D: (Average) time to read or write disk page –Measuring number of page I/O’s ignores gains of pre-fetching blocks of pages; thus, even I/O cost is only approximated. –Average-case analysis; based on several simplistic assumptions. * Good enough to show the overall trends!

Assumptions in Our Analysis Single record insert and delete. Heap Files: –Equality selection on key; exactly one match. –Insert always at end of file. Sorted Files: –Files compacted after deletions. –Selections on sort field(s). Hashed Files: –No overflow buckets, 80% page occupancy.

Cost of Operations * Several assumptions underlie these (rough) estimates!

Cost of Operations * Several assumptions underlie these (rough) estimates!

Indexes An index on a file speeds up selections on the search key fields for the index. –Any subset of the fields of a relation can be the search key for an index on the relation. –Search key is not the same as key (minimal set of fields that uniquely identify a record in a relation). An index contains a collection of data entries, and supports efficient retrieval of all data entries k* with a given key value k.