Database Applications (15-415) DBMS Internals- Part I Lecture 10, September 27, 2016 Mohammad Hammoud.

Slides:



Advertisements
Similar presentations
Storing Data: Disk Organization and I/O
Advertisements

Faculty of Information Technology Department of Computer Science Computer Organization Chapter 7 External Memory Mohammad Sharaf.
Magnetic Disk Magnetic disks are the foundation of external memory on virtually all computer systems. A disk is a circular platter constructed of.
RAID Redundant Array of Independent Disks
CS 6560: Operating Systems Design
Storing Data: Disks and Files: Chapter 9
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Storing Data: Disks and Files Chapter 7.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Disks and RAID.
1 Storing Data: Disks and Files Yanlei Diao UMass Amherst Feb 15, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
SECTIONS 13.1 – 13.3 Sanuja Dabade & Eilbroun Benjamin CS 257 – Dr. TY Lin SECONDARY STORAGE MANAGEMENT.
Disks CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
Secondary Storage CSCI 444/544 Operating Systems Fall 2008.
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How data are stored? –physical level –logical level.
Introduction to Database Systems 1 The Storage Hierarchy and Magnetic Disks Storage Technology: Topic 1.
Layers of a DBMS Query optimization Execution engine Files and access methods Buffer management Disk space management Query Processor Query execution plan.
CS 352 : Computer Organization and Design University of Wisconsin-Eau Claire Dan Ernst Storage Systems.
1 Recitation 8 Disk & File System. 2 Disk Scheduling Disks are at least four orders of magnitude slower than main memory –The performance of disk I/O.
Lecture 11: DMBS Internals
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How are data stored? –physical level –logical level.
Disk Access. DISK STRUCTURE Sector: Smallest unit of data transfer from/to disk; 512B 2/4/8 adjacent sectors transferred together: Blocks Read/write heads.
Lecture 9 of Advanced Databases Storage and File Structure (Part II) Instructor: Mr.Ahmed Al Astal.
Introduction to Database Systems 1 Storing Data: Disks and Files Chapter 3 “Yea, from the table of my memory I’ll wipe away all trivial fond records.”
1 Storing Data: Disks and Files Chapter 9. 2 Disks and Files  DBMS stores information on (“hard”) disks.  This has major implications for DBMS design!
“Yea, from the table of my memory I’ll wipe away all trivial fond records.” -- Shakespeare, Hamlet.
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How data are stored? –physical level –logical level.
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
DMBS Internals I February 24 th, What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the.
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
Lecture 3 Secondary Storage and System Software I
CS422 Principles of Database Systems Disk Access Chengyu Sun California State University, Los Angeles.
1 Storing Data: Disks and Files Chapter 9. 2 Objectives  Memory hierarchy in computer systems  Characteristics of disks and tapes  RAID storage systems.
Database Applications (15-415) DBMS Internals: Part II Lecture 12, February 21, 2016 Mohammad Hammoud.
File organization Secondary Storage Devices Lec#7 Presenter: Dr Emad Nabil.
Magnetic Disks Have cylinders, sectors platters, tracks, heads virtual and real disk blocks (x cylinders, y heads, z sectors per track) Relatively slow,
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Disks and Files.
CS Introduction to Operating Systems
Storage HDD, SSD and RAID.
CS522 Advanced database Systems
Storage Overview of Physical Storage Media Magnetic Disks RAID
Database Applications (15-415) DBMS Internals- Part I Lecture 11, February 16, 2016 Mohammad Hammoud.
Multiple Platters.
External Memory.
Storing Data: Disks and Files
Database Applications (15-415) DBMS Internals: Part II Lecture 11, October 2, 2016 Mohammad Hammoud.
Lecture 16: Data Storage Wednesday, November 6, 2006.
Disks and RAID.
RAID Non-Redundant (RAID Level 0) has the lowest cost of any RAID
Database Management Systems (CS 564)
Oracle SQL*Loader
Lecture 11: DMBS Internals
Storing Data: Disks and Files
Database Applications (15-415) DBMS Internals- Part III Lecture 15, March 11, 2018 Mohammad Hammoud.
Database Applications (15-415) DBMS Internals: Part II Lecture 13, February 25, 2018 Mohammad Hammoud.
RAID RAID Mukesh N Tekwani
Lecture 9: Data Storage and IO Models
Sanuja Dabade & Eilbroun Benjamin CS 257 – Dr. TY Lin
Disk Storage, Basic File Structures, and Buffer Management
ICOM 6005 – Database Management Systems Design
Database Systems November 2, 2011 Lecture #7.
5. Disk, Pages and Buffers Why Not Store Everything in Main Memory
Overview Continuation from Monday (File system implementation)
UNIT IV RAID.
Mark Zbikowski and Gary Kimura
Secondary Storage Management Brian Bershad
File Storage and Indexing
Basics Storing Data on Disks and Files
Secondary Storage Management Hank Levy
Database Systems (資料庫系統)
RAID RAID Mukesh N Tekwani April 23, 2019
Storing Data: Disks and Files
Presentation transcript:

