1 / 23

CSE 326: Data Structures Lecture #13 Extendible Hashing and Splay Trees

CSE 326: Data Structures Lecture #13 Extendible Hashing and Splay Trees. Alon Halevy Spring Quarter 2001. Extendible Hashing. Hashing technique for huge data sets optimizes to reduce disk accesses each hash bucket fits on one disk block better than B-Trees if order is not important

halla-morin
Télécharger la présentation

CSE 326: Data Structures Lecture #13 Extendible Hashing and Splay Trees

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. CSE 326: Data StructuresLecture #13Extendible Hashing and Splay Trees Alon Halevy Spring Quarter 2001

  2. Extendible Hashing • Hashing technique for huge data sets • optimizes to reduce disk accesses • each hash bucket fits on one disk block • better than B-Trees if order is not important • Table contains • buckets, each fitting in one disk block, with the data • a directory that fits in one disk block used to hash to the correct bucket

  3. Extendible Hash Table • Directory contains entries labeled by k bits plus a pointer to the bucket with all keys starting with its bits • Each block contains keys+data matching on the first j k bits directory for k = 3 000 001 010 011 100 101 110 111 (2) 00001 00011 00100 00110 (2) 01001 01011 01100 (3) 10001 10011 (3) 10101 10110 10111 (2) 11001 11011 11100 11110

  4. Inserting (easy case) insert(11011) 000 001 010 011 100 101 110 111 (2) 00001 00011 00100 00110 (2) 01001 01011 01100 (3) 10001 10011 (3) 10101 10110 10111 (2) 11001 11100 11110 000 001 010 011 100 101 110 111 (2) 00001 00011 00100 00110 (2) 01001 01011 01100 (3) 10001 10011 (3) 10101 10110 10111 (2) 11001 11011 11100 11110

  5. Splitting insert(11000) 000 001 010 011 100 101 110 111 (2) 00001 00011 00100 00110 (2) 01001 01011 01100 (3) 10001 10011 (3) 10101 10110 10111 (2) 11001 11011 11100 11110 000 001 010 011 100 101 110 111 (2) 00001 00011 00100 00110 (2) 01001 01011 01100 (3) 10001 10011 (3) 10101 10110 10111 (3) 11000 11001 11011 (3) 11100 11110

  6. Rehashing insert(10010) No room to insert and no adoption! 00 01 10 11 (2) 01101 (2) 10000 10001 10011 10111 (2) 11001 11110 Expand directory 000 001 010 011 100 101 110 111 Now, it’s just a normal split.

  7. Rehash of Hashing • Hashing is a great data structure for storing unordered data that supports insert, delete, and find • Both separate chaining (open) and open addressing (closed) hashing are useful • separate chaining flexible • closed hashing uses less storage, but performs badly with load factors near 1 • extendible hashing for very large disk-based data • Hashing pros and cons + very fast + simple to implement, supports insert, delete, find - lazy deletion necessary in open addressing, can waste storage - does not support operations dependent on order: min, max, range

  8. Binary search tree properties binary tree property search tree property Balance property balance of every node is: -1b 1 result: depth is (log n) Recall: AVL Tree Dictionary Data Structure 8 5 11 2 6 10 12 4 7 9 13 14 15

  9. Splay Trees “blind” rebalancing – no height info kept • amortized time for all operations is O(log n) • worst case time is O(n) • insert/find always rotates node to the root! • Good locality – most common keys move high in tree

  10. Since you’re down there anyway, fix up a lot of deep nodes! Idea 10 You’re forced to make a really deep access: 17 5 2 9 3

  11. Splay Operations: Find • Find(x) • do a normal BST search to find n such that n->key = x • move n to root by series of zig-zag and zig-zig rotations, followed by a final zig if necessary

  12. Zig-Zag* Helped Unchanged Hurt g n X p g p n W X Y Z W Y Z *This is just a double rotation

  13. Zig-Zig g n W p p Z X n g Y Y Z W X

  14. Zig root root p n n Z X p X Y Y Z

  15. Why Splaying Helps • Node n and its children are always helped (raised) • Except for final zig, nodes that are hurt by a zig-zag or zig-zig are later helped by a rotation higher up the tree! • Result: • shallow (zig) nodes may increase depth by one or two • helped nodes may decrease depth by a large amount • If a node n on the access path is at depth d before the splay, it’s at about depth d/2 after the splay • Exceptions are the root, the child of the root, and the node splayed

  16. Locality • Assume mn access in a tree of size n • Total amortized time O(m log n) • O(log n) per access on average • Gets better when you only access k distinct items in the m accesses. • Exercise.

  17. 6 5 4 Splaying Example 1 1 2 2 zig-zig 3 3 Find(6) 4 5 6

  18. 6 5 4 Still Splaying 6 1 1 2 6 zig-zig 3 3 2 5 4

  19. 6 1 Almost There, Stay on Target 1 6 zig 3 3 2 5 2 5 4 4

  20. 6 6 1 1 Splay Again zig-zag 3 4 Find(4) 2 5 3 5 4 2

  21. 6 1 Example Splayed Out 4 1 6 zig-zag 3 5 4 2 3 5 2

  22. Splay Tree Summary • All operations are in amortized O(log n) time • Splaying can be done top-down; better because: • only one pass • no recursion or parent pointers necessary • Invented by Sleator and Tarjan (1985), now widely used in place of AVL trees • Splay trees are very effective search trees • relatively simple • no extra fields required • excellent locality properties: frequently accessed keys are cheap to find

  23. Coming Up • Project 3: implement a “smart” web server. • Heaps! • Disjoint Sets • Graphs and more.

More Related