CS 245: Database System Principles Notes 03: Disk Organization - - PowerPoint PPT Presentation

▶
cs 245 database system
SMART_READER_LITE
LIVE PREVIEW

CS 245: Database System Principles Notes 03: Disk Organization - - PowerPoint PPT Presentation

May 29, 2023 985 likes •1.8k views

CS 245: Database System Principles Notes 03: Disk Organization Hector Garcia-Molina CS 245 Notes 3 1 Topics for today How to lay out data on disk How to move it to memory CS 245 Notes 3 2 What are the data items we want to store?

slide-1
SLIDE 1

CS 245 Notes 3 1

CS 245: Database System Principles

Notes 03: Disk Organization

Hector Garcia-Molina

slide-2
SLIDE 2

CS 245 Notes 3 2

  • How to lay out data on disk
  • How to move it to memory

Topics for today

slide-3
SLIDE 3

CS 245 Notes 3 3

What are the data items we want to store?

  • a salary
  • a name
  • a date
  • a picture
slide-4
SLIDE 4

CS 245 Notes 3 4

What are the data items we want to store?

  • a salary
  • a name
  • a date
  • a picture

What we have available: Bytes

8 bits

slide-5
SLIDE 5

CS 245 Notes 3 5

To represent:

  • Integer (short): 2 bytes

e.g., 35 is 00000000 00100011

  • Real, floating point

n bits for mantissa, m for exponent….

slide-6
SLIDE 6

CS 245 Notes 3 6

  • Characters

 various coding schemes suggested,

most popular is ascii

To represent:

Example: A: 1000001 a: 1100001 5: 0110101 LF: 0001010

slide-7
SLIDE 7

CS 245 Notes 3 7

  • Boolean

e.g., TRUE FALSE

1111 1111 0000 0000

To represent:

  • Application specific

e.g., RED  1 GREEN  3 BLUE  2 YELLOW  4 …

slide-8
SLIDE 8

CS 245 Notes 3 8

  • Boolean

e.g., TRUE FALSE

1111 1111 0000 0000

To represent:

  • Application specific

e.g., RED  1 GREEN  3 BLUE  2 YELLOW  4 … Can we use less than 1 byte/code?

Yes, but only if desperate...

slide-9
SLIDE 9

CS 245 Notes 3 9

  • Dates

e.g.: - Integer, # days since Jan 1, 1900

  • 8 characters, YYYYMMDD
  • 7 characters, YYYYDDD

(not YYMMDD! Why?)

  • Time

e.g. - Integer, seconds since midnight

  • characters, HHMMSSFF

To represent:

slide-10
SLIDE 10

CS 245 Notes 3 10

  • String of characters

– Null terminated e.g., – Length given e.g.,

  • Fixed length

c t a c t a 3

To represent:

slide-11
SLIDE 11

CS 245 Notes 3 11

  • Bag of bits

Length Bits

To represent:

slide-12
SLIDE 12

CS 245 Notes 3 12

Key Point

  • Fixed length items
  • Variable length items
  • usually length given at beginning
slide-13
SLIDE 13

CS 245 Notes 3 13

  • Type of an item: Tells us how to

interpret (plus size if fixed)

Also

slide-14
SLIDE 14

CS 245 Notes 3 14

Data Items Records Blocks Files Memory

Overview

slide-15
SLIDE 15

CS 245 Notes 3 15

Record - Collection of related data items (called FIELDS)

E.g.: Employee record: name field, salary field, date-of-hire field, ...

slide-16
SLIDE 16

CS 245 Notes 3 16

Types of records:

  • Main choices:

– FIXED vs VARIABLE FORMAT – FIXED vs VARIABLE LENGTH

slide-17
SLIDE 17

CS 245 Notes 3 17

A SCHEMA (not record) contains following information

  • # fields
  • type of each field
  • order in record
  • meaning of each field

Fixed format

slide-18
SLIDE 18

CS 245 Notes 3 18

Example: fixed format and length

Employee record (1) E#, 2 byte integer (2) E.name, 10 char. Schema (3) Dept, 2 byte code

55 s m i t h 02 83 j o n e s 01

Records

