Vorlesungsfolien_5

Sitzung 5: Indexkompression Folien Übersetzt + z.T. Ergänzt von Manning eT al. 1
Indexkompression • “Gesetze” zur Abschätzung des Vokabulars • Eher kurz: – DicIonary Kompression – PosIngs Kompression 2
Montag – IndexkonstrukIon • Sort-­‐based indexing – Naïve in-­‐memory inversion – Blocked Sort-­‐Based Indexing • Merge sort is effecIve for disk-­‐based sorIng (avoid seeks!) • Single-­‐Pass In-­‐Memory Indexing – No global dicIonary • Generate separate dicIonary for each block – Don’t sort posIngs • Accumulate posIngs in posIngs lists as they occur 3
• Distributed indexing using MapReduce Ch. 5
Heute • KollekIonsstaIsIken detailierter (zu RCV1) – Wie groß werden DicIonary und PosIngs? • DicIonary Kompression • PosIngs Kompression 4
Ch. 5
Warum Kompression? • Verbrauchen weniger Plaaenplatz – Geringe Ressourcenersparnis • Können mehr Ressourcen im Hauptspeicher halten – Deutliche Zunahme der Verarbeitungsgeschwindigkeit • Insbesondere auch schnellerer Datentransfer von der Festplaae zum Hauptspeicher – [lesen komprimierter Daten | dekomprimieren] ist schneller als [lesen unkomprimierter Daten] 5
Ch. 5
Warum Komprimieren wir inverIerte Indizes? • DicIonary – Klein genug um im Hauptspeicher gehalten zu werden – Klein genug um auch einige PosIngslisten im Hauptspeicher zu halten • PosIngs File(s) – Reduzieren des benöIgten Festplaaenplatzes – Redzieren der Zeit, die benöIgt wird um die PosIngsliste von der Festplaae zu lesen – Suchmaschinen halten einen bedeutenden Teil der PosIngs im Speicher 6
Sec. 5.1
Reuters RCV1 • symbol sta*s*c • N documents • L avg. # tokens per doc • M terms (= word types) • avg. # bytes per token (incl. spaces/punct.) value 800,000 200 ~400,000 6 • avg. # bytes per token 4.5 (without spaces/punct.) • avg. # bytes per term 7.5 7
• non-­‐posiIonal posIngs 100,000,000 Sec. 5.1
Index Parameter und Größen (details IIR Table 5.1, p.80) size of
word types (terms)
non-positional
postings
positional postings
dictionary
non-positional index
positional index
Size
(K)
Size (K)
∆% cumul
%
∆
%
cumul Size (K)
%
109,971
∆
%
cumul
%
Unfiltered
484
197,879
No numbers
474
-2
-2
100,680
-8
-8
179,158
-9
-9
Case folding
392 -17
-19
96,969
-3
-12
179,158
0
-9
30 stopwords
391
-0
-19
83,390 -14
-24
121,858 -31
-38
150 stopwords
391
-0
-19
67,002 -30
-39
94,517 -47
-52
stemming
322 -17
-33
63,812
-42
94,517
-52
-4
0
Intuition für die ‘0’ Einträge. Warum entsprechen manche
davon großen Änderungen in anderen Spalten?
8
Sec. 5.1
Verlusrreie vs. Nicht-­‐verlusrreie Kompression • Verlusrrei: Die InformaIon wird bewahrt. – Ist das was heute meistens getan wird. • Kompression mit Verlust: Ein Teil der InformaIon wird geopfert • Einige der Vorverarbeitungsschriae kann als Kompression mit Verlust betrachtet werden: Kleinschreibung, Stoppwörter enrernen, Stemming, LemmaIsierung, Zahlen enrernen. • Woche 6: Einträge in PosIngs enrernen die wenig wahrschlich in den top k jedweder Query auuauchen werden. Sec. 5.1
Vokabular vs. KollekIonsgröße • Wie groß ist das Termvokabular? – Wieviele unterschiedliche Wörter gibt es? • Obergrenze? – Nicht wirklich: Schätzung 2007, mindestens 7020 = 1037 verschiedene Wörter bis Länge 20 • In der Praxis, wird das Vokabular mit der Größe der KollekIon wachsen Searchable words on the Web • Hugh E. Williams and JusIn Zobel 2005 hap://www.springerlink.com/content/l5a2j2rvwurnbrfa/fulltext.pdf 10
Sec. 5.1
Vokabular vs. KollekIonsgröße • Heaps’ law: M = kTb • M Größe des Vokabulars, T ist die Zahl der Token in der KollekIon • Typical values: 30 ≤ k ≤ 100 and b ≈ 0.5 • In einem logarithmierten Plot ergibt sich eine Gerade mit etwa ½ Steigung – Empirische Erkenntnis (“Empirisches Gesetz”) 11
Sec. 5.1
Heaps’ Law Fig 5.1 p81
For RCV1, ist die gestrichelte Linie die beste Kleinstquadrateschätzung log10M = 0.49 log10T + 1.64 . M = 101.64T0.49 mit k = 101.64 ≈ 44 and b = 0.49. Gute empirische Schätzung für Reuters RCV1 ! Für die ersten 1,000,020 tokens, nach Heap 38,323 terme; tatsächlich, 38,365 terme 12
Sec. 5.1
Zipfsches Gesetz • Heaps’ Gesetz erlaubt eine grobe Schätzung für die Grösse des Vokabulars in einer KollekIon. • Interessant für den Au€au eines Index sind aber auch die relaIven Frequenzen von Termen. • In der natürlichen Sprachverarbeitung finden sich v. a. hochfrequente und sehr seltene Terme. • Zipfs Gesetz: Der i. häufigste Term hat eine Frequenz im Korpus der propor>onal zu 1/i ist. • cfi = K/i wobei K eine normalisierende Konstante • cfi ist die collecIon frequency: Zahl der Vorkommen von Term ti in der KollekIon. Sec. 5.1
Konsequenzen aus Zipf • Wenn der häufigste Term (the) cf1 mal vorkommt – Kommt der zweithäufigste cf1/2 mal also halb so ou vor – Konstante kürzt sich raus – Der driahäufigste (and) cf1/3 mal … • aus cfi = K/i – log cfi = log K -­‐ log i Lineare Beziehung zwischen cf und i 14
Sec. 5.1
Zipfsches Gesetz für Reuters RCV1 15
Ch. 5
Kompression • Schauen nochmals Kompression für DicIonary und PosIngs an – Einfacher Boolscher Index – Offen posiIonale Indizes, etc. 16
Sec. 5.2
DICTIONARY KOMPRESSION 17
Sec. 5.2
DicIonary Speicherung erste Idee • Array mit Zellen fester Länge – ~400,000 Terme; 28 Bytes/Term = 11.2 MB. Dictionary Suchbaum
20 bytes
4 bytes each
18
Sec. 5.2
Zellen fester Länge verschwenden Speicher • Mehrzahl der 20 Byte sind unbelegt. Wir allozieren 20 Bytes für 1-­‐Buchstaben Terme – Darüberhinaus können lange Terme nicht behandelt werden. supercalifragilis>cexpialidocious or hydrochlorofluorocarbons. • Geschriebens Englisch nach Schütze et al. durchschnialich ~4.5 Zeichen/Wort • Durchschnialiches DicIonary Word Englisch: ~8 Zeichen • Kurze Wörter dominieren auf Tokenebene entsprechen aber nicht dem Durchschnia auf 19
Typesebene. Sec. 5.2
Komprimieren der Termliste: DicIonary-­‐as-­‐a-­‐String Speichern das Dictionary als langen
Zeichenstring:
 Pointer auf das nächste Wort zeigt das Ende des
