8 ms·

A pattern I've seen on a lot of the negative Mongo articles has been people using it for things they probably shouldn't. I've yet to use it for any load, and a

by mtkd 13y ago

A pattern I've seen on a lot of the negative Mongo articles has been people using it for things they probably shouldn't. I've yet to use it for any load, and am struggling to triangulate from all the articles I read on whether it does/doesn't scale efficiently. All the issues I have hit so far have been self-inflicted, it is still one of the best new technologies I've used in years - but is has taken a while to stop thinking in SQL equivalents and start thinking natively.

otterley 13y ago
For what kind of application or workload is MongoDB superior to the alternatives?
- Xorlev 13y ago
  The kind that lives on a single VPS and requires a rich query layer to bootstrap quickly.
relistan 13y ago
Hopefully this article wasn't seen as bashing MongoDB. I think I mention it was pretty reliable for us even under load. We were just solving a problem with it for which it wasn't the best solution.
arohner 13y ago
> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would. It's impossible to configure a clustered mongo environment to not lose data: http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb Sharding configuration is baroque, and limited.
- francesca 13y ago
  The global lock was removed in 2.2 https://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/ https://blog.serverdensity.com/goodbye-global-lock-mongodb-2... Now locking is on the database level.
  - MichaelGG 13y ago
    That sorta makes it sound worse, honestly, if databases in MongoDB are anything like you'd use the word for in any other datastore. A global lock across all databases is mind-bogglingly confusing; what's one DB got to do with another? Couldn't you just work around that before by running a separate Mongo process per database? Saying it's now on the database still means any single-database app is globally locked. Or does using Mongo imply you're going to be making lots of databases so this actually means anything?
    - nasalgoat 13y ago
      That's what we do - dozens of databases, containing one collection. It's perverse.
- foobar1988 13y ago
  You could say the same about multi-master environments. Those are prime opportunities for losing data (eventually consistent does not mean consistent, it means data loss)
- snmaynard 13y ago
  > Implications: if you run a query in production that doesn't hit an index, all traffic stops Even if Mongo did have a global write lock, which it doesn't as has already been covered, it yields on page faults which means that other queries are minimally impacted. See: http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-or-write-operation-ever-yield-the-lock http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-...
  - arohner 13y ago
nasalgoat 13y ago
It doesn't. MongoDB is a dog, and I know this because I run hundreds of instances of it in a production environment. I need to use 10x as many hosts as I should to support less than 30K queries per second. The second I can migrate to another data store, I will. Unfortunately that kind of refactor isn't possible right now, but all new projects are using different tools.

by mtkd 13y ago

otterley 13y ago

For what kind of application or workload is MongoDB superior to the alternatives?

Xorlev 13y ago
The kind that lives on a single VPS and requires a rich query layer to bootstrap quickly.

relistan 13y ago

Hopefully this article wasn't seen as bashing MongoDB. I think I mention it was pretty reliable for us even under load. We were just solving a problem with it for which it wasn't the best solution.

arohner 13y ago

> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would. It's impossible to configure a clustered mongo environment to not lose data: http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb Sharding configuration is baroque, and limited.

francesca 13y ago
The global lock was removed in 2.2 https://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/ https://blog.serverdensity.com/goodbye-global-lock-mongodb-2... Now locking is on the database level.
- MichaelGG 13y ago
  That sorta makes it sound worse, honestly, if databases in MongoDB are anything like you'd use the word for in any other datastore. A global lock across all databases is mind-bogglingly confusing; what's one DB got to do with another? Couldn't you just work around that before by running a separate Mongo process per database? Saying it's now on the database still means any single-database app is globally locked. Or does using Mongo imply you're going to be making lots of databases so this actually means anything?
  - nasalgoat 13y ago
    That's what we do - dozens of databases, containing one collection. It's perverse.
foobar1988 13y ago
You could say the same about multi-master environments. Those are prime opportunities for losing data (eventually consistent does not mean consistent, it means data loss)
snmaynard 13y ago
> Implications: if you run a query in production that doesn't hit an index, all traffic stops Even if Mongo did have a global write lock, which it doesn't as has already been covered, it yields on page faults which means that other queries are minimally impacted. See: http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-or-write-operation-ever-yield-the-lock http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-...
- arohner 13y ago

nasalgoat 13y ago

It doesn't. MongoDB is a dog, and I know this because I run hundreds of instances of it in a production environment. I need to use 10x as many hosts as I should to support less than 30K queries per second. The second I can migrate to another data store, I will. Unfortunately that kind of refactor isn't possible right now, but all new projects are using different tools.