Information Retrieval. Lecture 3 - Index compression. Introduction. Overview. Characterization of an index. Wintersemester 2007

Transcription

1 Information Retrieval Lecture 3 - Index compression Seminar für Sprachwissenschaft International Studies in Computational Linguistics Wintersemester / 30 Introduction Dictionary and inverted index: core of IR systems Techniques can be used to compress these data structures, with 2 objectives: 1. reducing the disk space needed 2. reducing the time processing, by using a cache (keeping the postings of the most frequently used terms into main memory) NB: decompression can be faster than reading from disk 2/ 30 Overview The string method Conclusion 3/ 30 Example considered: the Reuters-RCV1 collection non-positional positional postings word types postings (word tokens) size of dictionary non-positional index positional index size cumul. size size cumul. 484, ,971, ,879,290 unfiltered no numbers 473,723-2% -2% 100,680,242-8% -8% 179,158,204-9% case folding 391,523-17% -19% 96,969,056-3% -12% 179,158,204-0% 30 stop words 391,493-0% -19% 83,390,443-14% -24% 121,857,825-31% 150 stop words 391,373-0% -19% 67,001,847-30% -39% 94,516,599-47% stemming 322,383-17% -33% 63,812,300-4% -42% 94,516,599-0% 4/ 30

2 Statistical properties of terms The vocabulary grows with the corpus size Empirical law determining the number of term types in a collection of size M (Heap s law) M = kt b where T is the number of tokens, and k and b 2 parameters defined as follows: (k is the growth-rate) b 0.5 and 30 k 100 On the REUTERS corpus (taking k = 33 and b = 0.5): M = = / 30 Index format with fixed-width entries term tot. freq. pointer to postings list postings list a 656,265 aachen 65 zulu 221 space needed: 40 bytes 4 bytes 4 bytes Total space: M ( ) = 400, = 19.2 MB NB: why 40 bytes per term? (unicode + max. length of a term) 6/ 30 Remarks The average length of a word type for REUTERS is 7.5 bytes With fixed-length entries, a one-letter term is stored using 40 bytes! Some very long words (such as hydrochlorofluorocarbons) cannot be handle How can we extend the dictionary representation to save bytes and allow for long words? 7/ 30 Dictionary-as-a-string The string method... s y s t i l e s y z yge t i c s y z yg i a l s y z ygy s z a i be l y i t e s z e c i freq. postings ptr. term ptr bytes 4 bytes 3 bytes 8/ 30

3 The string method Space use for dictionary-as-a-string 4 bytes per term for frequency 4 bytes per term for pointer to postings list 3 bytes per pointer into string (need log bits to resolve 400,000 positions) 8 chars (on average) for term in string Space: 400,000 ( ) = 10.8 MB (compared to 19.2 MB for fixed-width) 9/ 30 Block-storage... 7s y s t i l e9s yzyge t i c8s y z yg i a l 6s y z ygy11s za i be l y i t e freq postings ptr. term ptr. 10/ 30 Space use for block-storage Let us consider blocks of size k We remove k 1 pointers, but add k bytes for term length Example: k = 4, (k 1) 3 bytes saved (pointers), and 4 bytes added (term length) 5 bytes saved Space saved: 400,000 (1/4) 5 = 0.5 MB (dictionary reduced to 10.3 MB) Why not taking k > 4? 11/ 30 Search without blocking aid job den pit box ex ox win Average search cost: ( )/8 2.6 steps 12/ 30

4 Impact of blocking on search aid box den ex job ox pit win Average search cost: ( )/8 3 steps 13/ 30 Front coding One block in blocked compression (k = 4) 8 a u t o m a t a 8 a u t o m a t e 9 a u t o m a t i c 10 a u t o m a t i o n further compressed with front coding. 8 a u t o m a t a 1 e 2 i c 3 i o n End of prefix marked by Deletion of prefix marked by 14/ 30 Dictionary compression for Reuters representation size in MB dictionary, fixed-width 19.2 dictionary as a string 10.8, with blocking, k = , with blocking & front coding / 30 Recall: the REUTERS collection has about documents, each having 200 tokens Since tokens are encoded using 6 bytes, the collection s size is 960 MB A document identifier must cover all the collection, i.e. must be log bits long If the collection includes about postings, the size of the posting lists is /8 = 250MB How to compress these postings? Idea: most frequent terms occur close to each other we encode the gaps between occurences of a given term 16/ 30

