lecture 13: b+ tree (continued) - github pages · lecture 13 > section 3 > b+ tree design...

39
Lecture 13: B+ Tree (continued) Lecture 13

Upload: others

Post on 30-May-2020

8 views

Category:

Documents


0 download

TRANSCRIPT

Lecture13:B+Tree(continued)

Lecture13

Whatyouwilllearnaboutinthissection

1. Recap:B+Trees

2. B+Trees:Cost

3. B+Trees:Clustered

2

Lecture13

1. Recap:B+Trees

3

Lecture13

B+TreeBasics

10 20 30Eachnon-leaf(“interior”)nodehasd≤ 𝑚 ≤ 2dentries• Minimum50%occupancy

Parameterd =theorder

Lecture13>Section2>B+Treebasics

Root node has1 ≤ 𝑚 ≤ 2dentries

B+TreeBasics

10 20 30

22 25 28 29

Leaf nodes

32 34 37 38

Non-leaforinternalnode

12 17

Name:JohnAge:21

Name:JakeAge:15

Name:BobAge:27

Name:SallyAge:28

Name:SueAge:33

Name:JessAge:35

Name:AlfAge:37Name:Joe

Age:11

Name:BessAge:22

Name:SalAge:30

Lecture13>Section2>B+Treebasics

B+TreePageFormat

Lecture13>Section2>B+Treebasics

LeafPage

R1 K 1 R2 K 2 K n P n+1

data entries

record1 record2

NextPagePointer

Rn

recordn

P0

PrevPagePointer

Non

-leaf

Page

P1 K 1 P 2 K 2 P 3 K m Pm+1

index entries

PointertoapagewithValues<K1

Pointertoapagewithvaluess.t.K1≤Values<K2

Pointertoapagewithvalues≥Km

Pointertoapagewithvaluess.t.,K2≤Values<K3

Pm

B+Tree:Search

Lecture13>Section3>B+Treedesign&cost

• startfromroot

• examineindexentriesinnon-leafnodestofindthecorrectchild

• traversedownthetreeuntilaleafnodeisreached

• non-leafnodescanbesearchedusingabinaryoralinearsearch

B+Tree:Insert

Lecture13>Section3>B+Treedesign&cost

• FindcorrectleafL.• PutdataentryontoL.

• IfLhasenoughspace,done!• Else,mustsplit L(intoLandanewnodeL2)

• Redistributeentriesevenly,copyupmiddlekey.• InsertindexentrypointingtoL2intoparentofL.

• Thiscanhappenrecursively• Tosplitnon-leafnode,redistributeentriesevenly,butpushingup themiddlekey.(Contrastwithleafsplits.)

• Splits“grow”tree;rootsplitincreasesheight.• Treegrowth:getswider oroneleveltallerattop.

• Startatroot,findleafL whereentrybelongs.• Removetheentry.

• IfLisatleasthalf-full,done!• IfLhasonlyd-1entries,

• Trytore-distribute,borrowingfromsibling (adjacentnodewithsameparentasL).

• Ifre-distributionfails,merge Landsibling.

• Ifmergeoccurred,mustdeleteentry(pointingtoL orsibling)fromparentofL.• Mergecouldpropagate toroot,decreasingheight.

B+Tree:Deletingadataentry

Lecture13>Section3>B+Treedesign&cost

2.B+Trees:Cost

10

Lecture13

B+Tree:HighFanout =Smaller&LowerIO

• Ascomparedtoe.g.binarysearchtrees,B+Treeshavehigh fanout (betweend+1and2d+1)

• ThismeansthatthedepthofthetreeissmallàgettingtoanyelementrequiresveryfewIOoperations!• AlsocanoftenstoremostoralloftheB+Treeinmainmemory!

• ATiB =240 Bytes.WhatistheheightofaB+Tree(withfill-factor=1)thatindexesit(with64Kpages)?• (2*2730+1)h =240 à h =4

Thefanout isdefinedasthenumberofpointerstochildnodescomingoutofanode

Notethatfanout isdynamic-we’lloftenassumeit’sconstantjusttocomeupwithapproximateeqns!

Lecture13>Section2>B+Treecost

SimpleCostModelforSearch• Let:

• f =fanout,whichisin[d+1,2d+1](we’llassumeit’sconstantforourcostmodel…)• N =thetotalnumberofpagesweneedtoindex• F =fill-factor(usually~=2/3)

