Index compression CE-324: Modern Information Retrieval Sharif - - PowerPoint PPT Presentation
Index compression CE-324: Modern Information Retrieval Sharif University of Technology M. Soleymani Fall 2017 Most slides have been adapted from: Profs. Manning, Nayak & Raghavan (CS-276, Stanford) Ch. 5 Today Collection statistics
Sharif University of Technology
Most slides have been adapted from: Profs. Manning, Nayak & Raghavan (CS-276, Stanford)
2
Saves a little money
Increases speed
[read compressed data + decompress] is faster than
Premise: Decompression algorithms are fast
True of the decompression algorithms we use
3
Make it small enough to keep in main memory Make it so small that you can keep some postings lists in main
Reduce disk space needed Decrease time needed to read postings lists from disk Large search engines keep a significant part of the postings in
Compression lets you keep more in memory
4
5
6
7
What we mostly do in IR.
case folding, stop words, stemming, number elimination.
Almost no loss quality for top k list.
8
9
10
11
to support high query throughput
That is, how many distinct words are there?
Not really:At least 7020 = 1037 different words of length 20
Especially with Unicode
12
M: # terms T : # tokens Typical values: 30 ≤ k ≤ 100 and b ≈ 0.5
Heaps’ law predicts a line with slope about ½ It is the simplest possible relationship between the two in log-
An empirical finding (“empirical law”)
13
14
𝑁 = 101.64𝑈0.49 k = 101.64 ≈ 44 b = 0.49.
15
We allow 20 bytes for 1 letter terms Also we still can’t handle supercalifragilisticexpialidocious or
How do we use ~8 characters per dictionary term?
16
Freq. Postings ptr. Term ptr. 33 29 44 126
17
18
Example below: k=4.
Freq. Postings ptr. Term ptr. 33 29 44 126 7
19
Where we used 3 bytes/pointer without blocking
20
21
Then linear search through terms in block.
22
Sorted words commonly have long common prefix
store differences only (for last k-1 in a block of k)
23
24
25
factor of at least 10.
A posting for our purposes is a docID.
Alternatively, we can use log2 800,000 ≈ 20 bits per docID.
26
27
we would like to store this posting using log2 1M ~ 20 bits.
20 bits/posting is too expensive. Prefer 0/1 bitmap vector in this case
computer: 33,47,154,159,202 …
33,14,107,5,43 …
28
29
30
31
32
33
𝑗 ∝ 1
34
We want to use ~log2𝐻 bits/gap entry.
For a gap value G, we want to use close to log2 G bits
using short codes for small numbers
35
If G ≤127, binary-encode it in the 7 available bits Else encode G’s lower-order 7 bits and then use additional
At the end: set the continuation bits
the last byte c =1 other bytes c = 0.
36
32 bits (words), 16 bits, 4 bits (nibbles). Variable byte may waste space when many small gaps (nibbles
Used by many commercial/research systems Good low-tech blend of variable-length coding and sensitivity
vs. bit-level codes, which we look at next
37
3:1110 38:111111111111111111111111111111111111110
38
Gamma code: the best known bit-level.
Offset: G in binary, with the leading bit cut off
E.g., 13 → 1101 → 101
Length: length of offset encoded with unary code
E.g., 13 (offset 101), length is 3 → 1110.
Gamma code: length + offset
E.g., 13 → 1110101
39
40
Offset: log G bits Length: log G + 1 bits
always have an odd number of bits almost within a factor of 2 of best possible (log2 G) uniquely prefix-decodable, likeVB can be used for any distribution parameter-free
41
Operations that cross word boundaries are slower Compressing and manipulating at the granularity of bits can be
42
43
Only 4% of the total size of the collection Only 10-15% of the total size of the text in the collection
But techniques substantially the same.
44