

MongoDB lessons - phektus
http://arbiesamong.com/mongodb-lessons-or-how-not-to-f-up-hard-when

======
voidr
> 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.

~~~
mh-
>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.

------
alexjarvis
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.

~~~
ymmy
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.

------
pacomerh
Anyone care the explain "2. Create your indexes as you develop." a little
deeper.

~~~
armon
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.

