Data Structures & Algorithms Extermal Search

1. Data Structures & Algorithms Extermal Search Richard Newman based on book by R. Sedgewick

2. Rules of the Game • Searching very large structures • Too big to fit into memory • Avoid sequential search • Fast random access to data blocks • Hard disk <-> memory pages • Support insert/remove/find

3. Rules of the Game • External access time dominates • Orders of magnitude slower • Minimize “probes” – first access to page • Models • File-name based storage • Virtual memory

4. Strategy • Maintain index to data • Get reference to item quickly • Only bring in necessary pages

5. Indexed Sequential Access • Keep sorted array with keys and item references • Use binary search on array • Uses only lg N probes • Problem: Index may be huge • Won’t fit on single page

6. Indexed Sequential Access • Store keys and item references in fully balanced binary tree • Internal nodes: keys and page pointers • External nodes: keys and item pointers • Page access dominates node access • Implement M-ary tree • Now logM N probes – nearly linear

7. Indexed Sequential Access 153 601 601 001 176 513 601 017 601 513 207 601 061 601 275 706 107 706 001 601 277 147 153 513 601 373 601 373 601 434 513 601 706 562 601 513 737 706 524 526 601 737 601 562 601 513 741 601 513 574 742 601 601 601 706 766 706 706 773 736

8. Indexed Sequential Access • Sequential key organization + indexed access • Hence indexed sequential access • Used by modern file systems • Index = directory • Not good with dynamic structures • Have to rebuild database!

9. Indexed Sequential Access Prop. 16.1: Search in indexed sequential file requires effectively a constant number of probes (logM N for large M), but an insertion can involve rebuilding the entire index.

10. B-Trees • Desire to support dynamic sets • And still be efficient • Relax requirement that every node have exactly M entries • Rather, require at most M entries • Still want space efficient • Require at least M/2 entries • Except possibly at root (at least one)

11. B-Trees • A generalization of 2-3-4 trees • Sedgewick allows different values • Not just M/2 <= k <= M items • Strict version Bayer & McCreight 1970 • Multiway nodes via arrays • Index, not search structure • Does not contain items • Split from bottom up

12. B-Trees EIQU ABCD FGH JKLMNOP RST VWXYZ Note that each node has one more link than number of keys Keys act to split search

13. B-Trees Defn. 16.2: A B-Tree of order M is a tree that either is empty or comprises k-nodes, with k-1 keys and k links to trees representing the intervals delimited by adjacent keys, with 2≤k≤M at the root and M/2 ≤ k ≤ M at all other nodes; all links to empty trees must be at the same depth.

14. B-Trees Check out the animation: http://www.cs.usfca.edu/~galles/visualization/BTree.html Prop. 16.2: A search or insertion in a B-Tree of order M with N items takes between logM N and logM/2 N probes – a constant number for practical purposes.

15. B-Plus Trees B-Plus tree: Add links from leaf to next leaf to make sort traversal easier, as well as merge Check out the animation: http://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

16. B-Trees Prop. 16.3: A B-Tree of order M constructed from N random items is expected to have about 1.44N/M pages.

17. Extendible Hashing • Combines features of • Hashing • Multi-way tries • Sequential-access • Uses just one or two probes for insert or search

18. Extendible Hashing • Search • Start with leading bits of key • Index into table (power of 2 size) • Items stored in pages split when overflow • Maintain directory with reference to page containing item matching a key

19. Extendible Hashing • Suppose have 2d disk pages • Directory of 2d page references • Use d bits of key to index into directory • Keep in same page all keys whose first d bits match, in order • Sequential search on page • OK to have multiple pointers to same pg • Items stored in pages split when overflow

20. Extendible Hashing Defn. 16.3: An extendible hash table of order d is a directory of 2d references to pages that each contain up to M items with keys. The items on each page are identical in their first k bits, and the directory contains 2d-k pointers to the page, starting at the location specified by the first k bits on the page.

21. Extendible Hashing • Table growth • Page split • Distribute keys from one page over two • Decided by first bit where keys differ • Directory split • Double the size of the directory, d++ • Do when necessary from page split • May make multiple pointers to same pg

22. Extendible Hashing Prop. 16.4: The extendible hash table built from a set of keys depends only on the values of those keys, not upon their insertion order.

23. Extendible Hashing M = 5 keys + item references per page Insert: 601 153 513 706 176 773 601 153 601 513 176 601 513 706 601 706 Now what? The page is full! Split!

24. Extendible Hashing Split page, so split directory… Insert: 601 153 513 706 176 773 742 373 524 153 0x 176 373 1x 513 601 706 773 742 773 Now we can insert 773

25. Extendible Hashing Split page again, need to split directory… Insert: … 524 776 275 374 007 153 00x 176 275 373 373 01x 374 513 10x 524 601 706 11x 742 773 776 Now we can insert 524 Now what?

26. Extendible Hashing Split page … but no need to split directory (2 pointers) Insert: … 007 153 007 275 00x 153 176 373 176 374 374 01x 10x 513 601 524 706 11x 742 773 776 Now we can insert 007

27. Concurrency Issues • May have multiple processes • All accessing same structure • At the same time…. • No problem if two read same data • Big problem if • Read overlaps write • Write overlaps write

28. Locking • One solution is locking • Prevent simultaneous access that could cause problems • Process requests lock • Has to wait until lock is granted • Once lock held, can proceed

29. Locking • Single lock for whole data structure is too restrictive • Prevents all other accesses! • So lock parts of structure needed • Nodes along path • Unlock as soon as no longer needed • Allow others to access

30. Locking • On insertion or removal • May have to change root • So can’t release until known • Types of locks • Depend on operation • Reads are compatible • Writes are not

31. Locking • Read lock/write lock • Use read lock on search • Use write lock on insert/remove • Lock compatibility: • Read OK with read • Read NOT OK with write • Write NOT OK with write

32. Locking • Read lock/write lock • Use read lock on search • Use write lock on insert/remove • Lock compatibility matrix: Lock held Lock requested

33. Locking • Add Alpha lock = tentative write • Use alpha lock on insert/remove • Until known if write needed • Then write lock as required Lock held Lock requested

34. Locking • Always lock from top to bottom • Else danger of deadlock • Only unlock when know it is safe • If insert and node not full, then • Can unlock the parent • Process with alpha lock on a node can request write lock • Gets it when no more read locks

35. Summary • Indexed Sequential Access • B-Trees • Extendible Hashing • Concurrency issues