1 / 7

Secondary Storage

Secondary Storage. Rough Speed Differentials nanoseconds: retrieve data in main memory microseconds: retrieve from under a read head milliseconds: retrieve from elsewhere on disk Approximate Disk Speeds seek (head move): 8 milliseconds rotational latency (spin under): 4 milliseconds

oneida
Télécharger la présentation

Secondary Storage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secondary Storage • Rough Speed Differentials • nanoseconds: retrieve data in main memory • microseconds: retrieve from under a read head • milliseconds: retrieve from elsewhere on disk • Approximate Disk Speeds • seek (head move): 8 milliseconds • rotational latency (spin under): 4 milliseconds • block transfer: 68 microseconds (negligible) • total: 12.068 – about 12 milliseconds • Implications • cluster data on cylinders • make good use of caches

  2. Sequential Files • Operations • Add: write over a deleted record or after last record • Delete: mark deleted • Access: read until record found (half the file, on average) • Sorted (doesn’t help much without an index) • Access: • sequential (can be contiguous or non-contiguous) • binary search is usually worse • Add: can be expensive to maintain sort order • Delete: mark deleted

  3. Indexes Primary (Key) Index Guest(GuestNr Name StreetNr City) 1 101 Smith 12 Maple Boston 102 Carter 10 Main Hartford . . . 2 123 Jones 20 Main Boston . . . 144 Hansen 12 Oak Boston 25 763 Black 15 Elm Hartford 764 Barnes 45 Oak Boston Block#/Offset ---------------- 101 1,0 102 1,1 . . . 123 2,0 . . . Block# ----------- 101 1 123 2 . . . 763 25 Secondary (Key) Index <Smith, 12 Maple, Boston> 1 <Carter, 10 Main, Hartford> 1 . . . <Jones, 20 Main, Boston> 2 . . . Secondary (Nonkey) Index Boston 1, 2, . . ., 25 Hartford 1, . . ., 25 Dense & Sparse Indexes

  4. Indexed Sequential File 1. Sorted on primary key 2. Sparse index 3. Overflow buckets Index ----------- 101 1 123 2 . . . 763 25 Guest(GuestNr Name StreetNr City) 1 101 Smith 12 Maple Boston 102 Carter 10 Main Hartford . . . 2 123 Jones 20 Main Boston . . . 144 Hansen 12 Oak Boston 25 763 Black 15 Elm Hartford 764 Barnes 45 Oak Boston Operations: Access Delete Insert 146 Green 10 Main Albany 120 Adams 15 Oak Boston

  5. Variable-Length Records GuestNr RoomNr ArrivalDate NrDays --------------------------------------------------------- 101 1 10 May 2 2 20 May 1 3 15 May 2 102 3 10 May 5 . . . Three Implementations: 1. Reserve enough space for maximum. 2. Chain each nested record. 3. Reserve space for the expected number and chain the rest.

  6. Hashing • Static Hashing • similar to in-memory hashing (block/offset addresses) • records in (logically) contiguous blocks (degrades w/ chaining) • Open Hashing • hash table of pointers to buckets • buckets: chained blocks of dense-index value-pointer pairs • operations: retrieve, add, delete h(101) 101 Smith 12 Maple Boston 101 . . .

  7. Indexing Verses Hashing Which is better for: • Store and retrieve on key • Search on non-key • Range search • Search on multiple attributes For highly dynamic updates, indexed-sequential files degenerate quickly—need B+-tree indexes.

More Related