slide-19
SLIDE 19

CS 245 Notes 3 19

  • Record itself contains format

“Self Describing”

Variable format

slide-20
SLIDE 20

CS 245 Notes 3 20

Example: variable format and length

4 I 5 2 4 S D R O F 46 Field name codes could also be strings, i.e. TAGS # Fields Code identifying field as E# Integer type Code for Ename String type Length of str.

slide-21
SLIDE 21

CS 245 Notes 3 21

Variable format useful for:

  • “sparse” records
  • repeating fields
  • evolving formats

But may waste space...

slide-22
SLIDE 22

CS 245 Notes 3 22

  • EXAMPLE: var format record with

repeating fields Employee  one or more  children

3 E_name: Fred Child: Sally Child: Tom

slide-23
SLIDE 23

CS 245 Notes 3 23

Note: Repeating fields does not imply

  • variable format, nor
  • variable size

John Sailing Chess

slide-24
SLIDE 24

CS 245 Notes 3 24

Note: Repeating fields does not imply

  • variable format, nor
  • variable size

John Sailing Chess

  • Key is to allocate maximum number of

repeating fields (if not used  null)

slide-25
SLIDE 25

CS 245 Notes 3 25

Many variants between fixed - variable format:

Example: Include record type in record

record type record length tells me what to expect (i.e. points to schema) 5 27 . . . .

slide-26
SLIDE 26

CS 245 Notes 3 26

Record header - data at beginning that describes record

May contain:

  • record type
  • record length
  • time stamp
  • other stuff ...
slide-27
SLIDE 27

CS 245 Notes 3 27

Next: placing records into blocks

blocks ... a file

slide-28
SLIDE 28

CS 245 Notes 3 28

Next: placing records into blocks

blocks ... a file

assume fixed length blocks assume a single file (for now)

slide-29
SLIDE 29

CS 245 Notes 3 29

(1) separating records (2) spanned vs. unspanned (3) sequencing (4) indirection

Options for storing records in blocks:

slide-30
SLIDE 30

CS 245 Notes 3 30

Block

(a) no need to separate - fixed size recs. (b) Separate using special marker (c) Separate using record lengths (or offsets)

  • within each record
  • in block header

(1) Separating records

R2 R1 R3

slide-31
SLIDE 31

CS 245 Notes 3 31

  • Unspanned: records must be within one

block

block 1 block 2

...

  • Spanned

block 1 block 2 ...

(2) Spanned vs. Unspanned

R1 R2 R1 R3 R4 R5 R2

R3 (a) R3 (b)

R6 R5 R4

R7 (a)

slide-32
SLIDE 32

CS 245 Notes 3 32

need indication need indication

  • f partial record
  • f continuation

“pointer” to rest (+ from where?)

  • f the record

R1 R2

R3 (a) R3 (b)

R6 R5 R4

R7 (a)

With spanned records:

slide-33
SLIDE 33

CS 245 Notes 3 33

  • Unspanned is much simpler, but may

waste space…

  • Spanned essential if

record size > block size Spanned vs. unspanned:

slide-34
SLIDE 34

CS 245 Notes 3 34

  • Ordering records in file (and block) by

some key value Sequential file (  sequenced)

(3) Sequencing

slide-35
SLIDE 35

CS 245 Notes 3 35

Why sequencing?

Typically to make it possible to efficiently read records in order (e.g., to do a merge-join — discussed later)

slide-36
SLIDE 36

CS 245 Notes 3 36

Sequencing Options

(a) Next record physically contiguous ... (b) Linked

Next (R1) R1 R1 Next (R1)

slide-37
SLIDE 37

CS 245 Notes 3 37

(c) Overflow area Records in sequence

R1 R2 R3 R4 R5

Sequencing Options

slide-38
SLIDE 38

CS 245 Notes 3 38

(c) Overflow area Records in sequence

R1 R2 R3 R4 R5

Sequencing Options

header R2.1 R1.3 R4.7

slide-39
SLIDE 39

CS 245 Notes 3 39

  • How does one refer to records?

(4) Indirection

Rx

slide-40
SLIDE 40

CS 245 Notes 3 40

  • How does one refer to records?

