Storing Data: Disks and Files. Storing and Retrieving Data. Why Not Store Everything in Main Memory? Chapter 7

Similar documents
Storing and Retrieving Data. Storing Data: Disks and Files. Solution 1: Techniques for making disks faster. Disks. Why Not Store Everything in Tapes?

Storing Data: Disks and Files. Storing and Retrieving Data. Why Not Store Everything in Main Memory? Database Management Systems need to:

Storing and Retrieving Data. Storing Data: Disks and Files. Solution 1: Techniques for making disks faster. Disks. Why Not Store Everything in Tapes?

Storing Data: Disks and Files

Storing Data: Disks and Files

Storing Data: Disks and Files

Storing Data: Disks and Files

Review 1-- Storing Data: Disks and Files

Disks and Files. Storage Structures Introduction Chapter 8 (3 rd edition) Why Not Store Everything in Main Memory?

Storing Data: Disks and Files. Administrivia (part 2 of 2) Review. Disks, Memory, and Files. Disks and Files. Lecture 3 (R&G Chapter 7)

L9: Storage Manager Physical Data Organization

Disks and Files. Jim Gray s Storage Latency Analogy: How Far Away is the Data? Components of a Disk. Disks

Storing Data: Disks and Files

Principles of Data Management. Lecture #2 (Storing Data: Disks and Files)

Database Systems. November 2, 2011 Lecture #7. topobo (mit)

Disks, Memories & Buffer Management

Principles of Data Management. Lecture #3 (Managing Files of Records)

CS 405G: Introduction to Database Systems. Storage

Disks & Files. Yanlei Diao UMass Amherst. Slides Courtesy of R. Ramakrishnan and J. Gehrke

Storing Data: Disks and Files

ECS 165B: Database System Implementa6on Lecture 2

Outlines. Chapter 2 Storage Structure. Structure of a DBMS (with some simplification) Structure of a DBMS (with some simplification)

Database Applications (15-415)

ECS 165B: Database System Implementa6on Lecture 3

Managing Storage: Above the Hardware

Project is due on March 11, 2003 Final Examination March 18, pm to 10.30pm

Database design and implementation CMPSCI 645. Lecture 08: Storage and Indexing

Database Applications (15-415)

CS220 Database Systems. File Organization

STORING DATA: DISK AND FILES

CPSC 421 Database Management Systems. Lecture 11: Storage and File Organization

Normalization, Generated Keys, Disks

Storing Data: Disks and Files

Unit 2 Buffer Pool Management

User Perspective. Module III: System Perspective. Module III: Topics Covered. Module III Overview of Storage Structures, QP, and TM

RAID in Practice, Overview of Indexing

CSE 190D Database System Implementation

Announcements. Reading Material. Recap. Today 9/17/17. Storage (contd. from Lecture 6)

Parser. Select R.text from Report R, Weather W where W.image.rain() and W.city = R.city and W.date = R.date and R.text.

Unit 3 Disk Scheduling, Records, Files, Metadata

Unit 2 Buffer Pool Management

Goals for Today. CS 133: Databases. Relational Model. Multi-Relation Queries. Reason about the conceptual evaluation of an SQL query

CSCI-GA Database Systems Lecture 8: Physical Schema: Storage

Database Management Systems. Buffer and File Management. Fall Queries. Query Optimization and Execution. Relational Operators

CSE 232A Graduate Database Systems

A memory is what is left when something happens and does not completely unhappen.

Why Is This Important? Overview of Storage and Indexing. Components of a Disk. Data on External Storage. Accessing a Disk Page. Records on a Disk Page

Roadmap. Handling large amount of data efficiently. Stable storage. Parallel dataflow. External memory algorithms and data structures

Oracle on RAID. RAID in Practice, Overview of Indexing. High-end RAID Example, continued. Disks and Files: RAID in practice. Gluing RAIDs together

Introduction to Data Management. Lecture #13 (Indexing)

CS122A: Introduction to Data Management. Lecture #14: Indexing. Instructor: Chen Li

Storage and File Structure

Database Systems II. Secondary Storage

Data Storage and Query Answering. Data Storage and Disk Structure (2)

Introduction to Data Management. Lecture 14 (Storage and Indexing)

Today: Secondary Storage! Typical Disk Parameters!

DATA STORAGE, RECORD and FILE STUCTURES

CSE 544 Principles of Database Management Systems. Magdalena Balazinska Winter 2009 Lecture 6 - Storage and Indexing

Chapter 1 Disk Storage, Basic File Structures, and Hashing.

Important Note. Today: Starting at the Bottom. DBMS Architecture. General HeapFile Operations. HeapFile In SimpleDB. CSE 444: Database Internals

