That's super interesting!
I wonder what kinds of stuff you could do with that in a fancy datastore like Elasticsearch or GraphDB.
If it could be mapped to a resource model in a straightforward way, it'd be fun to make a special "ORM" that plugs into an API framework to expose public services.
Take bup (https://github.com/bup/bup/) for instance. It splits your content into chunks and stores them into GB-sized packs. With large backups you easily end up in hundreds of packs. During the splitting process it needs to search for a hash (the needle) into the huge amount of chunks (the haystack). That's why bup has one bloom filter per pack, which means that instead of searching through hundreds of packs you will have to search through maybe 2 or 3 packs. There are false positives (you know a hash can only realistically be contained in a single pack) but it is you the developer who choose how much you want. There is some complicated math that allows you to balance false positives, size of the structure, and expected number of elements.
There's a similar process inside LevelDB (http://leveldb.org/) and it's going to be the same thing for systems that store their data in multiple parts and know that what they're looking for actually is in a single part.