• OurB+TreeneedstohaveroomtoindexN/Fpages!• Wehavethefillfactorinordertoleavesomeopenslotsforfasterinsertions

• Whatheight(h)doesourB+Treeneedtobe?• h=1à Justtherootnode- roomtoindexfpages• h=2à fleafnodes- roomtoindexf2 pages• h=3à f2 leafnodes- roomtoindexf3pages• …• hà fh-1 leafnodes- roomtoindexfh pages!

Lecture13>Section2>B+cost

àWeneedaB+Treeofheighth= log&

'(!

SimpleCostModelforSearch• NotethatifwehaveB availablebufferpages,bythesamelogic:• Wecanstore𝑳𝑩 levelsoftheB+Treeinmemory• where𝑳𝑩 isthenumberoflevelssuchthatthesumofallthelevels’nodesfitinthebuffer:• 𝐵 ≥ 1 + 𝑓 +⋯+ 𝑓1234 = ∑ 𝑓𝑙123489:

• Insummary:todoexactsearch:• Wereadinonepageperlevelofthetree• However,levelsthatwecanfitinbufferarefree!• Finallywereadintheactualrecord

Lecture13>Section2>B+cost

IOCost: log&'(− 𝐿𝐵 + 1

where𝐵 ≥ ∑ 𝑓𝑙123489:

SimpleCostModelforSearch

• Todorangesearch,wejustfollowthehorizontalpointers

• TheIOcostisthatofloadingadditionalleafnodesweneedtoaccess+theIOcostofloadingeachpage oftheresults- wephrasethisas“Cost(OUT)”

Lecture13>Section2>B+Treecost

IOCost: log&'(− 𝐿𝐵 + 𝐶𝑜𝑠𝑡(𝑂𝑈𝑇)

where𝐵 ≥ ∑ 𝑓𝑙123489:

3.B+Trees:Clustered

15

Lecture13

ClusteredIndexes

Anindexisclustered iftheunderlyingdataisorderedinthesamewayasthe

index’sdataentries.

Lecture13>Section3

Clusteredvs.Unclustered Index

30

22 25 28 29 32 34 37 38

19 22 27 28 30 33 35 37

30

22 25 28 29 32 34 37 38

19 2227 28 3033 3537

Clustered Unclustered

IndexEntries

DataRecords

Lecture13>Section3

Clusteredvs.Unclustered Index

• Recallthatforadiskwithblockaccess,sequentialIOismuchfasterthanrandomIO

• Forexactsearch,nodifferencebetweenclustered/unclustered

• ForrangesearchoverRvalues:differencebetween1randomIO+RsequentialIO,andRrandomIO:• ArandomIOcosts~10ms(sequentialmuchmuchfaster)• ForR=100,000records- differencebetween~10msand~17min!

Lecture13>Section3

Summary

• Wecreateindexes overtablesinordertosupportfast(exactandrange)search andinsertion overmultiplesearchkeys

• B+Treesareoneindexdatastructurewhichsupportveryfastexactandrangesearch&insertionviahighfanout• Clusteredvs.unclusteredmakesabigdifferenceforrangequeriestoo

Lecture13>SUMMARY

Lecture14:HashIndexes

Lecture14

Whatyouwilllearnaboutinthissection

1. HashIndexes

2. StaticHashing

3. ExtendibleHashing

21

Lecture14

1.HashIndexes

22

Lecture14

Lecture14>Section1

HashIndex

• Ahashindexisacollectionofbuckets• bucket=primarypageplusoverflowpages• bucketscontainoneormoredataentries

• usesahashfunction h• h(r)=bucketinwhich(dataentryfor)recordr belongs

Lecture14>Section1

HashIndex

• Ahashindexis:• goodforequalitysearch• notsogoodforrangesearch(usetreeindexesinstead)

• Typesofhashindexes:• Static hashing• Extendible hashing(dynamic)• Linearhashing(dynamic)– notcoveredinthecourse,see11.3inthecowbook

Lecture14>Section1

OperationsonHashIndexes

• Equalitysearch• applythehashfunctiononthesearchkeytolocatetheappropriatebucket• searchthroughtheprimarypage(plusoverflowpages)tofindtherecord(s)

• Deletion• findtheappropriatebucket,deletetherecord

• Insertion• findtheappropriatebucket,inserttherecord• ifthereisnospace,createanewoverflowpage

Lecture14>Section1

