Storage Management - Lecture 8 - Introduction to Databases (WE-DINF-9552)

2 December 2005Introduction to DatabasesStorage ManagementProf. Beat SignerDepartment of Computer ScienceVrije Universiteit Brusselhttp://www.beatsigner.com

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 2April 19, 2013Context of Todays LectureAccessMethodsSystemBuffersAuthorisationControlIntegrityCheckerCommandProcessorProgramObject CodeDDLCompilerFileManagerBufferManagerRecoveryManagerSchedulerQueryOptimiserTransactionManagerQueryCompilerQueriesCatalogueManagerDMLPreprocessorDatabaseSchemaApplicationProgramsDatabaseManagerDataManagerDBMSProgrammers Users DB AdminsBased on Components of a DBMS, Database Systems,T. Connolly and C. Begg, Addison-Wesley 2010Data, Indices andSystem Catalogue

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 3April 19, 2013Storage Device Hierarchy Storage devices vary in data capacity access speed cost per byte Devices with fastestaccess time havehighest costs andsmallest capacityCacheMain MemoryFlash MemoryMagnetic DiskOptical DiskMagnetic Tapes

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 4April 19, 2013Cache On-board cache on the same chip as the microprocessor level 1 (L1) cache temporary storage of instructions and data typical size of ~64 kB Extra cache levels located on separate chips e.g. level 2 (L2) cache typical size of ~1 MB Data items in the cache are copies of values in mainmemory locations If data in the cache has been updated, changes must bereflected in the corresponding memory locations

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 5April 19, 2013Main Memory Main memory can be several gigabytes large Normally too small and too expensive for storing theentire database content is lost during power failure or crash (volatile memory) in-memory databases (IMDB) primarily rely on main memory- note that IMDBs lack durability (D of the ACID properties) IMDB size limited by the maximal addressable memory space- e.g. maximal 4 GB for 32-bit address space Random access memory (RAM) time to access data is more or less independent of its location(different from magnetic tapes) Typical access time of ~10 nanoseconds (10-8 seconds)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 6April 19, 2013Secondary Storage (Hard Disk) Essentially random access Files are moved between a hard disk and main memory(disk I/O) by the operating system (OS) or the DBMS the transfer units are blocks tendency for larger block sizes Parts of the main memory are used to buffer blocks the buffer manager of the DBMS manages the loading andunloading of blocks for specific DBMS operations Typical block I/O time (seek time) ~10 milliseconds 1000000 times slower than main memory access Capacity of several hundred gigabytes and a system canuse many disk units

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 7April 19, 2013Hard Disk A hard disk contains oneor more platters and one ormore heads The platters were originallyaddressed in terms of cylinders,heads and sectors (block) cylinder-head-sector (CHS) scheme max of 1024 cylinders, 16 headsand 63 sectors Current hard disks offerlogical block addressing (LBA) hides the physical disk geometry

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 8April 19, 2013Solid-State Drives (SSD) Storage device that uses solid-state memory(flash memory) to persistently store data Offers a hard disk interface with a storage capacity of upto a few hundred gigabytes Typical block I/O time (seek time) ~0.1 milliseconds SSDs might help to reduce the gap between primary andsecondary storage in DBMS systems Currently there are still some limitations of SSDs the limited number of SSD write operations before failure can be aproblem for DBs with a lot of update operations write operations are often still much slower than read operations

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 9April 19, 2013Tertiary Storage No random access access time depends ondata location Different devices tapes optical disk jukeboxes- racks of CD-ROMs (read only) tape silos- room-sized devices holdingracks of tapes operated bytape robots- e.g. StorageTek PowderHornwith up to 28.8 petabytes

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 10April 19, 2013Models of Computation RAM model of computation assumes that all data is held in main memory DBMS model of computation assumes that data does not fit into main memory efficient algorithms must take into account secondary and eventertiary storage best algorithms for processing large amounts of data often differfrom those for the RAM model of computation minimising disk accesses plays a major role- I/O model of computation I/O model of computation the time to move a block between disk and memory is muchhigher than the time for the corresponding computation

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 11April 19, 2013Accelerating Secondary Storage Access Various possible strategies to improve secondarystorage access placement of blocks that are often accessed together on the samedisk cylinder distribute data across multiple disks to profit from parallel diskaccesses (e.g. RAID) mirroring of data use of disk scheduling algorithms in OS, DBMS or disk controllerto determine order of requested block read/writes- e.g. elevator algorithm prefetching of disk blocks efficient caching- main memory- disk controllers

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 12April 19, 2013Redundant Array of Independent Disks The redundant array of independent disks (RAID)organisation technique provides a single disk view for anumber (array) of disks divide and replicate data across multiple hard disks introduced in 1987 by D.A. Patterson, G.A. Gibson and R. Katz The main goals of a RAID solution are higher capacity by grouping multiple disks- originally a RAID was also a cheaper alternative to expensive large disks• original name: Redundant Array of Inexpensive Disks higher performance due to parallel disk access- multiple parallel read/write operations increased reliability since data might be stored redundantly- data can be restored if a disk fails

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 13April 19, 2013RAID ... There are three main concepts in RAID systems identical data is written to more than one disk (mirroring) data is split accross multiple disks (striping) redundant parity data is stored on separated disks and used todetect and fix problems (error correction)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 14April 19, 2013RAID Reliability The mean time between failures (MTBF) is the averagetime until a disk failure occurs e.g. a hard disk might have a MTBF of 200000 hours (22.8 years)- note that the MTBF decreases as disks get older If a DBMS uses an array of disks, then the overallsystems MTBF can be much lower e.g. the MTBF for a disk array of 100 of the disks mentionedabove is 200000 hours/100 = 2000 hours (83 days) By storing information redundantly, data can be restoredin the case of a disk failure

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 15April 19, 2013RAID Reliability ... The mean time to data loss (MTTDL) depends on theMTBF and the mean time to repair if we mirror the information on two disks with a MTBF of 200000hours and a mean time to repair of 10 hours then the MTTDL is2000002/(2*10) hours = 228000 years of course in reality it is more likely that an error occurs on multipledisks around the same time- drives have the same age- power failure, earthquake, fire, ...

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 16April 19, 2013RAID Levels The different RAID levels offer differentcost-performance trade-offs RAID 0 block level striping without any redundancy RAID 1 mirroring without striping RAID 2 bit level striping multiple parity disks RAID 3 byte level striping one parity disk[http://en.wikipedia.org/wiki/RAID]

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 17April 19, 2013RAID Levels ... RAID 4 block level striping one parity disk similar to RAID 3 RAID 5 block level striping with distributed parity no dedicted parity disk RAID 6 block level striping with dualdistributed parity no dedicted parity disk similar to RAID 5

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 18April 19, 2013Data Representation A DBMS has to define how the elements of its data model(e.g. relational model) are mapped to secondary storage a field contains a fixed- or variable-length sequence of bytes andrepresents an attribute a record contains a fixed- or variable-length sequence of fields andrepresents a tuple records are stored in fixed-length physical block storage unitsrepresenting a set of tuples- the blocks also represent the units of data transfer a file contains a collection of blocks and represents a relation A database is finally mapped to a number of filesmanaged by the underlying operating system index structures are stored in separate files

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 19April 19, 2013Relational Model Representation A number of issues have to be addressed whenmapping the basic elements of the relational modelto secondary storage how to map the SQL datatypes to fields? how to represent tuples as records? how to represent records in blocks? how to represent a relation as a collection of blocks? how to deal with record sizes that do not fit into blocks? how to deal with variable-length records? how to deal with schema updates and growing record lengths? ...

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 20April 19, 2013Representation of SQL Datatypes Fixed-length character string (CHAR(n)) represented as a field which is an array of n bytes strings that are shorter than n bytes are filled up with a special"pad" character Variable-length character string (VARCHAR(n)) two common representations (non-fixed length version later) length plus content- allocate an array of n + 1 bytes- the first byte represents the length of the string (8-bit integer) followed by thestring content- limited to a maximal string length of 255 characters null-terminated string- allocate an array of n + 1 bytes- terminate the string with a special null character (like in C)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 21April 19, 2013Representation of SQL Datatypes ... Dates (DATE) fixed-length character string Time (TIME(n)) the precision n leads to strings of variable length and two possiblerepresentations fixed-precision- limit the precision to a fixed value and store as VARCHAR(m) true-variable length- store the time as true variable length value Bits (BIT(n)) bit values of size n can be packed into single bytes packing of multiple bit values into a single byte is not recommended- makes the retrieval and updating of a value more complex and error-prone

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 22April 19, 2013Storage Access A part of the systems main memory is used as a bufferto store copies of disk blocks The buffer manager is responsible to move data fromsecondary disk storage into memory the number of block transfers between disk and memory shouldbe minimised as many blocks a possible should be kept in memory The buffer manager is called by the DMBS every time adisk block has to be accessed the buffer manager has to check whether the block is alreadyallocated in the buffer (main memory)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 23April 19, 2013Buffer Manager If the requested block is already in the buffer, the buffermanager returns the corresponding address If the block is not yet in the buffer, the buffer managerperforms the following steps allocate buffer space- if no space is available, remove an existing block from the buffer(based on a buffer replacement strategy) and write it back to the disk if it hasbeen modified since it was last fetched/written to disk read the block from the disk, add it to the buffer and return thecorresponding memory address Note the similarities to a virtual memory manager

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 24April 19, 2013Buffer Replacement Strategies Most operating systems use a least recently used (LRU)strategy where the block that was least recently used ismoved back from memory to disk use past access pattern to predict future block access A DBMS is able to predict future access patterns moreaccurately than an operating system a request to the DBMS involves multiple steps and the DBMSmight be able to determine which blocks will be needed byanalysing the different steps of the operation note that LRU might not always be the best replacement strategyfor a DBMS

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 25April 19, 2013Buffer Replacement Strategies ... Let us have a look at the procedure to compute thefollowing natural join query: order ⋈ customer note that we will see more efficient solutions for this problemwhen discussing query optimisationfor each tuple o of order {for each tuple c of customer {if o.customerID = c.customerID {create a new tuple r with:r.customerID := c.customerIDr.name := c.name...r.orderID := o.orderID...add tuple r to the result set of the join operation}}}

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 26April 19, 2013Buffer Replacement Strategies ... We further assume that the two relations order andcustomer are stored in separate files From the pseudocode we can see that once an order tuple has been processed, it is not neededanymore- if a whole block of order tuples has been processed, that block is no longerrequired in memory (but an LRU strategy might keep it)- as soon as the last tuple of an order block has been processed, the buffermanager should free the memory space  toss-immediate strategy once a customer tuple has been processed, it is not accessedagain until all the other customer tuples have been accessed- when the processing of a customer block has been finished, the least recentlyused customer block will be requested next- we should replace the block that has been most recently used (MRU)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 27April 19, 2013Buffer Replacement Strategies ... A memory block can be marked to indicate that this blockis not allowed to be written back to disk (pinned block) note that if we want to use an MRU strategy for the inner loop ofthe previous example, the block has to be pinned- the block has to be unpinned after the last tuple in the block has be processed the pinning of blocks provides some control to restrict the timewhen blocks can be written back to disk- important for crash recovery- blocks that are currently updated should not be written to disk The prefetching of blocks might be used to furtherincrease the performance of the overall system e.g. for serial scans (relation scans)

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 28April 19, 2013Buffer Replacement Strategies ... The buffer manager can also use statistical informationabout the probability that a request will reference aparticular relation (and its related blocks) the system catalogue (data dictionary) with its metadata is one ofthe most frequently accessed parts of the database- if possible, system catalogue blocks should always be in the buffer index files might be accessed more often than the correspondingfiles themselves- do not remove index files from the buffer if not necessary the crash recovery manager can also provide constraints for thebuffer manager- the recovery manager might demand that other blocks have to be written first(force-output) before a specific block can be written to disk

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 29April 19, 2013System Catalogue / Data Dictionary Stores metadata about the database names of the relations names, domain and lengths of the attributes of each relation names of views names of indices- name of relation that is indexed- name of attributes- type of index integrity constraints users and their authorisations statistical data- number of tuples in relation, storage method, ... ...

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 30April 19, 2013File Organisation A file is a logically organised as a sequence of records each record contains a sequence of fields name, datatype and offset of record fields are defined bythe schema record types (schema) might change over time The records are mapped to disk blocks the block size is fixed and defined by the physical properties ofthe disk and the operating system the record size might vary for different relations and evenbetween tuples of the same relation (variable field size) There are different possible mappings of records to files use multiple files and only store fixed-length records in each file store variable-length records in a file

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 31April 19, 2013Fixed-Length Records If we assume that an integer requires 2 bytes andcharacters are represented by one byte, then thecustomer record is 64 bytes longtype customer = recordcID int;name varchar(30)street varchar(30)endcID name street... ...0 2 33 64Block

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 32April 19, 2013Fixed-Length Records ... It might be necessary to ensure that data elements beginat an offset that is a multiple of 4 (8 for 64-bit processors) the first byte of a block loaded from disk is placed at a memoryaddress that is a multiple of 4 we have to ensure that we have the appropriate offsets(e.g. dividable by 4)cID name street... ...0 4 36 68Block

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 33April 19, 2013Fixed-Length Records ... Often a record header is added to each record formanaging metadata about the record schema (pointer s to the DBMS schema information) timestamp t about the last access or modification time the length l of the record- could be computed from the schema but the information is convenient if wewant to quickly access the next record without having to consult the schema ...0 12 48 80cID name street... ...s t l16Block

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 34April 19, 2013Fixed-Length Records in Blocks/Files Problems with this fixed length representation after a record has been deleted, its space has to be filled withanother record- could move all records after the deleted one but that is too expensive- can move the last record to the deleted records position but also that mightrequire an additional block access if the block size is not a multiple of the record size, some recordswill cross block boundaries and we need two block accesses toread/write such a record1 Max Frisch Bahnhofstrasse 7h2 Eddy Merckx Pleinlaan 25h5 Claude Debussy 12 Rue Louiseh53 Albert Einstein Bergstrasse 18h8 Max Frisch ETH Zentrumhrecord 0record 1record 2record 3record 4

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 35April 19, 2013Fixed-Length Records in Blocks/Files ... Since insert operations tend to be more frequent thatdelete operations, it might be acceptable to leave thespace of the deleted record open until a new record isinserted we cannot just add an additional boolean flag ("free") to therecord since it will be hard to find the free records allocate a certain amount of bytes for a file header containingmetadata about the file The block/file header contains a pointer (address) to thefirst deleted record each deleted record contains a pointer (address) to the nextdeleted record the linked list of deleted records is called a free list

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 36April 19, 2013record 0record 1record 2record 3record 4headerFixed-Length Records in Blocks/Files ... To insert a new record, the first free record pointed to bythe header is used and the address in the header isupdated to the free record that the used record waspointing to to save some space, the pointers of the free list can also bestored in the unused space of deleted records (no additional field)1 Max Frisch Bahnhofstrasse 7h5 Claude Debussy 12 Rue Louiseh8 Max Frisch ETH Zentrumh

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 37April 19, 2013Address Space There are several ways how the database addressspace (blocks and block offsets) can be represented physical addresses consisting of byte strings (up to 16 bytes)that address- host- storage device identifier (e.g. hard disk ID)- cylinder number of the disk- track within the cylinder (for multi-surface disks)- block within the track- potential offset of record within the block logical addresses consisting of an arbitrary string of length n

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 38April 19, 2013Address Space Mapping A map table is stored at a known disk location andprovides a mapping between the logical and physicaladdress spaces introduces some indirection since the map table has to beconsulted to get the physical address flexibility to rearrange records within blocks or move them to otherblocks without affecting the records logical address different combinations of logical and physical addresses arepossible (structured address schemes)... ...logical physicallogicaladdressphysicaladdressmap table

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 39April 19, 2013Variable-Length Data Records of the same type may have different lengths We may want to represent record fields with varying size (e.g. VARCHAR(n)) large fields (e.g. images) ... We need an alternative data representation to deal withthese requirements

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 40April 19, 2013Variable-Length Record Fields Scheme for records with variable-length fields put all fixed-length fields first (e.g. cID) add the length of the record to the record header add the offsets of the variable-length fields to the record header Note that if the order of the variable-length fields isalways the same, we do not have to store an offset forthe first variable-length field (e.g. name)cID name streetrecord length

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 41April 19, 2013Variable-Length Records There are different reasons why we might have to usevariable-length records to store records that have at least one field with a variable length to store different record types in a single block/file Structured address scheme (slotted-page structure) address of a record consists of the block address in combinationwith an offset table index records can be moved aroundrecord3 record2 record1... free ...offset table

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 42April 19, 2013Large Records Sometimes we have to deal with values that do not fitinto a single block (e.g. audio or movie clips) a record that is split across two or more blocks is calleda spanned record spanned records can also be used to pack blocks more efficiently Extra header information each record header carries a bit to indicate if it is a fragment- fragments have some more bits; telling whether first or last fragment of record potential pointers to previous and next fragmentblock headerrecord headerrecord2b record3record2arecord1block 1 block 2

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 43April 19, 2013Storage of Binary Large Objects (BLOBS) BLOB is stored as a sequence of blocks often blocks allocated successively on a disk cylinder BLOB might be striped across multiple disks for moreefficient retrieval BLOB field might not be automatically fetched intomemory user has to explicitly load parts of the BLOB possibly index structures to retrieve parts of a BLOB

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 44April 19, 2013Insertion of Records If the records are not kept in a particular order, we canjust find a block with some empty space or create a newblock if there is no such space If the record has to be inserted in a particular order, butthere is no space in the block, there are two alternatives find space in a nearby block and rearrange some records create an overflow block and link it from the header of the originalblock- note that an overflow block might point to another overflow block and so onrecord3 record2 record1... free ...offset table

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 45April 19, 2013Deletion of Records If we use an offset table, we may compact the free spacein the block (slide around the records) If the records cannot be moved, we might have a free listin the header We might also be able to remove an overflow block aftera delete operationrecord3 record2 record1... free ...offset table

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 46April 19, 2013Update of Records If we have to update a fixed-length record there is noproblem since we will still use the same space If the updated record is larger than the original version,then we might have to create more space same options as discussed for insert operation If the updated record is smaller, then we may compactsome free space or remove overflow blocks similar to delete operationrecord3 record2 record1... free ...offset table

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 47April 19, 2013Homework Study the following chapter of theDatabase System Concepts book chapter 10- sections 10.1-10.9- Storage and File Structure

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 48April 19, 2013Exercise 8 Structured Query Language (SQL) PostgreSQL

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 49April 19, 2013References H. Garcia-Molina, J.D. Ullman and J. Widom,Database Systems – The Complete Book,Prentice Hall, 2002 A. Silberschatz, H. Korth and S. Sudarshan, DatabaseSystem Concepts (Sixth Edition), McGraw-Hill, 2010

2 December 2005Next LectureAccess Methods

http://www.slideshare.net	10
http://www.inf.ethz.ch	7
http://wise.vub.ac.be	5

Storage Management - Lecture 8 - Introduction to Databases (WE-DINF-9552)

by Beat Signer on Apr 01, 2010

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 22

Statistics

Storage Management - Lecture 8 - Introduction to Databases (WE-DINF-9552) Presentation Transcript