MongoDB lessons

>Sharding also assumes a replica set, which will help bring in secondaries when your primary goes down.

I'm not sure they used more than a single mongod. I'm not sure any datastore would have been forgiving of the lack of attention to best practices.

Asynchronous driver isn't always needed, but he was working with Tornado, an asynchronous framework. Using anything non asynchronous that has the possibility to block for any significant period of time (i.e. network call or database call) with tornado defeats the whole purpose. Hardly MongoDB's fault.

I'm guessing the authors deployed to production with no indexes on their collections. This means the cost of most queries was probably O(n). This could go unnoticed in development where N is small, but is unacceptable once you have any real data. I think they are recommending thinking about and adding indexes while you are developing as opposed to trying to do so post-hoc, once queries are taking tens of seconds.

MongoDB is basically unusable without indexes even under the slightest load.