Indexing. The Problem

Transcription

1 Indexing Topics The Problem. Terminology. The Design Space. Fixed and Variable Length Records. B-trees Hashing Learning Objectives: Describe the problem we face in creating keys atop a conventional disk-based storage system. Design a scheme to implement records on top of files. Explain what B-trees are. Distinguish the different B-tree variants and explain the trade-offs among them. Explain hashing as applied to database indexes. 2/2/10 1 The Problem We want to store key/data pairs (aka records). Today s file systems store files. Old IBM file systems were record-based. Operating system/file system knew about record formats, keys, etc. In fact, some disks knew about keyed structure and lookup. Take CS261 to learn more about this. Need to flexibly and efficiently store records in files. Efficient in terms of space. Efficient in terms of look-up time. Flexible in terms of record size (fixed and variable). Flexible in terms of the number of indices, types of indices, etc. 2/2/10 2

2 Isn t this a solved problem? There are lots of data structures like trees and things with gazillions of algorithms that operate on them efficiently. Why don t these algorithms and data structures translate directly into disk-space structures? Pointers work nicely in main memory -- how do you represent pointers in main memory? Data structures can be arbitrarily sized, but disk blocks are fixed size (and are larger than many objects). Files typically only grow at the end -- they don t support insert into the middle. 2/2/10 3 Storage Technology There are a variety of media on which to store data. Each type has a different set of tradeoffs. Tradeoffs change over time. Important to understand the principles and roles rather than particular implementations. What would an ideal storage technology look like? Infinitely fast: add no additional latency to the cost of the processor operations. 100% reliable. 100% available. Infinitely large (or as large as your largest data set). Cheap. 2/2/10 4

3 Sample Storage Technologies RAM Main Memory Speed Stability Writable Cost/bit Random access Very fast Poor Yes High Yes Flash Fast OK Yes Medium/ High Yes Disk Slow OK Yes Mid Yes (but slower) Tape Slow Good Yes Low No 2/2/10 5 Abstracting the Disk The disk interface is clunky: Read and write one or more sectors. A sector is 512 bytes. Not a terribly elegant interface for implementing key/data pairs. Operating systems provides files -- are they much better? Byte stream interface. Position a pointer and read/write some number of bytes to/from that location. Still not terribly easy to do things like keys. Problems: No structure within disk blocks or byte streams. Unit of transfer between disk and file system is pages (1K, 4K, 1M) Placing one object per file breaks nearly all file systems. If you put multiple objects into a file, you still need a way to locate them. 2/2/10 6

4 Terminology Interchangeable terms: key/data pairs, record, tuple Primary Index: Index sort order corresponds to layout Secondary Index: Sort order independent of layout Internal Index: Keys and data both stored in index External Index: Keys and reference to data in index Data is stored elsewhere Meta-data: Data that describes the data or its structure Not user data 2/2/10 7 The Design Space Fixed versus variable length records. Fixed are easier. Fixed are faster. Most data are not fixed length. Usually waste space -- have to allocate enough space for largest objects (if you don t allocate enough space, what do you do when you get a big object?) Internal or external indices External indices separate indexing from the data. Internal indices make consistency easier. Internal indices provide clustering. 2/2/10 8

5 B-tree versus Hash Indexing High order difference: ordered versus unordered In-theory hash indices require fewer disk accesses. In practice, this is often not the case: Practically all database systems maintain a cache. The cache should be large enough to hold all the internal nodes of a B-tree. If so, internal nodes are memory accesses, not disk accesses. Items in hash buckets are not necessarily sorted. If there are many items per bucket, locating an item in a bucket can be expensive. Since B-trees must be ordered, searching them may be faster. Accesses are rarely random, so B-tree clustering is often a win. When are hash tables a big win? Database is huge (internal pages do not fit in memory) 2/2/10 Access is really random. 9 Implementation: Fixed Length Records (Naïve Approach) Allocate records contiguously, one right after the other. Let s be the record size. To access record n, compute s * n, seek to that offset, and read s bytes. Record 0 Record 1 Record 2 Record 3 Record 4 s bytes Offset = s * n n 2/2/10 10