aktuellen Worts an
 Soll 60% der Lexikongröße einsparen.
 ….systilesyzygeticsyzygialsyzygyszaibelyiteszczecinszomo….
Total string length =
400K x 8B = 3.2MB
Pointers resolve 3.2M
positions: log23.2M =
22bits = 3bytes
Sec. 5.2
Platzverbrauch DicIonary als String • 4 Byte pro Term für die Frequenz ⎫ Jetzt ~ 11
⎬ Bytes/Term,
• 4 Byte für den PosIngs Pointer. ⎭ nicht 20.
• 3 Byte für Termpointer • Durchschn. 8 Byte für den Termstring • 400K Terme x 19 ⇒ 7.6 MB (vgl. zu 11.2MB für staIsche Länge) 21
Sec. 5.2
Blocking • Pointer nur für jeden kten TermString. – Unten: k=4. • Brauchen Termlängen (1 Extra Byte) ….7systile9syzygetic8syzygial6syzygy11szaibelyite8szczecin9szomo….
⎫ Sparen 9 Bytes
⎬ für 3
⎭ Pointer.
Brauchen 4
für Längen.
22
Sec. 5.2
DicIonary search without blocking • Assuming each dicIonary term equally likely in query (not really so in pracIce!), average number of comparisons = (1+2·∙2+4·∙3+4)/8 ~2.6 Exercise: what if the frequencies of query terms were non-­‐uniform
but known, how would you structure the dicIonary search tree? 23
Sec. 5.2
DicIonary search with blocking • Binary search down to 4-­‐term block; – Then linear search through terms in block. • Blocks of 4 (binary tree), avg. = (1+2·∙2+2·∙3+2·∙4+5)/8 = 3 compares 24
Sec. 5.2
Front Coding • Front-­‐Coding: – SorIerte Wörter haben ou lange gemeinsame Präfixe – speichere nur die Unterschiede – (for last k-­‐1 in a block of k) 8automata8automate9automa'c10automa'on →8automat*a1◊e2◊ic3◊ion
Kodiere automat
Zusatzlänge über automat.
Sec. 5.2
RCV1 DicIonary Kompression Summary Technique Size in MB Feste Länge 11.2 DicIonary-­‐as-­‐String mit Pointern 7.6 Blocking k = 4, nur jeder 4. Term mit Pointer 7.1 Blocking + Front Coding 5.9 26
Sec. 5.3
POSTINGS KOMPRESSION 27
Sec. 5.3
PosIngs Kompression • PosIngs File viel größer, wenigstens Faktor 10. • Was man will: jedes PosIng kompakt speichern. • PosIng bei uns docID. • Für Reuters (800,000 Dokumente), 32 Bit pro docID wenn wir 4-­‐byte Integers verwenden • AlternaIv, können wir log2 800,000 ≈ 20 bits pro docID benutzen. • Ziel: deutlich weniger als 20 Bit pro docID. 28
Sec. 5.3
PosIngs: unterschiedliche Fälle • Term arachnocentric kommt u.U. nur einmal in einer Million Dokumente vor log2 1M ~ 20 bits. • Term wie the kommt fast in jedem Dokument vor; 20 Bits/PosIng ist zu teuer. – Idee 0/1 Bitmap Vektor benutzen. 29
Sec. 5.3
PosIngs file entry • Speichern die Liste der Dokumente die einen Term enthalten mit zunehmender docID. – computer: 33,47,154,159,202 … • Konsequenz: genügt die Gaps zu speichern. – computer: 33,14,107,5,43 … • Hoffnung: die meisten Gaps können mit deutlich weniger als 20 bits kodiert werden. • Zwei Verfahren siehe IntroducIo to InformaIon Retrieval 30
Sec. 5.3
RCV1 compression Data structure
Size in MB
dictionary, fixed-width
11.2
dictionary, term pointers into string
7.6
with blocking, k = 4
7.1
with blocking & front coding
5.9
collection (text, xml markup etc)
3,600.0
collection (text)
Term-doc incidence matrix
960.0
40,000.0
postings, uncompressed (32-bit words)
400.0
postings, uncompressed (20 bits)
250.0
postings, variable byte encoded
116.0
postings, γ-encoded
101.0
31
Sec. 5.3
Index Kompression Zusammenfassung • Haben Überblick zu einem Index für Boolesches Retrieval, der speichereffizient ist • Nur 4% der KollekIonsgröße • Nur 10-­‐15% der Größe des Textes der KollekIon • Aber posiIonale InformaIon ignoriert • Ersparnis also kleiner für Indizes in der Praxis, aber Techniken von der Substanz her dieselben 32
Ch. 5
Lesearbeit • IIR 5 Kodierungsverfahren für PosIgsfile nur bei Interesse • F. Scholer, H.E. Williams and J. Zobel. 2002. Compression of Inverted Indexes For Fast Query EvaluaIon. Proc. ACM-­‐SIGIR 2002. – Variable byte codes • Williams and Zobel. Searchable Words on the Web. 2005 33