Layers of a DBMS - PowerPoint PPT Presentation

About This Presentation
Title:

Layers of a DBMS

Description:

Title: Architecture of a DBMS Author: alon Last modified by: alon Created Date: 11/18/1998 5:26:12 PM Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:26
Avg rating:3.0/5.0
Slides: 16
Provided by: Alon75
Category:

less

Transcript and Presenter's Notes

Title: Layers of a DBMS


1
Layers of a DBMS
Query
Query optimization Execution engine Files and
access methods Buffer management Disk space
management
Query Processor
Query execution plan
2
The Memory Hierarchy
Main Memory Disks
Tapes
  • 5-10 MB/S
  • transmission rates
  • 2-10 GB storage
  • average time to
  • access a block
  • 10-15 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
  • Volatile
  • limited address
  • spaces
  • expensive
  • average access
  • time
  • 10-100 nanoseconds

3
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.

Spindle
Disk head
Sector
Platters
4
Buffer Management in a DBMS
Page Requests from Higher Levels
BUFFER POOL
disk page
free frame
MAIN MEMORY
DISK
choice of frame dictated by replacement policy
  • Data must be in RAM for DBMS to operate on it!
  • Table of ltframe, pageidgt pairs is maintained.

5
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!

6
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.
7
Record Formats Fixed Length
F1
F2
F3
F4
L1
L2
L3
L4
Base address (B)
Address BL1L2
  • Information about field types same for all
    records in a file stored in system catalogs.
  • Finding ith field requires scan of record.

8
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)

9
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.

10
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.

11
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/Os 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!

12
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.

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

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

15
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.
Write a Comment
User Comments (0)
About PowerShow.com