Garbage collection with a very large dictionary

Question

I have a very large immutable set of keys that doesn't fit in memory, and an even larger list of references, which must be scanned just once. How can the mark phase be done in RAM? I do have a possible solution, which I will write as an answer later (don't want to spoil it), but maybe there are other solutions I didn't think about.

I will try to restate the problem to make it more "real":

You work at Facebook, and your task is to find which users didn't ever create a post with an emoji. All you have is the list of active user names (around 2 billion), and the list of posts (user name / text), which you have to scan, but just once. It contains only active users (you don't need to validate them).

Also, you have one computer, with 2 GB of RAM (bonus points for 1 GB). So it has to be done all in RAM (without external sort or reading in sorted order). Within two day.

Can you do it? How? Tips: You might want to use a hash table, with the user name as the key, and one bit as the value. But the list of user names doesn't fit in memory, so that doesn't work. With user ids it might work, but you just have the names. You can scan the list of user names a few times (maybe 40 times, but not more).

Answer 1

Sounds like a problem I tackled 10 years ago.

The first stage: ditch GC. The overhead of GC for small objects (a few bytes) can be in excess of 100%.

The second stage: design a decent compression scheme for user names. English has about 3 bits per character. Even if you allowed more characters, the average amount of bits won't rise fast.

Third stage: Create dictionary of usernames in memory. Use a 16 bit prefix of each username to choose the right sub-dictionary. Read in all usernames, initially sorting them just by this prefix. Then sort each dictionary in turn. As noted in the question, allocate one extra bit per username for the "used emoji" result.

The problem is now I/O bound, as the computation is embarrassingly parallel. The longest phase will be reading in all the posts (which is going to be many TB).

Note that in this setup, you're not using fancy data types like String. The dictionaries are contiguous memory blocks.

Given a deadline of two days, I would however dump some of this this fanciness. The I/O bound for reading the text is severe enough that the creation of the user database may exceed 16 GB. Yes, that will swap to disk. Big deal for a one-off.

Answer 2

Hash the keys, sort the hashes, and store sorted hashes in compressed form.

TL;DR

The algorithm I propose may be considered as an extension to the solution for similar (simpler) problem.

1. To each key: apply a hash function that maps keys to integers in range [0..h]. It seems to be reasonably good to start with h = 2 * number_of_keys.
2. Fill all available memory with these hashes.
3. Sort the hashes.
4. If hash value is unique, write it to the list of unique hashes; otherwise remove all copies of it and write it to the list of duplicates. Both these lists should be kept in compressed form: as difference between adjacent values, compressed with optimal entropy coder (like arithmetic coder, range coder, or ANS coder). If the list of unique hashes was not empty, merge it with sorted hashes; additional duplicates may be found while merging. If the list of duplicates was not empty, merge new duplicates to it.
5. Repeat steps 1..4 while there are any unprocessed keys.
6. Read keys several more times while performing steps 1..5. But ignore all keys that are not in the list of duplicates from previous pass. For each pass use different hash function (for anything except matching with the list of duplicates from previous pass, which means we need to sort hashes twice, for 2 different hash functions).
7. Read keys again to convert remaining list of duplicate hashes into list of plain keys. Sort it.
8. Allocate array of 2 billion bits.
9. Use all unoccupied memory to construct an index for each compressed list of hashes. This could be a trie or a sorted list. Each entry of the index should contain a "state" of entropy decoder which allows to avoid decoding compressed stream from the very beginning.
10. Process the list of posts and update the array of 2 billion bits.
11. Read keys once more co convert hashes back to keys.

While using value h = 2*number_of_keys seems to be reasonably good, we could try to vary it to optimize space requirements. (Setting it too high decreases compression ratio, setting it too low results in too many duplicates).

This approach does not guarantee the result: it is possible to invent 10 bad hash functions so that every key is duplicated on every pass. But with high probability it will succeed and most likely will need about 1GB RAM (because most compressed integer values are in range [1..8], so each key results in about 2..3 bits in compressed stream).

