Looks like they may have added some complexity with their feed parser implementation, what they refer to as "supernoders". Looks like they don't lock ownership of feeds during parsing, thus allowing concurrent supernoders to get into race conditions while parsing the same feed.
And so it turns into another NoSQL example of employing conflict resolution to fix things.
I wonder if they could just use a simple locking scheme to prevent more than 1 parser from parsing the same feed at the same time. This sounds simpler than conflict resolution, to me.
You may want to check out Aphyr's "Call Me Maybe" series of posts about distributed databases: http://aphyr.com/tags/jepsen
The short version is that convergent conflict resolution seems intimidating but works better than locking and synchronization.
I don't see where it draws that conclusion at all.
The postgres post shows that even ACID databases have network error cases which can leave your client in an indeterminate state. Fair enough. However the solution for this is... to restart your client once the network's back up. All it needs to do is requery the DB to determine the truth.
Compare that to writing conflict resolution logic for all your data because there is no single source of truth. This is considerably more complicated.
The series actually ends up recommending "the right design for the right problem space." I am not making a general SQL vs. NoSQL argument here, but I think in this case they may have taken a more complicated approach than necessary.
Disclosure: I work at Basho, makers of the Riak database.
Assuming you are using Riak's default configuration each range query hits 1/3 of the cluster, which could get pretty hairy on large clusters that have lots of requests. Also, there is no pagination, so if an index has a million objects you'll have to be prepared to wait even if you only want the first part of the query.
You could solve this by putting a sort value in the key and using a range query, but this wouldn't work if you want the most recent items keyed with time, because the items could be unevenly spaced back in time. Also, Riak, like many databases based on Dynamo, thrives on fat data which one would think would favor lists. LevelDB is also supposedly slower than Bitcask, the default backend, but I'm not sure if this is still true.
I've been trying to think of ways around these problems. A simple thought I had was to simply cache the response as pages in Riak. Although this introduces new problems like how to know how often to reset the cache, too often and I may as well not have this cache, too infrequently and users get stale data. I would also have to handle this using worker threads because I wouldn't want the odd 100th user to get a big latency hit. The database would also either have to be continually polled, wasting CPU, or potentially not have the data cached when needed.
Another solution I've been considering is to write a secondary index layer on top of Riak using a skiplist or btree to know where to add and remove data when it gets to be very large. This seems like a cool idea, but might be tricky to implement and do conflict resolutions on.
My last idea was the most ambitious, which was to implement a separate distributed database specifically for secondary indexes and range queries which would not be bound by Dynamo. The idea here is to have each node in charge of a segment of the key space (like Big Table) and then have it split and coalesce not only based on size, but also on frequency of reads and writes to handle the bottleneck problem.
I initially was going to have this paired with the Dynamo database (https://github.com/dbunker/Dynago) I was experimenting with using Go and LevelDB, but there is no reason it couldn't work with any Key-Value eventually-consistent hyper-reliable database to provide light-weight secondary indexes. Having it constantly check the core key-value database would mean it wouldn't have to be super reliable in its own right and so could be kept relatively simple.
But again the simplest solution may ultimately be the way to go, I'm not sure, all these seem to have pretty big trade offs.
You could solve this by putting a sort value in the key and using a range query, but this wouldn't work if you want the most recent items keyed with time, because the items could be unevenly spaced back in time.
Pagination is coming soon; it's in riak_kv master already, but in buyer-beware #yolo territory.
LevelDB is also supposedly slower than Bitcask, the default backend, but I'm not sure if this is still true.
Bitcask is faster when all the keys fit in memory: it's designed to load any value with a single disk seek. LevelDB can't make that guarantee, but neither can Bitcask with too many keys for available memory.
I've been trying to think of ways around these problems. A simple thought I had was to simply cache the response as pages in Riak. Although this introduces new problems like how to know how often to reset the cache, too often and I may as well not have this cache, too infrequently and users get stale data.
Caching is one of the two hard problems in software engineering (along with "naming things" and "off-by-one errors"), so good luck :) If you're not opposed to running a separate service, Memcache is what I'd use.
(If anyone has a dedicated server with a high transfer cap, we could really use for temporary storage and uploading to IA. Email in profile.)
For anyone else doing an independent backup, you can get more than 1000 items by using ?r=n&n=1000 and following the continuation in the JSON response with a ?c= URL parameter. And keep in mind that Google doesn't canonicalize feed URLs for the same content, so you have to grab all of them.
You can email me for an rsync source that contains the work items we've generated. Right now this is about ~68.2M URLs, mostly on the big blog platforms. This list should grow considerably.
The only downside—and why I stopped using it—is that the pricing model is per-item, so if you have frequently updating feeds it can get very expensive. Although I never tried to use it, the pricing page does say they they'll meet whatever it costs you to run your own feed system since their cost should be lower than yours.
