> I chose MongoDB because it seemed very lightweight and the ease of changing the models.
This makes me think that the author didn't put enough effort into determining the right solution for this problem. Using something like MongoDB requires experience too, which the author lacked.
The author couldn't be more right about picking an asynchronous driver. It makes me wonder how long it will take for the official MongoDB drivers to adopt this approach too. I've been using ReactiveMongo for Scala for the past two months and would recommend it without hesitation.
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.
7 comments
[ 6.1 ms ] story [ 28.4 ms ] threadThis makes me think that the author didn't put enough effort into determining the right solution for this problem. Using something like MongoDB requires experience too, which the author lacked.
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.