HashFunctions

• Anideal hashfunctionmustbeuniform:eachbucketisassignedthesamenumberofkeyvalues

• Abad hashfunctionmapsallsearchkeyvaluestothesamebucket

• Examplesofgoodhashfunctions:• h(k)=a*k+b,where a andb areconstants• arandomfunction

2.StaticHashing

27

Lecture14

Lecture14>Section2

StaticHashing

• #primarybucketpagesfixed,allocatedsequentially,neverde-allocated;overflowpagesifneeded.

• h(k)modN =buckettowhichdataentrywith key kbelongs.(N=#ofbuckets)

h(key)modN

hkey

Primarybucketpages Overflowpages

10

N-1

Lecture14>Section2

StaticHashing:ExamplePerson(name,zipcode,phone)• searchkey:zipcode• hashfunctionh:last2digits

bucket0 (John,53400,23218564)(Alice,54768,60743111)

bucket1 (Theo,53409,23200564)

bucket2

bucket3 (Bob,34411,29010533)

• 4buckets• eachbuckethas2data

entries(fullrecord)

(Anna,53632,23209964)

overflowpagesprimarypages

Lecture14>Section2

HashFunctions

• Anideal hashfunctionmustbeuniform:eachbucketisassignedthesamenumberofkeyvalues

• Abad hashfunctionmapsallsearchkeyvaluestothesamebucket

• Examplesofgoodhashfunctions:• h(k)=a*k+b,where a andb areconstants• arandomfunction

Lecture14>Section2

BucketOverflow

• Bucketoverflow canoccurbecauseof• insufficientnumberofbuckets• skew indistributionofrecords

• manyrecordshavethesamesearch-keyvalue• thehashfunctionresultsinanon-uniformdistributionofkeyvalues

• Bucketoverflowishandledusingoverflowbuckets

Lecture14>Section2

ProblemsofStaticHashing

• Instatichashing,thereisafixed numberofbucketsintheindex

• Issueswiththis:• ifthedatabasegrows,thenumberofbucketswillbetoosmall:longoverflowchainsdegradeperformance• ifthedatabaseshrinks,spaceiswasted• reorganizingtheindexisexpensiveandcanblockqueryexecution

3.ExtendibleHashing

33

Lecture14

Lecture14>Section3

ExtendibleHashing

• Extendiblehashing isatypeofdynamic hashing

• Itkeepsadirectoryofpointerstobuckets

• Onoverflow,itreorganizestheindexbydoublingthedirectory(andnotthenumberofbuckets)

Lecture14>Section3

ExtendibleHashingTosearch,usethelast 2digitsofthebinaryform ofthesearchkeyvalue

00

01

10

11

2

globaldepth 2

2

2

2

localdepth

(John,12,23218564)(Alice,8,60743111)

(Theo,9,23200564)

(Maria,11,29010533)

Lecture14>Section3

ExtendibleHashing:InsertIfthereisspaceinthebucket,simplyaddtherecord

00

01

10

11

2

globaldepth 2

2

2

2

localdepth

(John,12,23218564)(Alice,8,60743111)

(Theo,9,23200564)(Zoe,13,23345563)

(Maria,11,29010533)

Lecture14>Section3

ExtendibleHashing:InsertIfthebucketisfull,splitthebucketandredistributetheentries

000

100

001

101

010

110

011

111

3

globaldepthincreasesby1 3

2

2

2

(Natalie,4,23200564)(John,12,23218564)

(Theo,9,23200564)(Zoe,13,23345563)

(Maria,11,29010533)

(Alice,8,60743111)3localdepthincreasesforthesplitbucket!

localdepthremainsthesamefortheotherbuckets

Lecture14>Section3

ExtendibleHashing:Delete• Locatethebucketoftherecordandremoveit• Ifthebucketbecomesempty,itcanberemoved(andupdatethedirectory)• Twobucketscanalsobecoalescedtogetherifthesumoftheentriesfitinasinglebucket• Decreasingthesizeofthedirectorycanalsobedone,butitisexpensive

Lecture14>Section3

MoreonExtendibleHashing• Howmanydiskaccessesforequalitysearch?• Oneifdirectoryfitsinmemory,elsetwo

• Directorygrowsinspurts,and,ifthedistributionofhashvaluesisskewed,thedirectorycangrowverylarge

• Wemayneedoverflowpageswhenmultipleentrieshavethesamehash