Tom, Can you link directly to the Bloom Filter implementation? It's not obvious from the main project page how to find it. Any time we can get people to think about computer science-y solutions to big data problems instead of just subscribing to RDBMS dogma, we win =).
While bloom filters are not a solution for everything, there are places where they would greatly improve performance. One place where you'd likely see huge benefits from bloom filters are in N x N comparison type of operations. Here's an example from RapLeaf: http://blog.rapleaf.com/dev/2007/09/05/bloomfilter/ By doing a single pass over all entities to build the initial filter, when you cross-check on the second pass, you can do the same operation in much less time if you know that matches tend to be sparse (for other folks reading this thread that are new to the concept: this means spread out - most comparison operations will be NO MATCH). In the N x N hash comparison example, you know that you are only going to do a write in the first phase with no deletes, and you know you will only be reading the filter later on so you can use local memory. -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Mon, Dec 12, 2011 at 5:07 PM, Tom Gibara <tomgib...@gmail.com> wrote: > I've used Bloom filters for a number of purposes, including the scenario > you describe - though not on App Engine. > > Bloom filters are an extremely versatile tool, but are not a panacea. > Firstly they aren't as compact as one might expect. By my reckoning, a 1MB > bloom filter will accommodate 1M entries with a false positive rate of > around 2%. A well implemented trie with a suitable set of keys can approach > similar levels of compactness. > > Secondly, Bloom filters are obviously sensitive to their initial sizing; > though they degrade gracefully, in some applications it can be difficult to > resize them in-situ without causing unacceptable spikes in throughput. > > Finally, just in case you hadn't considered it; Bloom filters don't > support element removal. This may or may not be an issue for your > application. > > Also, I'm not sure if Brandon's suggestion to consider "Short misses" was > targeted at storing more data in the Bloom filter. Bloom filter capacity is > independent of key size and smaller keys may result in poorer performance > due to weaker hashing. > > If it's any use I've made an open source Bloom filter > implementation available as part of my collections package at > http://code.google.com/p/tomgibara/ > > Tom. > > On 12 December 2011 03:17, John Tantalo <john.tant...@gmail.com> wrote: > >> I wonder whether anybody has tried to build an in-memory bloom filter in >> front of an index to reduce datastore read operations? >> >> In my application, I have an exact-match query on a single field, and it >> commonly matches no results. However, I still have to pay for datastore >> read operations in this case. >> >> My idea was to build a bloom filter on every value of the field in my >> datastore. Given a query input, if the bloom filter says the value is a >> member of the set, I will query the datastore for it, which may or may not >> match results (i.e., a false positive). >> >> The bloom filter would be wrapped in an app engine model and stored in >> the datastore and memcached. The write rate to the datastore for this index >> is rather low, so I plan to update the bloom filter transactionally and >> cache it on every write. The updates could also be done offline in a task >> queue. >> >> The goal is to reduce the cost of searches, especially in the "no >> matches" case. I believe this change would reduce costs on datastore read >> operations, but increase CPU time because each request would have to read >> and deserialize a potentially large bloom filter from memcached. Clearly, >> this tradeoff could be tuned to the needs of the app, as a larger bloom >> filter would produce fewer false positives and wasted datastore reads. >> >> Thoughts? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/google-appengine/-/ViVc7VJ8iOAJ. >> To post to this group, send email to google-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