(4) Indirection

Rx

Many options: Physical Indirect

slide-41
SLIDE 41

CS 245 Notes 3 41

Purely Physical

Device ID E.g., Record Cylinder # Address = Track #

  • r ID

Block # Offset in block

Block ID

slide-42
SLIDE 42

CS 245 Notes 3 42

Fully Indirect

E.g., Record ID is arbitrary bit string map rec ID r address a

Physical addr. Rec ID

slide-43
SLIDE 43

CS 245 Notes 3 43

Tradeoff

Flexibility Cost

to move records

  • f indirection

(for deletions, insertions)

slide-44
SLIDE 44

CS 245 Notes 3 44

Physical Indirect

Many options in between …

slide-45
SLIDE 45

CS 245 Notes 3 45

Example: Indirection in block

Header A block: Free space

R3 R4 R1 R2

slide-46
SLIDE 46

CS 245 Notes 3 46

Block header - data at beginning that describes block

May contain:

  • File ID (or RELATION or DB ID)
  • This block ID
  • Record directory
  • Pointer to free space
  • Type of block (e.g. contains recs type 4;

is overflow, …)

  • Pointer to other blocks “like it”
  • Timestamp ...
slide-47
SLIDE 47

CS 245 Notes 3 47

(1) separating records (2) spanned vs. unspanned (3) sequencing (4) indirection

Options for storing records in blocks:

slide-48
SLIDE 48

CS 245 Notes 3 48

Case Study: salesforce.com

  • salesforce.com provides CRM services
  • salesforce customers are tenants
  • Tenants run apps and DBMS as service

tenant A tenant B tenant C salesforce.com data CRM App

slide-49
SLIDE 49

CS 245 Notes 3 49

Options for Hosting

  • Separate DBMS per tenant
  • One DBMS, separate tables per tenant
  • One DBMS, shared tables
slide-50
SLIDE 50

CS 245 Notes 3 50

Tenants have similar data

customer A B C D E F a1 b1 c1 d1 e1 - a2 b2 c2 - e2 f2 customer A B C D G a3 b3 c2 - - a1 b1 c1 - g1 a4 - - d1 tenant 1: tenant 2:

slide-51
SLIDE 51

CS 245 Notes 3 51

salesforce.com solution

customer tenant A B C 1 a1 b1 c1 1 a2 b2 c2 2 a3 b3 c2 2 a1 b1 c1 cust-other tenant A f1 v1 f2 v2 ... 1 a1 D d1 E e1 1 a2 E e2 F f2 2 a1 G g1 3 a4 D d1 fixed schema for all tenants var schema for all tenants

slide-52
SLIDE 52

CS 245 Notes 3 52

(1) Insertion/Deletion (2) Buffer Management (3) Comparison of Schemes

Other Topics

slide-53
SLIDE 53

CS 245 Notes 3 53

Block

Deletion

Rx

slide-54
SLIDE 54

CS 245 Notes 3 54

Options:

(a) Immediately reclaim space (b) Mark deleted

slide-55
SLIDE 55

CS 245 Notes 3 55

Options:

(a) Immediately reclaim space (b) Mark deleted

– May need chain of deleted records

(for re-use)

– Need a way to mark:

  • special characters
  • delete field
  • in map
slide-56
SLIDE 56

CS 245 Notes 3 56

As usual, many tradeoffs...

  • How expensive is to move valid record

to free space for immediate reclaim?

  • How much space is wasted?

– e.g., deleted records, delete fields, free space chains,...

slide-57
SLIDE 57

CS 245 Notes 3 57

Dangling pointers

Concern with deletions

R1 ?

slide-58
SLIDE 58

CS 245 Notes 3 58

Solution #1: Do not worry

slide-59
SLIDE 59

CS 245 Notes 3 59

E.g., Leave “MARK” in map or old location

Solution #2: Tombstones

slide-60
SLIDE 60

CS 245 Notes 3 60

E.g., Leave “MARK” in map or old location

Solution #2: Tombstones

  • Physical IDs

A block This space This space can never re-used be re-used

slide-61
SLIDE 61

CS 245 Notes 3 61

  • Logical IDs

