9 ms·

I really don't understand why people use MongoDB. It seems like it's a elegant technological metaphor (lets use mmap, the OS is our cache and we can overwrite

I really don't understand why people use MongoDB. It seems like it's a elegant technological metaphor (lets use mmap, the OS is our cache and we can overwrite in place in RAM) that in practise turns out to be a terrible idea. Overwrite/mmap cannot be made reliable, requires blocking write-locks, wastes disk, and causes problems shuffling data around as it grows. Add other bad decisions (keys aren't interned, seriously?)and it's just a terrible limping monster. Abandon it, walk away.

deleted 13y ago
[deleted]
aroman 13y ago
Because when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up. I have used mongodb for a number of smaller projects, and I have had an excellent experience. It's not "a terrible idea in practice". It might be a terrible fit for what you want, but that doesn't mean it's bad technology.
- JulianMorrison 13y ago
  Are you dead certain those projects aren't ever eating data, and nor are they about to crash tomorrow with an unrecoverably hosed DB? I still say it's bad technology. Use plain old SQL instead.
  - lmm 13y ago
    "plain old SQL" can require a lot of mangling one's data to fit its constraints. I refuse to believe that there isn't a better key-value store for the case where the values are json documents, even if mongodb isn't it.
    - gaius 13y ago
      Except it isn't "SQL" it's first-order predicate calculus - a provably sound way to store and query your data.
    - pwg 13y ago
      But if one is going to use a key-value store anyway, where is the "mangling"? Building a key-value store in an SQL database is trivial (this below is for PostgreSQL): create table keyvalue (key text, value text); create index keyvalue_idx on keyvalue(key); And use is trivial as well: insert into keyvalue (key, value) values ('key', 'value'); select value from keyvalue where key = 'key'; [edit] formatting fix.
      - lmm 13y ago
        It is not nice to have to manipulate JSON as a plain string (you miss out on validation, have to manually construct like expressions for queries, and I don't even want to think about what you'd have to do to update part of a document), at least using "plain old SQL". (PostgreSQL's native JSON support would make it quite easy, but that supports my point)
        snaky 13y ago
        If you need to query JSON content, why to store it like plain string, to begin with? Parse it at application level (or even in stored procedure) and store like ordinary fields. Or use hstore.
        kanja 13y ago
        Postgres additionally has a json field type.
        snaky 13y ago
        That is for now, until PostgreSQL 9.3 released, have only one useful feature comparing to plain string - validation. That's not much help, and that original lmm's point was about.
    - JulianMorrison 13y ago
      Redis. Riak. Rethinkdb. Cassandra (with a mapping layer). SQL (with a mapping layer). SQL, in a JSON-typed column (PostgreSQL supports it). SQL, in a blob field, plus indexes. I could go on.
- timr 13y ago
  "when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up." When you're not operating at significant scale, you can use a relational database. They're easy and fast to set up, have nice write-safety guarantees, are more flexible than a key-value store, and will scale well beyond anything that mongo has ever achieved. You can even use them as a key-value store! The downside, of course, is that you have to a tiny bit of knowledge about set theory, and that's a deal breaker for most "developers" today. The whole point of the GP was that Mongo isn't elegant or easy...it's just naive and short-sighted, and the architectural mistakes within it are fundamental and probably unfixable (at least, not without killing the speed advantages they claim). The real reason that people use mongo is that most webapp devs don't have a very good understanding of how computers work, and want everything to look like Javascript, because that's all they really know.
  - lucisferre 13y ago
    You lost me when you quoted the word "developers". Edit: And this is downvoted for calling out the fact that people on HN can't discuss a freakin' database without hurling insults.
    - timr 13y ago
      I quoted "developers", because we need a term to distinguish people who know basic computer science from people who know just enough to install software and piece together APIs. The latter group tends not to realize that things like overwriting your working set in memory and global write-locking lead inevitably to consistency and throughput issues. The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.
      - lucisferre 13y ago
        In the real world though, both groups still need to use what works in practice. It's entirely possible for MongoDB to work sufficiently well for a certain group of people in a reasonably cost effective way. Exaggerating its problems (as bad as they are) doesn't add weight to your agrement. For example, global write-locking will not _inevitably_ lead to consistency or throughput unless the write frequencies are sufficient to cause and require that. Lots of data problems aren't "big data", they're barely a medium. I'll agree MongoDB is not a terribly well engineered database however I don't agree that SQL is always the best alternative in these simpler scenarios. There are lots of things wrong with using SQL to solve every data problem. I also don't agree that knowing SQL is equivalent to understanding "set theory". I've known plenty of DBAs who don't know the first thing about set theory and really just know just enough to install the software and piece together the APIs. The fact that one has chosen SQL doesn't make them good at working with data any more than choosing MongoDB makes someone bad, or implies they don't understand "set theory". What concerns me mostly though isn't the MongoDB issue but that we can't discus the issue in a professional way, without elitism and distain dripping through. You seem to have confused "computer science" with "anything of value". I happen to believe there are more things worth knowing that are of value to practical software development than just the computer science (not to minimize that of course).
wslh 13y ago
> I really don't understand why people use MongoDB. Really? When I don't want to think in databases and only on persisting my native types in my favorite programming language MongoDB is my choice. I use it only for experimenting, so I don't care about all those scalability issues.
- JulianMorrison 13y ago
  Try Redis instead? Or rethinkdb (if you don't mind it being a bit new)?
  - wslh 13y ago
    No. The Redis interfaces doesn't abstract data types. For example Python types are quasi transparently interfaced with MongoDB. Was your comment a little bit ironic?
mratzloff 13y ago
I was required to use MongoDB in a recent large-scale analytics project. It is a disaster. I am in the process of replacing the most important metrics with Redis; I can't ditch Mongo fast enough.
snaky 13y ago
Because the koolaid is so sweet. MongoDB is every developer's wet dream. With it's expressive query syntax and extreme ease of use, everyone wants to drink the koolaid. This is a huge problem, because mongodb as a database is dangerous [..] I have developers begging me to let them use it. This time to collect logs from our servers for analysis later. I cave in, and give my go ahead, with a warning saying that no critical data can enter that section. Mongo processes were crashing. Several times per day. About 20% of the crashes yielded a completely corrupted database. This programmers wet dream quickly shows itself to be a serious operations nightmare. http://hackingdistributed.com/2013/02/07/10gen-response/#comment-792884602 http://hackingdistributed.com/2013/02/07/10gen-response/#com...
- deleted 13y ago
  [deleted]
nramirezuy 13y ago
Because is easy: * Easy to learn * Easy to use * Easy to deploy All easy things get us in troubles when we want high performance. Cheers;)
ams6110 13y ago
I think the author summed it up well: "There is a niche where MongoDB can work well." s/MongoDB/Any technology/g The size of the niche varies. The lesson is to be sure the choices you make are appropriate for your situation, and be aware that things may change if new requirements emerge or scale needs to go beyond what you projected. These concerns are not specific to MongoDB. It is a rare project that goes from prototype to small scale to large scale on its original implementation technology choices.
- JulianMorrison 13y ago
  MongoDB is the Pinto of databases. It is not safe at any scale.
rdtsc 13y ago
Marketing. They are also on my blacklist, forever. They used to ship with unacknowledged writes as the default option. Think about it for a little, a database that just throws your _data_ over the fence and prays for the best, proceeding without an write acknowledgement. There was not flashing warning on their front page about, no bold disclaimers, but there were sure plenty of "Oh look super fast benchmarks beating SQL and other NoSQL database, albeit created by fanboys". That decision told me the story of who they are and what kind of principles they use to build their product. It wasn't a mistake it was a deliberate shady tactic employed. (Yes, I know I have written about it at least 3 times before and will mention it every time I see MongoDB mentioned )
- est 13y ago
  So can you tell us what's your easieast way to implement something like: books: [ {id: 1, tags: ['a', 'b'], author: ['c', 'd'], count_read: 123, count_bought: 456}, ] where count_read and count_bought is atomic increment, tags are arbitrary string array and could be indexed for searching. Yeah I knew Postgre could do that. But MongoDB is the most simple and direct way on the market. Stuff like tags makes MySQL m2m joins very inefficient.

deleted 13y ago

[deleted]

aroman 13y ago

Because when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up. I have used mongodb for a number of smaller projects, and I have had an excellent experience. It's not "a terrible idea in practice". It might be a terrible fit for what you want, but that doesn't mean it's bad technology.

JulianMorrison 13y ago
Are you dead certain those projects aren't ever eating data, and nor are they about to crash tomorrow with an unrecoverably hosed DB? I still say it's bad technology. Use plain old SQL instead.
- lmm 13y ago
  "plain old SQL" can require a lot of mangling one's data to fit its constraints. I refuse to believe that there isn't a better key-value store for the case where the values are json documents, even if mongodb isn't it.
  - gaius 13y ago
    Except it isn't "SQL" it's first-order predicate calculus - a provably sound way to store and query your data.
  - pwg 13y ago
    But if one is going to use a key-value store anyway, where is the "mangling"? Building a key-value store in an SQL database is trivial (this below is for PostgreSQL): create table keyvalue (key text, value text); create index keyvalue_idx on keyvalue(key); And use is trivial as well: insert into keyvalue (key, value) values ('key', 'value'); select value from keyvalue where key = 'key'; [edit] formatting fix.
    - lmm 13y ago
      It is not nice to have to manipulate JSON as a plain string (you miss out on validation, have to manually construct like expressions for queries, and I don't even want to think about what you'd have to do to update part of a document), at least using "plain old SQL". (PostgreSQL's native JSON support would make it quite easy, but that supports my point)
      - snaky 13y ago
        If you need to query JSON content, why to store it like plain string, to begin with? Parse it at application level (or even in stored procedure) and store like ordinary fields. Or use hstore.
        kanja 13y ago
        Postgres additionally has a json field type.
        snaky 13y ago
        That is for now, until PostgreSQL 9.3 released, have only one useful feature comparing to plain string - validation. That's not much help, and that original lmm's point was about.
  - JulianMorrison 13y ago
    Redis. Riak. Rethinkdb. Cassandra (with a mapping layer). SQL (with a mapping layer). SQL, in a JSON-typed column (PostgreSQL supports it). SQL, in a blob field, plus indexes. I could go on.
timr 13y ago
"when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up." When you're not operating at significant scale, you can use a relational database. They're easy and fast to set up, have nice write-safety guarantees, are more flexible than a key-value store, and will scale well beyond anything that mongo has ever achieved. You can even use them as a key-value store! The downside, of course, is that you have to a tiny bit of knowledge about set theory, and that's a deal breaker for most "developers" today. The whole point of the GP was that Mongo isn't elegant or easy...it's just naive and short-sighted, and the architectural mistakes within it are fundamental and probably unfixable (at least, not without killing the speed advantages they claim). The real reason that people use mongo is that most webapp devs don't have a very good understanding of how computers work, and want everything to look like Javascript, because that's all they really know.
- lucisferre 13y ago
  You lost me when you quoted the word "developers". Edit: And this is downvoted for calling out the fact that people on HN can't discuss a freakin' database without hurling insults.
  - timr 13y ago
    I quoted "developers", because we need a term to distinguish people who know basic computer science from people who know just enough to install software and piece together APIs. The latter group tends not to realize that things like overwriting your working set in memory and global write-locking lead inevitably to consistency and throughput issues. The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.
    - lucisferre 13y ago
      In the real world though, both groups still need to use what works in practice. It's entirely possible for MongoDB to work sufficiently well for a certain group of people in a reasonably cost effective way. Exaggerating its problems (as bad as they are) doesn't add weight to your agrement. For example, global write-locking will not _inevitably_ lead to consistency or throughput unless the write frequencies are sufficient to cause and require that. Lots of data problems aren't "big data", they're barely a medium. I'll agree MongoDB is not a terribly well engineered database however I don't agree that SQL is always the best alternative in these simpler scenarios. There are lots of things wrong with using SQL to solve every data problem. I also don't agree that knowing SQL is equivalent to understanding "set theory". I've known plenty of DBAs who don't know the first thing about set theory and really just know just enough to install the software and piece together the APIs. The fact that one has chosen SQL doesn't make them good at working with data any more than choosing MongoDB makes someone bad, or implies they don't understand "set theory". What concerns me mostly though isn't the MongoDB issue but that we can't discus the issue in a professional way, without elitism and distain dripping through. You seem to have confused "computer science" with "anything of value". I happen to believe there are more things worth knowing that are of value to practical software development than just the computer science (not to minimize that of course).

wslh 13y ago

> I really don't understand why people use MongoDB. Really? When I don't want to think in databases and only on persisting my native types in my favorite programming language MongoDB is my choice. I use it only for experimenting, so I don't care about all those scalability issues.

JulianMorrison 13y ago
Try Redis instead? Or rethinkdb (if you don't mind it being a bit new)?
- wslh 13y ago
  No. The Redis interfaces doesn't abstract data types. For example Python types are quasi transparently interfaced with MongoDB. Was your comment a little bit ironic?

mratzloff 13y ago

I was required to use MongoDB in a recent large-scale analytics project. It is a disaster. I am in the process of replacing the most important metrics with Redis; I can't ditch Mongo fast enough.

snaky 13y ago

Because the koolaid is so sweet. MongoDB is every developer's wet dream. With it's expressive query syntax and extreme ease of use, everyone wants to drink the koolaid. This is a huge problem, because mongodb as a database is dangerous [..] I have developers begging me to let them use it. This time to collect logs from our servers for analysis later. I cave in, and give my go ahead, with a warning saying that no critical data can enter that section. Mongo processes were crashing. Several times per day. About 20% of the crashes yielded a completely corrupted database. This programmers wet dream quickly shows itself to be a serious operations nightmare. http://hackingdistributed.com/2013/02/07/10gen-response/#comment-792884602 http://hackingdistributed.com/2013/02/07/10gen-response/#com...

deleted 13y ago
[deleted]

nramirezuy 13y ago

Because is easy: * Easy to learn * Easy to use * Easy to deploy All easy things get us in troubles when we want high performance. Cheers;)

ams6110 13y ago

I think the author summed it up well: "There is a niche where MongoDB can work well." s/MongoDB/Any technology/g The size of the niche varies. The lesson is to be sure the choices you make are appropriate for your situation, and be aware that things may change if new requirements emerge or scale needs to go beyond what you projected. These concerns are not specific to MongoDB. It is a rare project that goes from prototype to small scale to large scale on its original implementation technology choices.

JulianMorrison 13y ago
MongoDB is the Pinto of databases. It is not safe at any scale.

rdtsc 13y ago

Marketing. They are also on my blacklist, forever. They used to ship with unacknowledged writes as the default option. Think about it for a little, a database that just throws your _data_ over the fence and prays for the best, proceeding without an write acknowledgement. There was not flashing warning on their front page about, no bold disclaimers, but there were sure plenty of "Oh look super fast benchmarks beating SQL and other NoSQL database, albeit created by fanboys". That decision told me the story of who they are and what kind of principles they use to build their product. It wasn't a mistake it was a deliberate shady tactic employed. (Yes, I know I have written about it at least 3 times before and will mention it every time I see MongoDB mentioned )

est 13y ago
So can you tell us what's your easieast way to implement something like: books: [ {id: 1, tags: ['a', 'b'], author: ['c', 'd'], count_read: 123, count_bought: 456}, ] where count_read and count_bought is atomic increment, tags are arbitrary string array and could be indexed for searching. Yeah I knew Postgre could do that. But MongoDB is the most simple and direct way on the market. Stuff like tags makes MySQL m2m joins very inefficient.