Database Applications (15-415) DBMS Internals- Part I Lecture 10, September 27, 2016 Mohammad Hammoud

Today… Last Sessions: SQL- Part III Today’s Session: JDBC DBMS Internals- Part I Background on Disks and Disk Arrays Announcements: Quiz I is on Thursday, Sep 29 (during the recitation time) P1 is due on Tuesday, Oct 4 PS2 grades will be out on Thursday

Java Database Connectivity

Establishing a Connection You can create the following function: public Connection getConnection() throws SQLException { String url = "jdbc:postgresql://localhost/test"; Properties props = new Properties(); props.setProperty("user",“Hammoud"); props.setProperty("password","secret"); props.setProperty("ssl","true"); Connection conn = DriverManager.getConnection(url, props); System.out.println("Connected to database"); return conn; }

Creating Tables Assume the following students table: SQL: JDBC: Sid Name 1 Hammoud 2 Esam SQL: CREATE TABLE students( sid INTEGER, name CHAR(30), PRIMARY KEY (sid)) public void createTable() throws SQLException { String createT = "create table students (sid INTEGER, " + “name CHAR(30) “ + "PRIMARY KEY (sid))"; Statement stmt = null; try { stmt = conn.createStatement(); stmt.executeUpdate(createT); } catch (SQLException e) { e.printStackTrace(e); } finally { if (stmt != null) { stmt.close(); } } } JDBC:

Populating Tables Assume the following students table: SQL: JDBC: Sid Name 1 Hammoud 2 Esam INSERT INTO students values (1, ‘Hammoud) INSERT INTO students values (2, ‘Esam’) SQL: public void populateTable() throws SQLException { Statement stmt = null; try { stmt = conn.createStatement(); stmt.executeUpdate( "insert into students values(1, ‘Hammoud‘)”); stmt.executeUpdate( "insert into students values(2, ‘Esam‘)”); } catch (SQLException e) {} finally { if (stmt != null) { stmt.close(); } } } JDBC:

Querying Tables Assume the following students table: SQL: JDBC: Sid Name 1 Hammoud 2 Esam SQL: SELECT sid, name from students public static void viewTable() throws SQLException { Statement stmt = null; String query = "select sid, name from students"; try { stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(query); while (rs.next()) { int sID = rs.getInt(“sid"); String sName = rs.getString(“name"); System.out.println(sName + "\t" + sID); } } catch (SQLException e ) {} finally { if (stmt != null) { stmt.close(); } } } A “cursor” that points to one row of data at a time Columns retrieved by names JDBC:

Querying Tables Assume the following students table: SQL: JDBC: Sid Name 1 Hammoud 2 Esam SQL: SELECT sid, name from students public static void viewTable() throws SQLException { Statement stmt = null; String query = "select sid, name from students"; try { stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(query); while (rs.next()) { int sID = rs.getInt(1); String sName = rs.getString(2); System.out.println(sName + "\t" + sID); } } catch (SQLException e ) {} finally { if (stmt != null) { stmt.close(); } } } OR: Columns retrieved by numbers JDBC:

By default, you can call only next()! Cursor Methods Methods available to move the cursor of a result set: next() previous() first() Last() beforeFirst() afterLast() relative(int rows) absolute(int row) By default, you can call only next()!

Updating Tables By default, ResultSet objects cannot be updated, and their cursors can only be moved forward ResultSet objects can be though defined to be scrollable (the cursor can move backwards or move to an absolute position) and updatable public void modifyStudents() throws SQLException { Statement stmt = null; try { /* stmt = con.createStatement(); */ stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE); ResultSet uprs = stmt.executeQuery( "SELECT * FROM students"); while (uprs.next()) { String old_n = uprs.getString(“name"); uprs.updateString( “name", “Mohammad” + old_n); uprs.updateRow(); } } catch (SQLException e ) {} finally { if (stmt != null) { stmt.close(); } } }

Result Set Types TYPE_FORWARD_ONLY (the default) The result set is not scrollable TYPE_SCROLL_INSENSITIVE The result set is scrollable The result set is insensitive to changes made to the underlying data source while it is open TYPE_SCROLL_SENSITIVE The result set is sensitive to changes made to the underlying data source while it is open

Result Set Concurrency The concurrency of a ResultSet object determines what level of update functionality is supported Concurrency levels: CONCUR_READ_ONLY (the default) The result set cannot be updated CONCUR_UPDATABLE The result set can be updated

More about JDBC in the upcoming two recitations! Prepared Statements JDBC allows using a PreparedStatement object for sending SQL statements to a database This way, the same statement can be used with different values many times … String sql = “INSERT into students values (?, ?)”; PreparedStatement ps = conn.prepareStatement(sql); ps.clearParameters(); ps.setInt(1, 111); ps.setString(2, “Hammoud”); int numRows1 = ps.executeUpdate(); ps.setInt(1, 222); ps.setString(2, “Esam”); int numRows2 = ps.executeUpdate(); More about JDBC in the upcoming two recitations! 1 2

DBMS Layers Queries Query Optimization and Execution Relational Operators Transaction Manager Files and Access Methods Recovery Manager Buffer Management Lock Manager Disk Space Management DB Today and the Next Two Weeks

Outline Where Do DBMSs Store Data? Various Disk Organizations and Reliability and Performance Implications on DBMSs Disk Space Management

The Memory Hierarchy Storage devices play an important role in database systems How systems arrange storage? P P 2-3 GHZ 16KB-64KB 2-4 Cycles L1-I L1-D L1-I L1-D 512KB-8MB 6-15 Cycles L2 Cache More expensive, but faster! Less expensive, but slower! L3 Cache 4MB-32MB 30-50 Cycles Main Memory 1GB-8GB 600+ Cycles Disk 160GB- 4TB 1000s of times slower

Where to Store Data? Where do DBMSs store information? DBMSs store large amount of data (what about Big Data?)– as of now, we assume centralized DBMSs Typically, buying enough memory to store all data is prohibitively expensive (let alone that classical memories are volatile) Thus, databases are usually stored on disks (or tapes for backups)

But, Is Memory Gone? I/O Time Data must be brought into memory to be processed! READ: transfer data from disk to main memory (RAM) WRITE: transfer data from RAM to disk I/O time dominates the time taken for database operations! To minimize I/O time, it is necessary to store and locate data strategically I/O Time

Magnetic Disks Data is stored in disk blocks Blocks are arranged in concentric rings called tracks Each track is divided into arcs called sectors (whose size is fixed) The block size is a multiple of sector size The set of all tracks with the same diameter is called cylinder To read/write data, the arm assembly is moved in or out to position a head on a desired track Platters Spindle Disk head Arm movement Arm assembly Tracks Sector

Accessing a Disk Block What is I/O time? The time to move the disk heads to the track on which a desired block is located The waiting time for the desired block to rotate under the disk head The time to actually read or write the data in the block once the head is positioned

Accessing a Disk Block What is I/O time? Seek Time Rotational Time The time to move the disk heads to the track on which a desired block is located The waiting time for the desired block to rotate under the disk head The time to actually read or write the data in the block once the head is positioned I/O time = seek time + rotational time + transfer time Seek Time Rotational Time Transfer Time

Implications on DBMSs Seek time and rotational delay dominate! Key to lower I/O cost: reduce seek/rotation delays! How to minimize seek and rotational delays? Blocks on same track, followed by Blocks on same cylinder, followed by Blocks on adjacent cylinder Hence, sequential arrangement of blocks of a file is a big win! More on that later…

Outline Where Do DBMSs Store Data? Various Disk Organizations and Reliability and Performance Implications on DBMSs Disk Space Management

Faloutsos CMU - 15-415/615 Many Disks vs. One Disk Although disks provide cheap, non-volatile storage for DBMSs, they are usually bottlenecks for DBMSs Reliability Performance How about adopting multiple disks? More data can be held as opposed to one disk Data can be stored redundantly; hence, if one disk fails, data can be found on another Data can be accessed concurrently

Faloutsos CMU - 15-415/615 Many Disks vs. One Disk Although disks provide cheap, non-volatile storage for DBMSs, they are usually bottlenecks for DBMSs Reliability Performance How about adopting multiple disks? More data can be held as opposed to one disk Data can be stored redundantly; hence, if one disk fails, data can be found on another Data can be accessed concurrently Capacity! Reliability! Performance!

Reliability + Performance Faloutsos CMU - 15-415/615 Multiple Disks Discussions on: Reliability Performance Reliability + Performance

Logical Volume Managers (LVMs) Faloutsos CMU - 15-415/615 Logical Volume Managers (LVMs) But, disk addresses used within a file system are assumed to refer to one particular disk (or sub-disk) What about providing an abstraction that makes a number of disks appear as one disk? Disk LVM

Logical Volume Managers (LVMs) Faloutsos CMU - 15-415/615 Logical Volume Managers (LVMs) Disk LVM Disk What can LVMs do? Spanning: LVM transparently maps a larger address space to different disks Mirroring: Each disk can hold a separate, identical copy of data LVM directs writes to the same block address on each disk LVM directs a read to any disk (e.g., to the less busy one)

Logical Volume Managers (LVMs) Faloutsos CMU - 15-415/615 Logical Volume Managers (LVMs) Disk LVM Disk What can LVMs do? Spanning: LVM transparently maps a larger address space to different disks Mirroring: Each disk can hold a separate, identical copy of data LVM directs writes to the same block address on each disk LVM directs a read to any disk (e.g., to the less busy one) Mainly Provides Redundancy!

Reliability + Performance Faloutsos CMU - 15-415/615 Multiple Disks Discussions on: Reliability Performance Reliability + Performance

Faloutsos CMU - 15-415/615 Data Striping To achieve parallel accesses, we can use a technique called data striping Logical File 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Stripe Length = # of disks Striping Unit Disk 1 Disk 2 Disk 3 Disk 4 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15

Faloutsos CMU - 15-415/615 Data Striping To achieve parallel accesses, we can use a technique called data striping Client I: 512K write, offset 0 Client II: 512K write, offset 512 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 1 5 2 6 3 7 8 12 9 13 10 14 11 15 Disk 1 Disk 2 Disk 3 Disk 4 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15

Data Striping Disk 1 Disk 2 Disk 3 Disk 4 Stripe 1 Stripe 2 Stripe 3 Faloutsos CMU - 15-415/615 Data Striping Disk 1 Disk 2 Disk 3 Disk 4 Stripe 1 Unit 1 Unit 2 Unit 3 Unit 4 Stripe 2 Unit 5 Unit 6 Unit 7 Unit 8 Stripe 3 Unit 9 Unit 10 Unit 11 Unit 12 Stripe 4 Unit 13 Unit 14 Unit 15 Unit 16 Stripe 5 Unit 17 Unit 18 Unit 19 Unit 20 Each stripe is written across all disks at once Typically, a unit is either: A bit  Bit Interleaving A byte  Byte Interleaving A block  Block Interleaving

Striping Unit Values: Tradeoffs Faloutsos CMU - 15-415/615 Striping Unit Values: Tradeoffs Small striping unit values Higher parallelism (+) Smaller amount of data to transfer (+) Increased seek and rotational delays (-) Disk 1 Disk 2 Disk 3 Disk 4 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4

Striping Unit Values: Tradeoffs Faloutsos CMU - 15-415/615 Striping Unit Values: Tradeoffs Large striping unit values Lower parallelism (-) Larger amount of data to transfer (-) Decreased seek and rotational delays (+) A request can be handled completely on a separate disk! (- or +) But, multiple requests could be satisfied at once! (+) Disk 1 Disk 2 Disk 3 Disk 4 1 2 3 4

Striping Unit Values: Tradeoffs Faloutsos CMU - 15-415/615 Striping Unit Values: Tradeoffs Large striping unit values Lower parallelism Larger amount of data to transfer Decreased seek and rotational delays A request can be handled completely on a separate disk! But, multiple requests could be satisfied at once! Number of requests = Concurrency Factor Disk 1 Disk 2 Disk 3 Disk 4 1 2 3 4

Reliability + Performance Faloutsos CMU - 15-415/615 Multiple Disks Discussions on: Reliability Performance Reliability + Performance

Redundant Arrays of Independent Disks Faloutsos CMU - 15-415/615 Redundant Arrays of Independent Disks A system depending on N disks is much more likely to fail than one depending on one disk If the probability of one disk to fail is f Then, the probability of N disks to fail is (1-(1-f)N) How would we combine reliability with performance? Redundant Arrays of Inexpensive Disks (RAID) combines mirroring and striping Nowadays, Independent!

RAID Level 0 Data Striping RAID level 1: mirroring.

RAID Level 1 Data Mirroring RAID level 1: mirroring.

RAID Level 2 Bit Interleaving; ECC Data Data bits Check bits RAID level 2: bit interleaving with an error-correcting code (ECC). An example of ECC is hamming code, which can detect up to two-bit errors or correct one-bit errors without detection of uncorrected errors. By contrast, the simple parity code cannot correct errors, and can detect only an odd number of bits in error. Check bits

RAID Level 3 Bit Interleaving; Parity Data Data bits Parity bits RAID level 3: bit interleaving with parity bits. Parity bits

RAID Level 4 Block Interleaving; Parity Data Data blocks Parity blocks RAID level 4: block interleaving with parity blocks. Parity blocks

RAID Level 5 Block Interleaving; Parity Data Data and parity blocks RAID level 5: block interleaving with parity blocks. Rather than dedicating one disk to hold all the parity blocks, the parity blocks are distributed among all the disks. For stripe 1, the parity block might be on disk 1; for stripe 2 it would be on disk 2, and so forth. If we have eleven disks, then for stripe 11 the parity block would be back on disk 1.

RAID 4 vs. RAID 5 What if we have a lot of small writes? RAID 5 is the best What if we have mostly large writes? Multiples of stripes Either is fine What if we want to expand the number of disks? RAID 4: add a disk and re-compute parity RAID 5: add a disk, re-compute parity, and shuffle data blocks among all disks to reestablish the check-block pattern (expensive!)

Beyond Disks: Flash Flash memory is a relatively new technology providing the functionality needed to hold file systems and DBMSs It is writable It is readable Writing is slower than reading It is non-volatile Faster than disks, but slower than DRAMs Unlike disks, it provides random access Limited lifetime More expensive than disks

Outline Where Do DBMSs Store Data? Various Disk Organizations and Reliability and Performance Implications on DBMSs Disk Space Management

DBMS Layers Queries Query Optimization and Execution Relational Operators Transaction Manager Files and Access Methods Recovery Manager Buffer Management Lock Manager Disk Space Management DB

Disk Space Management DBMSs disk space managers Support the concept of a page as a unit of data Page size is usually chosen to be equal to the block size so that reading or writing a page can be done in 1 disk I/O Allocate/de-allocate pages as a contiguous sequence of blocks on disks Abstracts hardware (and possibly OS) details from higher DBMS levels

What to Keep Track of? The DBMS disk space manager keeps track of: Which disk blocks are in use Which pages are on which disk blocks Blocks can be initially allocated contiguously, but allocating and de-allocating blocks usually create “holes” Hence, a mechanism to keep track of free blocks is needed A list of free blocks can be maintained (storage could be an issue) Alternatively, a bitmap with one bit per each disk block can be maintained (more storage efficient and faster in identifying contiguous free areas!)

OS File Systems vs. DBMS Disk Space Managers Operating Systems already employ disk space managers using their “file” abstraction “Read byte i of file f”  “read block m of track t of cylinder c of disk d” DBMSs disk space managers usually pursue their own disk management without relying on OS file systems Enables portability Can address larger amounts of data Allows spanning and mirroring

Next Class Queries Query Optimization and Execution Buffer Management and Parts of Files and Access Methods Relational Operators Transaction Manager Files and Access Methods Recovery Manager Buffer Management Lock Manager Disk Space Management DB