Classifying Physical Storage Media. Chapter 11: Storage and File Structure. Storage Hierarchy (Cont.) Storage Hierarchy. Magnetic Hard Disk Mechanism

Classifying Physical Storage Media. Chapter 11: Storage and File Structure. Storage Hierarchy. Storage Hierarchy (Cont.) Speed

Storage and File Structure. Classification of Physical Storage Media. Physical Storage Media. Physical Storage Media

Chapter 10 Storage and File Structure

Ch 11: Storage and File Structure

File. File System Implementation. Operations. Permissions and Data Layout. Storing and Accessing File Data. Opening a File

Introduction Disks RAID Tertiary storage. Mass Storage. CMSC 420, York College. November 21, 2006

Physical Data Organization. Introduction to Databases CompSci 316 Fall 2018

STORING DATA: DISK AND FILES

Storage Devices for Database Systems

BBM371- Data Management. Lecture 2: Storage Devices

Chapter 13 Disk Storage, Basic File Structures, and Hashing.

Advanced Database Systems

Chapter 10: Mass-Storage Systems

V. Mass Storage Systems

Chapter 10: Mass-Storage Systems. Operating System Concepts 9 th Edition

Indexing. Jan Chomicki University at Buffalo. Jan Chomicki () Indexing 1 / 25

File Structures and Indexing

Midterm Review CS634. Slides based on Database Management Systems 3 rd ed, Ramakrishnan and Gehrke

Chapter 11: Storage and File Structure. Silberschatz, Korth and Sudarshan Updated by Bird and Tanin

System Structure Revisited

File. File System Implementation. File Metadata. File System Implementation. Direct Memory Access Cont. Hardware background: Direct Memory Access

CMSC 424 Database design Lecture 12 Storage. Mihai Pop

Storage. Database Systems: The Complete Book

QUIZ: Is either set of attributes a superkey? A candidate key? Source:

Operating Systems. Operating Systems Professor Sina Meraji U of T

ECE331: Hardware Organization and Design

Mass-Storage Structure

CS 554: Advanced Database System

Introduction to I/O and Disk Management

CS510 Operating System Foundations. Jonathan Walpole

CS3600 SYSTEMS AND NETWORKS

Introduction to I/O and Disk Management

Database Systems II. Record Organization

Chapter 14: Mass-Storage Systems

Virtual Memory. Reading. Sections 5.4, 5.5, 5.6, 5.8, 5.10 (2) Lecture notes from MKP and S. Yalamanchili

Chapter 10: Mass-Storage Systems

Chapter 13: Mass-Storage Systems. Disk Scheduling. Disk Scheduling (Cont.) Disk Structure FCFS. Moving-Head Disk Mechanism

Chapter 13: Mass-Storage Systems. Disk Structure

Advanced Database Systems

Transcription:

Storing : Disks and Files Chapter 7 base Management Systems, R. Ramakrishnan and J. Gehrke 1 Storing and Retrieving base Management Systems need to: Store large volumes of data Store data reliably (so that data is not lost!) Retrieve data efficiently Alternatives for storage Main memory Disks Tape base Management Systems, R. Ramakrishnan and J. Gehrke 2 Why Not Store Everything in Main Memory? Costs too much. $500 will buy you either 512MB of RAM or 100GB of disk today. Main memory is volatile. We want data to be saved between runs. (Obviously!) base Management Systems, R. Ramakrishnan and J. Gehrke 3

Why Not Store Everything in Tapes? No random access. has to be accessed sequentially Not a great idea when accessing a small portion of a terabyte of data Slow! access times are larger than for disks base Management Systems, R. Ramakrishnan and J. Gehrke 4 Disks Secondary storage device of choice Cheap Stable storage medium Random access to data Main problem read/write times much larger than for main memory base Management Systems, R. Ramakrishnan and J. Gehrke 5 Solution 1: Techniques for making disks faster Intelligent data layout on disk Put related data items together Redundant Array of Inexpensive Disks (RAID) Achieve parallelism by using many disks base Management Systems, R. Ramakrishnan and J. Gehrke 6

Solution 2: Buffer Management Keep currently used data in main memory How do we do this efficiently? Typical storage hierarchy: Main memory (RAM) for currently used data Disks for the main database (secondary storage) Tapes for archiving older versions of the data (tertiary storage) base Management Systems, R. Ramakrishnan and J. Gehrke 7 Outline Disk technology and how to make disk read/writes faster Buffer management Storing database files on disk base Management Systems, R. Ramakrishnan and J. Gehrke 8 Components of a Disk The platters spin (say, 100rps). The arm assembly is moved in or out to position a head on a desired track. Tracks under heads make a cylinder (imaginary!). Only one head reads/writes at any one time. Block size is a multiple of sector size (which is fixed). Spindle Tracks Sector Platters base Management Systems, R. Ramakrishnan and J. Gehrke 9