6 Naïve Approach: Problems Obvious, simple, and wrong Record 0 Record 1 Record 2 Record 3 Record 4 Disk Block Other Problems? How do you delete a record? How do you add a record between record 2 and 3? 2/2/10 11 Fixed Length Records: Take 2 Add meta-data Let s add 1 bit in each record that indicates if the record is present/not present: Record 0 Record 1 Record 2 Record 3 Record 4 Pros/Cons? + Can delete records + Can reuse space - Difficult to find free space - Records still span pages 2/2/10 12

7 Fixed Length Records: Take 3 Add more meta-data: a header page Header points to the beginning of a free list Each deleted record points to the next deleted record. Header Record 0 Record 1 Record 2 Record 3 Record 4 Pros/Cons? + Can now find free space easily - Records still span pages 2/2/10 13 Fixed Length Records: Take 4 Put records on pages explicitly Calculate how many records fit on a page. Call this f (fill factor) To find record n, compute P(age) = n / f; O(ffset) = n % f Keep free space management from previous approach. Header Record 0 Record 1 Record 2 Record 3 Pros/Cons? +Records still span pages - Wasted space called internal fragmentation 2/2/10 14

8 Variable Length Records Now assume records have different lengths. Problem: Can no longer computer a fill factor Must have some kind of meta-data Per-record length End of record delimiter Directory Record lengths of delimiters Abandon record numbers and assume records are identified by a page number and offset. Before each record, include its length, OR After each record, place a special symbol 2/2/10 15 Lengths and Delimiters (1) Record P/0 100 Record P/2 Record P/1 Record P/0 Record P/1 Record P/2 2/2/10 16

9 Lengths and Delimiters (2) Pros/Cons? How do you read backwards within a page (lengths)? How do you delete? How do you insert? Add meta-data back in (from fixed length records) Add deleted bit Add header and freelist Chain empty records together Why is this harder than the fixed length case? Performing dynamic memory allocation Pick an algorithm: first fit, best fit, etc. 2/2/10 May have to coalesce space 17 Variable Length: Take 2 Use the page/offset identification scheme. Place a directory at the top of each page Directory points to where records begin Grow directory from the top Allocate record space from the bottom Can expand header to include things like deleted bits off 1 off 2... off f record f records 3 f-1 record 2 record 1 2/2/10 18

10 A note about objects How do objects fit into this? Objects are just variable sized records. Objects may contain references to other objects. Must translate these references between persistent form and memory representation; called swizzling. On-disk might use the page/offset record number In memory probably want an actual pointer It is this translation that is called swizzling Some objects are large (greater than a page). Previous designs assumed that objects fit on a single page; life gets more complicated when this is not the case. 2/2/10 19 B-trees: Balanced Trees B-trees were designed to balance the time taken to retrieve a page from disk and the time to search within a page. We will build a tree from nodes, where nodes correspond to disk pages (a few KB). Each (internal) node stores N keys and N + 1 pointers to other nodes. On leaves, keys can be paired with their data (internal index) or they can contain record numbers (external index). 2/2/10 20

11 B-Tree Diagram mouse eagle koala rat tiger bat emu lemur muskrat rhino vole cat frog llama ostrich shrimp whale dog goat mite parrot 2/2/10 21 B-tree vs B+tree B-tree: both leaves and internal pages contain data. B+tree: all data lives at the leaves. What are the trade-offs between B-trees and B+trees? B-tree: no duplication of keys B+tree: All data at the leaves; iterating over keys is easier. B+tree: Internal nodes more compact (better fanout). B-tree: Some lookups are faster 2/2/10 22

12 Maintaining your Tree Splits What do you do when you are trying to insert and an item doesn t fit? Split the page in half; pick a key that distinguishes the pages and insert it into the parent page. What happens if that key doesn t fit in the parent? Split the parent potentially recursive up to the root. Reverse splits (merges, coalescing) On delete, you might empty a page. Coalesce the page with its sibling and remove a key from the parent. Like splits, reverse splits can propagate to root. 2/2/10 23 Other B-Tree Variants B-link: Leaf pages are linked together to provide fast sequential scan. Almost everyone does this. Straight forward until you introduce cursors and concurrency (stay-tuned). B*: All nodes are kept 2/3 full (by redistributing keys). Splitting becomes more complicated because you may have to move keys among siblings to maintain the 2/3 property. Reverse splits happen before pages become empty must consider a coalescing operation whenever you drop below 2/3 full. 2/2/10 24