To estimate space requirements precisely we might use either (complicated?) mathematical proof or complete implementation of algorithm (also pretty complicated). But to obtain rough estimation we could use partial implementation of steps 1..4. See it on Ideone. It uses variant of ANS coder named FSE (taken from here: https://github.com/Cyan4973/FiniteStateEntropy) and simple hash function implementation (taken from here: https://gist.github.com/badboy/6267743). Here are the results:

Key list loads allowed:     10           20
Optimal h/n:                 2.1          1.2
Bits per key:                2.98         2.62
Compressed MB:             710.851      625.096
Uncompressed MB:            40.474        3.325
Bitmap MB:                 238.419      238.419
MB used:                   989.744      866.839
Index entries:           1'122'520    5'149'840
Indexed fragment size:    1781.71       388.361

With the original OP limitation of 10 key scans optimal value for hash range is only slightly higher (2.1) than my guess (2.0) and this parameter is very convenient because it allows using 32-bit hashes (instead of 64-bit ones). Required memory is slightly less than 1GB, which allows to use pretty large indexes (so step 10 would be not very slow). Here lies a little problem: these results show how much memory is consumed at the end, but in this particular case (10 key scans) we temporarily need more than 1 GB memory while performing second pass. This may be fixed if we drop results (unique hashes) of the first first pass and recompute them later, together with step 7.

With not so tight limitation of 20 key scans optimal value for hash range is 1.2, which means algorithm needs much less memory and allows more space for indexes (so that step 10 would be almost 5 times faster).

Loosening limitation to 40 key scans does not result in any further improvements.

Answer 3

Minimal perfect hashing

Create a minimal perfect hash function (MPHF). At around 1.8 bits per key (using the RecSplit algorithm), this uses about 429 MB. (Here, 1 MB is 2^20 bytes, 1 GB is 2^30 bytes.) For each user, allocate one bit as a marker, about 238 MB. So memory usage is around 667 MB. Then read the posts, for each user calculate the hash, and set the related bit if needed. Read the user table again, calculate the hash, check if the bit is set.

Generation

Generating the MPHF is a bit tricky, not because it is slow (this may take around 30 minutes of CPU time), but due to memory usage. With 1 GB or RAM, it needs to be done in segments. Let's say we use 32 segments of about the same size, as follows:

• Loop segmentId from 0 to 31.
• For each user, calculate the hash code, modulo 32 (or bitwise and 31).
• If this doesn't match the current segmentId, ignore it.
• Calculate a 64 bit hash code (using a second hash function), and add that to the list.
• Do this until all users are read.
• A segment will contain about 62.5 million keys (2 billion divided by 32), that is 238 MB.
• Sort this list by key (in place) to detect duplicates. With 64 bit entries, the probability of duplicates is very low, but if there are any, use a different hash function and try again (you need to store which hash function was used).
• Now calculate the MPHF for this segment. The RecSplit algorithm is the fastest I know. The CHD algorithm can be used as well, but needs more space / is slower to generate.
• Repeat until all segments are processed.

The above algorithm reads the user list 32 times. This could be reduced to about 10 if more segments are used (for example one million), and as many segments are read, per step, as fits in memory. With smaller segments, less bits per key are needed to the reduced probability of duplicates within one segment.

Answer 4

The simplest solution I can think of is an old-fashioned batch update program. It takes a few steps, but in concept it's no more complicated than merging two lists that are in memory. This is the kind of thing we did decades ago in bank data processing.

1. Sort the file of user names by name. You can do this easily enough with the Gnu sort utility, or any other program that will sort files larger than what will fit in memory.
2. Write a query to return the posts, in order by user name. I would hope that there's a way to get these as a stream.
3. Now you have two streams, both in alphabetic order by user name. All you have to do is a simple merge:

Here's the general idea:

currentUser = get first user name from users file
currentPost = get first post from database stream
usedEmoji = false
while (not at end of users file and not at end of database stream)
{
    if currentUser == currentPostUser
    {
        if currentPost has emoji
        {
            usedEmoji = true
        }
        currentPost = get next post from database
    }
    else if currentUser > currentPostUser
    {
        // No user for this post. Get next post.
        currentPost = get next post from database
        usedEmoji = false
    }
    else
    {
        // Current user is less than post user name.
        // So we have to switch users.
        if (usedEmoji == false)
        {
            // No post by this user contained an emoji
            output currentUser name
        }
        currentUser = get next user name from file
    }
}
// at the end of one of the files.
// Clean up.

// if we reached the end of the posts, but there are still users left,
// then output each user name.
// The usedEmoji test is in there strictly for the first time through,
// because the current user when the above loop ended might have had
// a post with an emoji.
while not at end of user file
{
    if (usedEmoji == false)
    {
        output currentUser name
    }
    currentUser = get next user name from file
    usedEmoji = false
}

// at this point, names of all the users who haven't
// used an emoji in a post have been written to the output.

An alternative implementation, if obtaining the list of posts as described in #2 is overly burdensome, would be to scan the list of posts in their natural order and output the user name from any post that contains an emoji. Then, sort the resulting file and remove duplicates. You can then proceed with a merge similar to the one described above, but you don't have to explicitly check if post has an emoji. Basically, if a name appears in both files, then you don't output it.