He mentions the lack of joins, but doesn't say a word about Mapreduce.

"MongoDB needs to walk the index from the beginning to the offset..." You don't "walk an index". It's an index.

"Too many databases" sounds a little suspicious. Why not add an indexed field to partition records?

Complaining about a lack of schema, transactions and triggers? Really? Did you read the docs at all before starting?

MongoDB is not without its problems, but friend, I think you wanted either Postgres or Hadoop.

If you have an address book, you don't have to walk through the city to find an address, but you do have to look through your address book in some way or other. Of course, you can have an index of the index ("C starts at page 7"), but then you have to look through the index of the index.

HBase is multidimensional though, which allows you to keep N numbers of versions of a cell. By default you will get the latest version of the cell back, but you could also opt to receive N versions back, which is useful for time series use cases.

As far as I know, key design is not an important aspect with MongoDB but I could be mistaken. HBase has a pretty awesome book (http://www.hbasebook.com/), which has an entire chapter dedicated to key design. Lars (the author) also has a pretty in depth 1 hour video on key design (http://www.youtube.com/watch?v=_HLoH_PgrLk).

HBase is pretty widely used, I've seen 1200+ node clusters running production tables.

It's a good point that some of this can be achieved with indexing, I should have given more details in the blog post.