13 Practical Considerations (1) Key lengths may vary, so you may not be able to maintain the same number of keys (and therefore pointers per page). What are the implications of this? Nodes must map to pages (either disk or file). Pointers are therefore page numbers. How do you handle keys (or data) larger than a page? What is the minimum number of keys you must have on a page? What if they don t fit? Key compression If you store entire keys, you may be storing a lot of repeated data (e.g., misdemeanor, misplace, mistake, etc). Store the minimum difference keys instead (store mis once and store the suffixes as keys). 2/2/10 25 Practical Considerations (2) What if you have multiple data items for the same key? Do you allow it? How do you store them? What if you have so many duplicates, you have to split the page on which they reside what key do you promote? Standard solutions: Disallow Store a few duplicates on a node, but if you get too many, create a special duplicate page (perhaps even an entire tree). Store multiple data items as one (encoded) data item. 2/2/10 26

14 A Cute Hack Sometimes you want real record numbers, not page/offset identifiers. And sometimes you want to insert new records between two adjacent records. You can hack B+trees to do that With each pointer, store the number of records that appear beneath that pointer. Can easily find the record with record number n. Facilitates insertion and. 2/2/10 27 Cute Hack: Demo 9 7 mouse eagle koala rat tiger bat cat dog emu frog goat lemur llama mite muskrat ostrich parrot rhino shrimp vole whale 2/2/10 28

15 Cursors They mark a position in the tree (used in iterating over a file). Cannot lose the position in the face of a delete. Subsequent inserts must happen in the right spot. Requires retaining the key value. With multiple deletes and multiple cursors, you have to maintain positioning between cursors c_get elephant delete current where is cursor? insert kangaroo insert eagle cat dog elephant mouse cursor 2/2/10 29 Semi-Digression: Famous Last Words (Thanks to Mark Day) Databases seem so complicated. We can just do this with shared text files. OK then, we ll just write a B-tree package B-tree code seems hard to get right for all the corner cases. No text book exists that actually explains all the intricate details of B-tree manipulation; they present the first 80% in wonderful simplicity. One of the reasons Berkeley DB exists is because B-tree implementations are simply hard. 2/2/10 30

16 Hashing Your index is a collection of buckets (bucket = page) Define a hash function, h, that maps a key to a bucket. Store the corresponding data in that bucket. Collisions Multiple keys hash to the same bucket. Store multiple keys in the same bucket. What do you do when buckets fill? Chaining: link new pages(overflow pages) off the bucket. Open-hashing: look in the next bucket. Chaining versus open-hashing Open-hashing does not support deletion well. 2/2/ Hash Example Assume: H(cat) = 0 H(dog) = 1 H(mouse) = 0 Operations 1. Insert cat 2. Insert dog 3. Insert mouse 4. Delete dog 5. Lookup mouse mouse cat dog mouse 2/2/10 32

17 Static vs Dynamic Hashing Static: number of buckets predefined; never changes. Either, overflow chains grow very long, OR A lot of wasted space in unused buckets. Dynamic: number of buckets changes over time. Hash function must adapt. Usually, start revealing more bits of the hash value as the table grows. 2/2/10 33 Practical Hashing (1) Buckets map to pages. Must be able to directly translate from a bucket number to a page number. Where do you store overflow pages? If number of buckets is fixed (static hashing), store overflow buckets after regular buckets. Use free list to manage overflow buckets. Static hashing isn t very practical for databases. Databases change in size fairly substantially. If you have to preallocate, often waste space. 2/2/10 34

18 Practical Hashing (2) Dynamic hash implementation. Periodically double the size of the database. Rehash every key into new table. Dynamic Linear Hashing (Litwin) Grow table one bucket at a time. Split buckets sequentially; rehash just the splitting bucket. Maintain overflow buckets as necessary. Keep track of max bucket to identify the correct number of bits to consider in the hash value. 2/2/10 35