Accessing a Disk Time to access (read/write) a disk block: seek time (moving arms to position disk head on track) rotational delay (waiting for block to rotate under head) transfer time (actually moving data to/from disk surface) Seek time and rotational delay dominate. Seek time varies from about 1 to 20msec Rotational delay varies from 0 to 10msec Transfer rate is about 0.5msec per 4KB page Key to lower I/O cost: reduce seek/rotation delays! Hardware vs. software solutions? base Management Systems, R. Ramakrishnan and J. Gehrke 10 Arranging s on Disk `Next block concept: blocks on same track, followed by blocks on same cylinder, followed by blocks on adjacent cylinder Blocks in a file should be arranged sequentially on disk (by `next ), to minimize seek and rotational delay. For a sequential scan, pre-fetching several pages at a time is a big win! base Management Systems, R. Ramakrishnan and J. Gehrke 11 RAID Disk Array: Arrangement of several disks that gives abstraction of a single, large disk. Goals: Increase performance and reliability. Two main techniques: striping: is partitioned; size of a partition is called the striping unit. Partitions are distributed over several disks. Redundancy: More disks -> more failures. Redundant information allows reconstruction of data if a disk fails. base Management Systems, R. Ramakrishnan and J. Gehrke 12

RAID Levels Level 0: No redundancy Level 1: Mirrored (two identical copies) Each disk has a mirror image (check disk) Parallel reads, a write involves two disks. Maximum transfer rate = transfer rate of one disk Level 0+1: Striping and Mirroring Parallel reads, a write involves two disks. Maximum transfer rate = aggregate bandwidth base Management Systems, R. Ramakrishnan and J. Gehrke 13 RAID Levels (Contd.) Level 3: Bit-Interleaved Parity Striping Unit: One bit. One check disk. Each read and write request involves all disks; disk array can process one request at a time. Level 4: Block-Interleaved Parity Striping Unit: One disk block. One check disk. Parallel reads possible for small requests, large requests can utilize full bandwidth Writes involve modified block and check disk Level 5: Block-Interleaved Distributed Parity Similar to RAID Level 4, but parity blocks are distributed over all disks base Management Systems, R. Ramakrishnan and J. Gehrke 14 Disk Space Management Lowest layer of DBMS software manages space on disk. Higher levels call upon this layer to: allocate/de-allocate a page read/write a page Request for a sequence of pages must be satisfied by allocating the pages sequentially on disk! Higher levels don t need to know how this is done, or how free space is managed. base Management Systems, R. Ramakrishnan and J. Gehrke 15

Outline Disk technology and how to make disk read/writes faster Buffer management Storing database files on disk base Management Systems, R. Ramakrishnan and J. Gehrke 16 Buffer Management in a DBMS Requests from Higher Levels BUFFER POOL disk page free frame MAIN MEMORY DISK DB choice of frame dictated by replacement policy must be in RAM for DBMS to operate on it! Table of <frame#, pageid> pairs is maintained. base Management Systems, R. Ramakrishnan and J. Gehrke 17 When a 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! base Management Systems, R. Ramakrishnan and J. Gehrke 18

More on Buffer Management Requestor of page must unpin it, and indicate whether page has been modified: dirty bit is used for this. in pool may be requested many times, a pin count is used. A page is a candidate for replacement iff pin count = 0. CC & recovery may entail additional I/O when a frame is chosen for replacement. (Write-Ahead Log protocol; more later.) base Management Systems, R. Ramakrishnan and J. Gehrke 19 Buffer Replacement Policy Frame is chosen for replacement by a replacement policy: Least-recently-used (LRU), Clock, MRU etc. Policy can have big impact on # of I/O s; depends on the access pattern. Sequential flooding: Nasty situation caused by LRU + repeated sequential scans. # buffer frames < # pages in file means each page request causes an I/O. MRU much better in this situation (but not in all situations, of course). base Management Systems, R. Ramakrishnan and J. Gehrke 20 DBMS vs. OS File System OS does disk space & buffer mgmt: why not let OS manage these tasks? Differences in OS support: portability issues Some limitations, e.g., files can t span disks. Buffer management in DBMS requires ability to: pin a page in buffer pool, force a page to disk (important for implementing CC & recovery), adjust replacement policy, and pre-fetch pages based on access patterns in typical DB operations. base Management Systems, R. Ramakrishnan and J. Gehrke 21

