memory management during run generation in external sorting – larson & graefe
TRANSCRIPT
![Page 1: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/1.jpg)
Memory Management during Run Generation in External Sorting – Larson & Graefe
![Page 2: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/2.jpg)
Need For External Merge Sort:• One of most often used operations • Used in joins• Used in duplicate elimination• User requests “sort”
It is important for the algorithm to degrade gracefully. The query optimizer does not know ahead the exact number of records (vs. amount of memory available).
![Page 3: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/3.jpg)
External Sorting
• External N-way merge sort• (Usually) two phases: Run generation and
merge• During run generation, create one run at a
time (load-sort-store):1. Load records2. Sort array of pointers to records (quicksort)3. Scan pointer array while outputting records
![Page 4: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/4.jpg)
Run Generation
• Problem:– Discontinuity in the cost function (thus it is
difficult to estimate cost of a sort operator) due to load-sort-store
– Note: That’s why (naively) hash join is preferred over sort-merge join
• Contribution:– Sorting algorithm with smooth cost function
(graceful degradation)
![Page 5: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/5.jpg)
This Paper
• Idea– Similar to hybrid-hash: Keep parts of the
previous run in-memory
• Problem: Memory management during initial run generation
![Page 6: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/6.jpg)
Assumptions
• Ascending sort order
• Sort must copy records into its own workspace
• No specialized disk page/file management
• Single thread of execution
• Variable-length records, no vertical partitioning of records possible
![Page 7: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/7.jpg)
Assumptions (Contd.)
• Fixed amount of sort workspace (main memory) available, divided into extents
• An extent is a sequence of segments– Record and free segments, one bit indication in header– Each segment holds one record. – Segment type and length stored in segment header– Free segments store pointers for space management– Free segments never touch
• Separate output buffer (one or several pages for asynch. I/O)
![Page 8: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/8.jpg)
Variable-Length Fields and Records:
• Human readable text data (non-numeric)• Even in numeric records, NULL values will
usually be not allocated• Any non-traditional data (pictures, sound)• Padding records is NOT a good idea!
Managing variable length records deterred researches from using this approach
![Page 9: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/9.jpg)
Memory Management Algorithms
• First fit (find first space that matches)
• Next fit (same as above, but move around)
• Best fit (find closest, larger match)
Collapse free spaces
Move records
![Page 10: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/10.jpg)
Run Formation
• First, do not output the run from memory until needed! That is, only output records from memory when need space for new record
• These ‘left over’ records can be used in first merge step of external sort – reduces IO
• Depends on the fan-in of input buffers. If fan-in maximal, there is little records left in memory for this optimization.
![Page 11: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/11.jpg)
Replacement Selection
• If we keep track of the highest key of a record written to disk from current output, we can add next record to the current output provided its key is higher
• Pointer array no longer efficient – use priority heap (‘tree of losers’)
• Runs on average twice the size of the available memory
Result: steady IO exploits pre-sorting
![Page 12: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/12.jpg)
Merging
• Always merge as many runs as possible
• Keep final run in memory to eliminate unnecessary IO
• Possibly reverse record order when writing to disk (not used)
![Page 13: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/13.jpg)
Memory Management
• Next Fit– free segments implemented as linked list– first check the list– second consider moving records– finally throw current record out– example: inserting 120 byte record
100 free, N occupied, 60 free, 80 occupied
![Page 14: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/14.jpg)
100 bytes 80 bytes
140 bytes60 bytes
120 bytes
60 bytes
![Page 15: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/15.jpg)
Next Fit Structure
Record Segment Free Segment
Type Type
Length Length
Pointer to reference map (Forward Pointer)
Actual Record Backward Pointer
![Page 16: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/16.jpg)
Memory Management (cont)
• Best Fit– unbalanced binary tree– go down the tree until right fit found or move
one to right– need to know neighboring segments for
merging
![Page 17: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/17.jpg)
Best Fit Structure
Record Segment Free Segment
Type Type
Length Length
Actual Record (Forward Pointer)
Backward Pointer
(Parent Pointer)
Left Child Pointer
Right Child Pointer
![Page 18: Memory Management during Run Generation in External Sorting – Larson & Graefe](https://reader036.vdocuments.site/reader036/viewer/2022082711/56649f1e5503460f94c36448/html5/thumbnails/18.jpg)
Results
• Best fit memory management algorithm achieved 90% memory utilization
• Runs were 1.8x size of available memory
• Degrades Gracefully!