Be careful with this trick. Although it appears to work well for Riak, it can cause lots of problems for BigTable style stores, like HBase, since it bottlenecks all the writes through one node.
It should be noted that Riak uses consistent hashing (where you route a key based on the Murmur or FNV hash of its md5 checksum) and virtual nodes. That means that even if keys are next to each other, they will get routed to different virtual nodes. Even in a single virtual node is "hot", virtual nodes do not map 1-to-1 onto physical nodes.
BigTable uses token ranges, which allows for range queries, but makes it vulnerable to this kind of a situation. This, however, shouldn't be needed with BigTable or HBase as BigTable and HBase use LSMs instead of a conventional B-Tree (what InnoDB -- which is what Innostore uses -- is): all writes and updates are strictly sequential, so this kind of "trick" is not needed.
[Disclaimer: Voldemort developer here, we use consistent hashing, virtual nodes and -- by default -- a log structured B+Tree from BerkeleyDB Java Edition]
See: http://ikaisays.com/2011/01/25/app-engine-datastore-tip-mono...
HBase (and I've heard BigTable) work best with purely random row keys - like the author of this post was using initially.