Outline Disk technology and how to make disk read/writes faster Buffer management Storing database files on disk base Management Systems, R. Ramakrishnan and J. Gehrke 22 Files of Records 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) base Management Systems, R. Ramakrishnan and J. Gehrke 23 Record Formats: Fixed Length F1 F2 F3 F4 L1 L2 L3 L4 Base address (B) Address = B+L1+L2 Information about field types same for all records in a file; stored in system catalogs. Finding i th field requires scan of record. base Management Systems, R. Ramakrishnan and J. Gehrke 24

Record Formats: Variable Length Two alternative formats (# fields is fixed): Field Count F1 F2 F3 F4 4 $ $ $ $ Fields Delimited by Special Symbols F1 F2 F3 F4 Array of Field Offsets Second offers direct access to i th field, efficient storage of nulls (special don t know value); small directory overhead. base Management Systems, R. Ramakrishnan and J. Gehrke 25 Formats: Fixed Length Records Slot 1 Slot 2 Slot N Free Space Slot 1 Slot 2...... Slot N PACKED N number of records Slot M 1... 0 1 M... 3 2 1 1 M UNPACKED, BITMAP number of slots Record id = <page id, slot #>. In first alternative, moving records for free space management changes rid; may not be acceptable. base Management Systems, R. Ramakrishnan and J. Gehrke 26 Formats: Variable Length Records Rid = (i,n) Rid = (i,2) i Rid = (i,1) 20 16 24 N N... 2 1 # slots SLOT DIRECTORY Can move records on page without changing rid; so, attractive for fixed-length records too. Pointer to start of free space base Management Systems, R. Ramakrishnan and J. Gehrke 27

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. base Management Systems, R. Ramakrishnan and J. Gehrke 28 Heap File Implemented as a List Full s Header s with Free Space The header page id and Heap file name must be stored someplace. Each page contains 2 `pointers plus data. base Management Systems, R. Ramakrishnan and J. Gehrke 29 Heap File Using a Directory Header 1 2 DIRECTORY N The entry for a page can include the number of free bytes on the page. The directory is a collection of pages; linked list implementation is just one alternative. Much smaller than linked list of all HF pages! base Management Systems, R. Ramakrishnan and J. Gehrke 30

Indexes A Heap file allows us to retrieve records: by specifying the rid, or by scanning all records sequentially Sometimes, we want to retrieve records by specifying the values in one or more fields, e.g., Find all students in the CS department Find all students with a gpa > 3 Indexes are file structures that enable us to answer such value-based queries efficiently. base Management Systems, R. Ramakrishnan and J. Gehrke 31 System Catalogs For each index: structure (e.g., B+ tree) and search key fields For each relation: name, file name, file structure (e.g., Heap file) attribute name and type, for each attribute index name, for each index integrity constraints For each view: view name and definition Plus statistics, authorization, buffer pool size, etc. Catalogs are themselves stored as relations! base Management Systems, R. Ramakrishnan and J. Gehrke 32 Attr_Cat(attr_name, rel_name, type, position) attr_name rel_name type position attr_name Attribute_Cat string 1 rel_name Attribute_Cat string 2 type Attribute_Cat string 3 position Attribute_Cat integer 4 sid Students string 1 name Students string 2 login Students string 3 age Students integer 4 gpa Students real 5 fid Faculty string 1 fname Faculty string 2 sal Faculty real 3 base Management Systems, R. Ramakrishnan and J. Gehrke 33

Summary Disks provide cheap, non-volatile storage. Random access, but cost depends on location of page on disk; important to arrange data sequentially to minimize seek and rotation delays. Buffer manager brings pages into RAM. stays in RAM until released by requestor. Written to disk when frame chosen for replacement (which is sometime after requestor releases the page). Choice of frame to replace based on replacement policy. Tries to pre-fetch several pages at a time. base Management Systems, R. Ramakrishnan and J. Gehrke 34 Summary (Contd.) DBMS vs. OS File Support DBMS needs features not found in many OS s, e.g., forcing a page to disk, controlling the order of page writes to disk, files spanning disks, ability to control pre-fetching and page replacement policy based on predictable access patterns, etc. Variable length record format with field offset directory offers support for direct access to i th field and null values. Slotted page format supports variable length records and allows records to move on page. base Management Systems, R. Ramakrishnan and J. Gehrke 35 Summary (Contd.) File layer keeps track of pages in a file, and supports abstraction of a collection of records. s with free space identified using linked list or directory structure (similar to how pages in file are kept track of). Indexes support efficient retrieval of records based on the values in some fields. Catalog relations store information about relations, indexes and views. (Information that is common to all records in a given collection.) base Management Systems, R. Ramakrishnan and J. Gehrke 36