* If you have a read-heavy workload, it should perform pretty well
* While it lacks transactions, MongoDB supports some fairly powerful atomic operations which make it fairly flexible
* It's all fun and games until you start sharding, which adds a huge amount of complexity and administrative troubles; a few gotchas I ran into: mongoc lists in mongos configs are order sensitive, if they're out of order, your cluster will fail after some indeterminate amount of time and you'll have to step down the primary to fix it, if a mongoc instance goes down, mongos will keep querying it, indefinitely. So every query will get the added latency of that timeout. The proposed workaround from the MongoDB folks was to use a script to firewall off the offending mongoc (what?).
* Rebalancing is a clusterfuck. You can either wait for every write to propagate to your slaves (could literally take weeks), orrrr... disable this "throttle" and get balls-to-the-wall rebalancing which, in my case, pushed the write lock to the point if was dramatically effecting application performance. You basically have to write your own script to deal with this correctly. Rebalancing requires careful planning.
* There's still only only db level locking, so you'll need a db per-collection in many cases, which means you'll need a connection pool per db (and even a mongos instance per db), which can add up to a LOT of connections (thousands)
* 16MB limit for aggregation framework! Because the result of EACH STAGE of aggregation is stored in a document, NO PART of your pipeline can exceed 16MB! This is a huge and very frustrating limitation (though I understand this will be addressed in 2.6). Map/reduce is an option, but far from ideal
What I like:
Very flexible, easy to configure (save sharding), great for prototyping!
Aggregation framework! Building queries as a data pipeline is very cool.
What I don't like:
Does not handle write load well (having had to scale writes in production, even w/ SSDs and sharding), but I can see a read-heavy unsharded application working splendidly. Compression seems poor, but I have no hard numbers to back this up.
But keep in mind, mongo is still improving. I would say its still beta-quality (but not marketed as such! tsk tsk!), but 2.6 is literally right around the corner (they're on RC1 now IIRC)
* If you have a read-heavy workload, it should perform pretty well
* While it lacks transactions, MongoDB supports some fairly powerful atomic operations which make it fairly flexible
* It's all fun and games until you start sharding, which adds a huge amount of complexity and administrative troubles; a few gotchas I ran into: mongoc lists in mongos configs are order sensitive, if they're out of order, your cluster will fail after some indeterminate amount of time and you'll have to step down the primary to fix it, if a mongoc instance goes down, mongos will keep querying it, indefinitely. So every query will get the added latency of that timeout. The proposed workaround from the MongoDB folks was to use a script to firewall off the offending mongoc (what?).
* Rebalancing is a clusterfuck. You can either wait for every write to propagate to your slaves (could literally take weeks), orrrr... disable this "throttle" and get balls-to-the-wall rebalancing which, in my case, pushed the write lock to the point if was dramatically effecting application performance. You basically have to write your own script to deal with this correctly. Rebalancing requires careful planning.
* There's still only only db level locking, so you'll need a db per-collection in many cases, which means you'll need a connection pool per db (and even a mongos instance per db), which can add up to a LOT of connections (thousands)
* 16MB limit for aggregation framework! Because the result of EACH STAGE of aggregation is stored in a document, NO PART of your pipeline can exceed 16MB! This is a huge and very frustrating limitation (though I understand this will be addressed in 2.6). Map/reduce is an option, but far from ideal
What I like: Very flexible, easy to configure (save sharding), great for prototyping!
Aggregation framework! Building queries as a data pipeline is very cool.
What I don't like: Does not handle write load well (having had to scale writes in production, even w/ SSDs and sharding), but I can see a read-heavy unsharded application working splendidly. Compression seems poor, but I have no hard numbers to back this up.
But keep in mind, mongo is still improving. I would say its still beta-quality (but not marketed as such! tsk tsk!), but 2.6 is literally right around the corner (they're on RC1 now IIRC)