ID LOC 7788 map Never reuse ID 7788 nor space in map...

E.g., Leave “MARK” in map or old location

Solution #2: Tombstones

slide-62
SLIDE 62

CS 245 Notes 3 62

Easy case: records not in sequence  Insert new record at end of file or in deleted slot  If records are variable size, not as easy...

Insert

slide-63
SLIDE 63

CS 245 Notes 3 63

Hard case: records in sequence  If free space “close by”, not too bad...  Or use overflow idea...

Insert

slide-64
SLIDE 64

CS 245 Notes 3 64

Interesting problems:

  • How much free space to leave in each

block, track, cylinder?

  • How often do I reorganize file + overflow?
slide-65
SLIDE 65

CS 245 Notes 3 65

Free space

slide-66
SLIDE 66

CS 245 Notes 3 66

  • DB features needed
  • Why LRU may be bad Read
  • Pinned blocks

Textbook!

  • Forced output
  • Double buffering
  • Swizzling

Buffer Management

in Notes02

slide-67
SLIDE 67

CS 245 Notes 3 67

Swizzling

Memory Disk

Rec A

block 1 block 2 block 1

slide-68
SLIDE 68

CS 245 Notes 3 68

Swizzling

Memory Disk

Rec A

block 1

Rec A

block 2 block 2 block 1

slide-69
SLIDE 69

CS 245 Notes 3 69

Row vs Column Store

  • So far we assumed that fields of a

record are stored contiguously (row store)...

  • Another option is to store like fields

together (column store)

slide-70
SLIDE 70

CS 245 Notes 3 70

  • Example: Order consists of

– id, cust, prod, store, price, date, qty

Row Store

id1 cust1 prod1 store1 price1 date1 qty1 id2 cust2 prod2 store2 price2 date2 qty2 id3 cust3 prod3 store3 price3 date3 qty3

slide-71
SLIDE 71

CS 245 Notes 3 71

  • Example: Order consists of

– id, cust, prod, store, price, date, qty

Column Store

id1 cust1 id2 cust2 id3 cust3 id4 cust4 ... ... id1 prod1 id2 prod2 id3 prod3 id4 prod4 ... ... id1 price1 qty1 id2 price2 qty2 id3 price3 qty3 id4 price4 qty4 ... ... ...

ids may or may not be stored explicitly

slide-72
SLIDE 72

CS 245 Notes 3 72

Row vs Column Store

  • Advantages of Column Store

– more compact storage (fields need not start at byte boundaries) – efficient reads on data mining operations

  • Advantages of Row Store

– writes (multiple fields of one record)more efficient – efficient reads for record access (OLTP)

slide-73
SLIDE 73

CS 245 Notes 3 73

Interesting paper to read:

  • Mike Stonebreaker, Elizabeth (Betty)

O'Neil, Pat O’Neil, Xuedong Chen, et al. " C-Store: A Column-oriented DBMS," Presented at the 31st VLDB Conference, September 2005.

  • http://www.cs.umb.edu/%7Eponeil/

vldb05_cstore.pdf

slide-74
SLIDE 74

CS 245 Notes 3 74

  • There are 10,000,000 ways to organize

my data on disk… Which is right for me?

Comparison

slide-75
SLIDE 75

CS 245 Notes 3 75

Issues:

Flexibility Space Utilization Complexity Performance

slide-76
SLIDE 76

CS 245 Notes 3 76

To evaluate a given strategy, compute following parameters:

  • > space used for expected data
  • > expected time to
  • fetch record given key
  • fetch record with next key
  • insert record
  • append record
  • delete record
  • update record
  • read all file
  • reorganize file
slide-77
SLIDE 77

CS 245 Notes 3 77

Example

How would you design Megatron 3000 storage system? (for a relational DB, low end)

– Variable length records? – Spanned? – What data types? – Fixed format? – Record IDs ? – Sequencing? – How to handle deletions?

slide-78
SLIDE 78

CS 245 Notes 3 78

  • How to lay out data on disk

Data Items Records Blocks Files Memory DBMS

Summary

slide-79
SLIDE 79

CS 245 Notes 3 79

How to find a record quickly, given a key

Next