Hva er fordelene med T-trær enn B +/- trær?

stemmer
12

Jeg har utforsket definisjonene av t-trær og B- / B + trær. Fra papirer på nettet forstår jeg at B-trær prestere bedre i hierarkisk minne, for eksempel harddisker og bufret minne.

Det jeg ikke forstår er hvorfor T-trær ble / blir brukt selv for flat minne?

De er annonsert plass effektivt alternativ til AVL trær.

I verste fall alle bladnoder i en T-treet inneholde bare ett element, og alle interne noder inneholde en minimal mengde tillatt, som ligger i nærheten av full. Dette betyr at i gjennomsnitt bare halvparten av det tildelte plass blir utnyttet. Med mindre jeg tar feil, er dette det samme utnyttelse som det verste tilfellet av B-trær, når nodene i en B-treet er halvfull.

Forutsatt at begge trær lagrer nøklene lokalt i nodene, men bruker pekere til å referere til postene, den eneste forskjellen er at B-trær har til å lagre pekere for hver av grenene. Dette vil vanligvis føre til at opp til 50% overhead eller mindre (i løpet av t-trær), avhengig av størrelsen av nøklene. Faktisk er dette i nærheten av overliggende forventet i AVL trær, forutsatt at ingen foreldre peker, plater innleiret i nodene kiler som er innleiret i journalen. Er dette den forventede effektivitetsgevinst som hindrer oss i å bruke B-trær i stedet?

T-trær er vanligvis implementert på toppen av AVL trær. AVL trær er mer balansert enn B-trær. Kan dette ha sammenheng med bruk av T-trær?

Publisert på 29/01/2011 klokken 14:43
kilden bruker
På andre språk...                            


2 svar

stemmer
3

Jeg kan gi deg en personlig historie som dekker halvparten av svaret, det er derfor jeg skrev noen Pascal kode for å programmere B + trær noen 18 år siden.

mitt mål systemet var en PC med to harddisker, jeg måtte lagre en indeks på ikke flyktig minne, og jeg ønsket å forstå bedre hva jeg lærte på universitetet. Jeg var veldig misfornøyd med ytelsen til en kommersiell pakke, sannsynligvis DBase III, eller noen Fox produkt, kan jeg ikke huske.

hvertfall: Jeg trengte disse operasjonene:

  • se opp
  • innsetting
  • sletting
  • neste element
  • forrige element

  • maksimale størrelsen på indeksen ble ikke kjent

  • slik at data måtte ligge på disken
  • hvert tilgang til støtte hadde høye kostnadene
  • lese en hel blokk koste det samme som å lese en byte

B + -trees gjort at små treg PC virkelig fly gjennom dataene!

bladene hadde to ekstra pekere slik at de dannet en dobbeltlenket liste, for sekvensielle søk.

Svarte 11/02/2011 kl. 22:49
kilden bruker

stemmer
2

I virkeligheten forskjellen ligger i systemet du bruker. Som min veileder på universitetet kommenterte det: Hvis problemet ligger i mangel på minne, eller i hdd mangel avgjør hvilken treet og der implementeringen vil du bruke. Mest sannsynlig vil det være B + tre.

Fordi det er hundrevis av implementeringer, for eksempel med 2direction kø og en retnings køer der du trenger å sløyfe tanke elementer, og også det er flere måter å lagre indeksen og hente det vil avgjøre de reelle ulemper og minutter av eventuell gjennomføring.

Svarte 25/02/2011 kl. 08:02
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more