5 Gap encoding encoding postings list the docids gaps computer docids gaps arachnocentric docids gaps Furthermore, small gaps are represented with shorter codes than big gaps 17/ 30 Variable-length byte encoding uses an integral number of bytes to encode a gap First bit := continuation byte Last 7 bits := part of the gap The first bit is set to 1 for the last byte of the encoded gap, 0 otherwise Example: a gap of size 5 is encoded as / 30 Variable-length byte code: example docids gaps VB code What is the code for a gap of size 1283? Homework: write a Java class which encodes/decodes such gaps. 19/ 30 About variable-length byte compression The posting lists for the REUTERS collection are compressed to 116 MB with this technique (original size: 250 MB) The idea of representing gaps with variable integral number of bytes can be applied with units that differ from 8 bits Larger units can be processed (decompression) quicker than small ones, but are less effective in terms of compression rate 20/ 30

6 Idea: representing numbers with a variable bit code Example: unary code the number n is encoded as: (NB: not efficient) n times {}}{ γ-code, variable encoding done by splitting the representation of a gap as follows: length offset offset is the binary encoding of the gap (without the leading 1) length is the unary code of the offset size Objective: having a representation that is as close as possible to the log 2 G size (in terms of bits) for G gaps 21/ 30 Unary and γ-codes number unary code length offset γ code , , , , , , , , γ-codes are always of odd length. More precisely, their length is 2 floor(log 2 s) + 1 γ-code for 6? 22/ 30 Example Given the following γ-coded gaps: Decode these, extract the gaps, and recompute the posting list NB: γ-decoding : 1. first reads the length (terminated by 0), 2. then uses this length to extract the offset, 3. and eventually prepends the missing 1 23/ 30 γ-codes (continued) How to evaluate the properties of a code? It depends on the distribution of gaps The coding properties of a probablility distribution P are related to its entropy H(P): H(P) = x X P(x)log 2 P(x) The expected length of a code C, called E(C), is such that: E(C) H(P) H(P) 3 This means that γ-codes always almost reach optimality (with a factor of 3) whatever the distribution is How good is a γ-encoding in terms of compression? 24/ 30

7 Compression rate of γ-codes Zipf s law: the frequency of the ith most common term f i is proportional to 1/i f i c i Rough analysis of the γ-encoding with this term distribution (H M is the harmonic number): 1 = M i=1 c = c i M i=1 1 = c H M i Thus: c = 1 1 H M lnm = 1 ln The expected average number of occurences of a term i in a document of length L is: L c i = i 15 i 25/ 30 Stratification of terms for estimation of compression L c most freq. terms N gaps of size 1 each L c next most freq. terms N/2 gaps of size 2 each L c next most freq. terms N/3 gaps of size 3 each 26/ 30 Compression rate of γ-codes (continued) Let us consider blocks of gaps of size 15 each Recall that the γ-code for 1 gap of size j requires 2 floor(log 2 j) + 1 bits To encode all gaps gathered in 1 block, we need (N/j is the number of gaps of size j): L c N j (2 floor(log 2 j) + 1) 2 N L c log 2 j j If we consider equi-distribution of gaps sizes, encoding all gaps requires: M/Lc j=1 2 N L c log 2 j j (M/L C = /15) j= log 2 j j 224MB 27/ 30 Compression of Reuters: Summary representation size in MB dictionary, fixed-width 19.2 dictionary, term pointers into string 10.8, with blocking, k = , with blocking & front coding 7.9 collection (text, xml markup etc) collection (text) postings, uncompressed (32-bit words) postings, uncompressed (20 bits) postings, variable byte encoded postings, γ encoded / 30

8 Conclusion Conclusion γ-codes achieve better compression ratios (about 15 % better than variable bytes encoding), but are more complex (expensive) to decode This cost applies on query processing trade-off to find The objectives announced are met by both techniques, recall: 1. reducing the disk space needed 2. reducing the time processing, by using a cache The techniques we have seen are lossless compression (no information is lost) Lossy compression can be useful, e.g. storing only the most relevant postings (more on this in the ranking lecture) 29/ 30 References Conclusion C. Manning, P. Raghavan and H. Schütze, Introduction to Information Retrieval (chapter 5) chapter05-compression.pdf F. Scholer, H.E. Williams, J. Yiannis and J. Zobel, Compression of Inverted Indexes for Fast Query Evaluation (2002) 30/ 30