9 ms·

The growing irrelevance of MongoDB

92 points by jraedisch 12y ago

jraedisch 12y ago
If transactions are the biggest problems, there are driver solutions like http://godoc.org/labix.org/v2/mgo/txn http://godoc.org/labix.org/v2/mgo/txn for that. I am not sure, how they compare to "real" transactions. Still missing "joining" in some cases though. Otherwise I am ok with MongoDB so far.
- stephen123 12y ago
  If another host connects to the db, and the transaction doesn't span to that second host. Its not as safe as sql transactions.
  - niemeyer 12y ago
    The transaction does span across hosts with the linked package.
- politician 12y ago
  Jeez. Please do not mention client-library-managed transactions and then put "real" transactions in scare quotes. At least read the Wikipedia article first.
  - jraedisch 12y ago
    I just wanted to distinguish between the two. I wasn't scared in any way but read up on scare quotes now - so thanks for that. http://en.wikipedia.org/wiki/Scare_quotes http://en.wikipedia.org/wiki/Scare_quotes
  - StavrosK 12y ago
    I didn't read it like that at all, I interpreted it as the gp distinguishing between the two.
- niemeyer 12y ago
  There are further details about how it works in this blog post: http://blog.labix.org/2012/08/22/multi-doc-transactions-for-mongodb http://blog.labix.org/2012/08/22/multi-doc-transactions-for-... While it does work, it's still a workaround for the lack of first-class transactions in MongoDB. It offers a more limited API and requires care on the developer side. Despite being the author, I do hope it gets obsoleted by more convenient first-class transaction support in MongoDB itself at some point in the near future.
crzrcn 12y ago
The submission url is malformed :(.
- tech-no-logical 12y ago
  I think it should be http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60
jnaour 12y ago
Probably this link: http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60
scarygliders 12y ago
Site seems to be overloaded or broken in some other way. Google cache : http://webcache.googleusercontent.com/search?q=cache:wwwdesigned.com/growing-irrelevance-mongodb/ http://webcache.googleusercontent.com/search?q=cache:wwwdesi...
collyw 12y ago
I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be suited to rather than actually building anything.
- Harrisburg 12y ago
  Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain for all products, others will vary, some will change and will be dropped. Some may be conditional, depending on size or color. I could model that in RDBMS as well, adding those properties in an additional JSON or something else. Yes, I'm also mainly using relational databases and just wanted to give an example of a use-case for MongoDB. I regret, sorry.
  - rjaco31 12y ago
    Care to elaborate? Beside maybe for the suggestion system, I really don't see what's the gain compared to a relational database.
    - BonoboBoner 12y ago
      Probably the EAV nightmare
      - arethuza 12y ago
        Stick JSON in a field within your relational model - best of both worlds.
Harrisburg 12y ago
I can't agree. MongoDB 2.8 with WiredTiger is a performant NoSQL solution. The way you solve things in document dbs like MongoDB is the key - not the fact that you get competitve performance in RDBMS as well. I like Postgres and the possibility to easily use JSON data. But I still prefer to build applications the NoSQL way...
bigiain 12y ago
MongoDB 2.8 (in RC4 right now, due out "in early January" last I heard) has the WiredTiger storage engine, and as well as high performance and compression also gets document level locking and multi document transactions. The roadmap says this'll become the default storage engine in 3.0 (3rd quarter 2015). I think the blog author's claim that for basically those omissions "MongoDB can still beat TokuMX on a future release. But only in a future release. Today it can’t." observation is only true if you ignore the development releases completely, and will be incorrect within a week or two. Sure, if you want SQL or traditional relational database, a traditional relational SQL database is a better choice. Using Postgres or Oracle for workloads better suited to tied hashes or BerkleyDB doesn't automatically become "right" though.
- jraedisch 12y ago
  Could you provide a source for "multi document transactions" support in 2.8? According to this comment they are supported by WiredTiger but won't be in the MongoDB API anytime soon: http://blog.mongodb.org/post/102461818738/announcing-mongodb-2-8-0-rc0-release-candidate-and#comment-1710534263 http://blog.mongodb.org/post/102461818738/announcing-mongodb...
  - dm_mongodb 12y ago
    you are correct, that's not in 2.8. might want to follow this jira: https://jira.mongodb.org/browse/SERVER-11500 https://jira.mongodb.org/browse/SERVER-11500 that said it will be a big release in other aspects, with pluggable storage engines now, and WiredTiger specifically.
nchelluri 12y ago
Unfortunately I didn't find much information in the article. Basically I got out of it: - he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web framework/AngularJS/Node.js) - he found that for document oriented purposes MongoDB could sometimes be a nice fit - he found that replacing MongoDB with the drop-in replacement TokuMx (seems like a MySQL/MariaDB type of idea), he could get a big performance increase - he found that with Postgres 9.2+ using the JSON/document storage there he could get some of the relational benefits and some of the document benefits, and ACID - he likes ACID because of transactions/handling multiple documents at once Ok, so I guess I was wrong, there is a bit there. But: this is all stuff that I've heard several times about MongoDB. One of the things he got into was that he learned when MongoDB was appropriate and when it wasn't -- but IMO he didn't really go into detail here other than to say: joins and transactions. I wish there was more substance than that. I also seem to recall reading recently that even supposedly ACID compliant databases have problems with transactions under load and that the only way to really get full ACID compliance is to treat transactions as serializable - perhaps I am wrong but I think this is the gist of what I've learned. Personally, I'm working on a project right now that uses MongoDB and I definitely do miss joins, transactions, and schemas. I am not even remotely sure where one would benefit from a system that had documents with arbitrary fields in it. (I didn't pick the technologies for my project.) I would really like to know when to choose which database - I feel like I know the bare basics of several, and none of them in depth. I really don't have time to learn them all. I feel like even when I'm building one application it's only some months after deployment that if I'm lucky or made a mistake that I will run into some actual performance constraint.
- crdoconnor 12y ago
  >I would really like to know when to choose which database I have asked this question before - under what situations is Mongo not just equally good as Postgres - but actually better? The only really coherent answer was that it was easier to configure replication (presumably because it chooses a lot of defaults for you). I'm not even sure that was a good thing given the number of obscure bugs that can arise from incorrectly configured replication. Postgres even seems to be more performant at NoSQL use cases (using the JSON store) than Mongo, which is frankly embarrassing.
gasping 12y ago
MongoDB will always be a relevant example of false advertising and over-marketing (to the point of 10gen probably opening themselves to litigation) and how we all need to stop drinking the kool-aid. There is LITERALLY no reason to use MongoDB today. If you're thinking of using MongoDB, for the love of god just try PostgreSQL.
- mwj 12y ago
  this is a ridiculous comment. we use a mongodb cluster for a multi-hundred GB document store that powers ~50 various worker instances, 2 sites and an API with sub 100ms response times. we have never lost data or experienced downtime worse than other dbs i've used in the past. at the end of the day you just need to do your job properly and read the documentation, not blame the tool when you can't use it properly. *disclaimer - this is not to say postgres isn't awesome.
kicolobo 12y ago
Actually, they posted thw wrong link. That article is not written by wwwdesigned, but by me. Here is the original text: http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60
- jraedisch 12y ago
  I actually came there via two other aggregators (Twitter and Prismatic) and thought that I had found the source. Will be more careful next time - sorry about that. In any case it was an interesting read.
  - kicolobo 12y ago
    Thanks!
- dang 12y ago
  We've changed the URL from http://wwwdesigned.com/growing-irrelevance-mongodb/ http://wwwdesigned.com/growing-irrelevance-mongodb/. Did that site publish your article without permission?
anilmujagic 12y ago
I never understood the hype around MongoDB. Maybe it is the fact that I started programming when SQL DBs were the prevalent/mainstream option, and got too much used to it... Anyways, Im glad people are recognizing the hype and realizing that RDBMS has enough to offer.
octix 12y ago
It may be hype, but when MongoDB was released, what other RDBMS was offering the same functionality? I see Posgresql + JSON mentioned, but when was JSON support added? I personally like MongoDB for: - flexible schema (less migration pain) - easy tags implementation - product attributes (list of name-value pairs) - GridFS - store binary files - nested documents for analytics (ex: a record for each day with a nested doc for each hour) I wish MongoDB had - some support of join - multi-master replication I personally used MongoDB as primary storage (yeay dot me), but currently prefer it as secondary storage. As any product it evolves and I expect to see more improvements. I think MongoDB brought NoSQL to the masses :) Just my 0.02. Thanks.
- snird 12y ago
  Everything you said is true, but I don't think the argument here is about the past, but rather about the future. MongoDB was great and innovative compared to other solutions when it started, but now, it's dragged behind while other solutions are much better.
  - jbergens 12y ago
    Then we should probably compare other NOSQL solutions to relational databases. Like CouchDb, CouchBase, FoundationDb, Neo4J, etc.
FallDead 12y ago
Nice writeup, I always felt mongodb as a really fast product prototyping database . After you get to certain point you in web scale I would guess you would use one of these alternate solutions.

92 points by jraedisch 12y ago

If transactions are the biggest problems, there are driver solutions like http://godoc.org/labix.org/v2/mgo/txn http://godoc.org/labix.org/v2/mgo/txn for that. I am not sure, how they compare to "real" transactions. Still missing "joining" in some cases though. Otherwise I am ok with MongoDB so far.

stephen123 12y ago
If another host connects to the db, and the transaction doesn't span to that second host. Its not as safe as sql transactions.
- niemeyer 12y ago
  The transaction does span across hosts with the linked package.
politician 12y ago
Jeez. Please do not mention client-library-managed transactions and then put "real" transactions in scare quotes. At least read the Wikipedia article first.
- jraedisch 12y ago
  I just wanted to distinguish between the two. I wasn't scared in any way but read up on scare quotes now - so thanks for that. http://en.wikipedia.org/wiki/Scare_quotes http://en.wikipedia.org/wiki/Scare_quotes
- StavrosK 12y ago
  I didn't read it like that at all, I interpreted it as the gp distinguishing between the two.
niemeyer 12y ago
There are further details about how it works in this blog post: http://blog.labix.org/2012/08/22/multi-doc-transactions-for-mongodb http://blog.labix.org/2012/08/22/multi-doc-transactions-for-... While it does work, it's still a workaround for the lack of first-class transactions in MongoDB. It offers a more limited API and requires care on the developer side. Despite being the author, I do hope it gets obsoleted by more convenient first-class transaction support in MongoDB itself at some point in the near future.

crzrcn 12y ago

The submission url is malformed :(.

tech-no-logical 12y ago
I think it should be http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60

jnaour 12y ago

Probably this link: http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60

scarygliders 12y ago

Site seems to be overloaded or broken in some other way. Google cache : http://webcache.googleusercontent.com/search?q=cache:wwwdesigned.com/growing-irrelevance-mongodb/ http://webcache.googleusercontent.com/search?q=cache:wwwdesi...

collyw 12y ago

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be suited to rather than actually building anything.

Harrisburg 12y ago
Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain for all products, others will vary, some will change and will be dropped. Some may be conditional, depending on size or color. I could model that in RDBMS as well, adding those properties in an additional JSON or something else. Yes, I'm also mainly using relational databases and just wanted to give an example of a use-case for MongoDB. I regret, sorry.
- rjaco31 12y ago
  Care to elaborate? Beside maybe for the suggestion system, I really don't see what's the gain compared to a relational database.
  - BonoboBoner 12y ago
    Probably the EAV nightmare
    - arethuza 12y ago
      Stick JSON in a field within your relational model - best of both worlds.

Harrisburg 12y ago

I can't agree. MongoDB 2.8 with WiredTiger is a performant NoSQL solution. The way you solve things in document dbs like MongoDB is the key - not the fact that you get competitve performance in RDBMS as well. I like Postgres and the possibility to easily use JSON data. But I still prefer to build applications the NoSQL way...

bigiain 12y ago

MongoDB 2.8 (in RC4 right now, due out "in early January" last I heard) has the WiredTiger storage engine, and as well as high performance and compression also gets document level locking and multi document transactions. The roadmap says this'll become the default storage engine in 3.0 (3rd quarter 2015). I think the blog author's claim that for basically those omissions "MongoDB can still beat TokuMX on a future release. But only in a future release. Today it can’t." observation is only true if you ignore the development releases completely, and will be incorrect within a week or two. Sure, if you want SQL or traditional relational database, a traditional relational SQL database is a better choice. Using Postgres or Oracle for workloads better suited to tied hashes or BerkleyDB doesn't automatically become "right" though.

jraedisch 12y ago
Could you provide a source for "multi document transactions" support in 2.8? According to this comment they are supported by WiredTiger but won't be in the MongoDB API anytime soon: http://blog.mongodb.org/post/102461818738/announcing-mongodb-2-8-0-rc0-release-candidate-and#comment-1710534263 http://blog.mongodb.org/post/102461818738/announcing-mongodb...
- dm_mongodb 12y ago
  you are correct, that's not in 2.8. might want to follow this jira: https://jira.mongodb.org/browse/SERVER-11500 https://jira.mongodb.org/browse/SERVER-11500 that said it will be a big release in other aspects, with pluggable storage engines now, and WiredTiger specifically.

nchelluri 12y ago

Unfortunately I didn't find much information in the article. Basically I got out of it: - he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web framework/AngularJS/Node.js) - he found that for document oriented purposes MongoDB could sometimes be a nice fit - he found that replacing MongoDB with the drop-in replacement TokuMx (seems like a MySQL/MariaDB type of idea), he could get a big performance increase - he found that with Postgres 9.2+ using the JSON/document storage there he could get some of the relational benefits and some of the document benefits, and ACID - he likes ACID because of transactions/handling multiple documents at once Ok, so I guess I was wrong, there is a bit there. But: this is all stuff that I've heard several times about MongoDB. One of the things he got into was that he learned when MongoDB was appropriate and when it wasn't -- but IMO he didn't really go into detail here other than to say: joins and transactions. I wish there was more substance than that. I also seem to recall reading recently that even supposedly ACID compliant databases have problems with transactions under load and that the only way to really get full ACID compliance is to treat transactions as serializable - perhaps I am wrong but I think this is the gist of what I've learned. Personally, I'm working on a project right now that uses MongoDB and I definitely do miss joins, transactions, and schemas. I am not even remotely sure where one would benefit from a system that had documents with arbitrary fields in it. (I didn't pick the technologies for my project.) I would really like to know when to choose which database - I feel like I know the bare basics of several, and none of them in depth. I really don't have time to learn them all. I feel like even when I'm building one application it's only some months after deployment that if I'm lucky or made a mistake that I will run into some actual performance constraint.

crdoconnor 12y ago
>I would really like to know when to choose which database I have asked this question before - under what situations is Mongo not just equally good as Postgres - but actually better? The only really coherent answer was that it was easier to configure replication (presumably because it chooses a lot of defaults for you). I'm not even sure that was a good thing given the number of obscure bugs that can arise from incorrectly configured replication. Postgres even seems to be more performant at NoSQL use cases (using the JSON store) than Mongo, which is frankly embarrassing.

gasping 12y ago

MongoDB will always be a relevant example of false advertising and over-marketing (to the point of 10gen probably opening themselves to litigation) and how we all need to stop drinking the kool-aid. There is LITERALLY no reason to use MongoDB today. If you're thinking of using MongoDB, for the love of god just try PostgreSQL.

mwj 12y ago
this is a ridiculous comment. we use a mongodb cluster for a multi-hundred GB document store that powers ~50 various worker instances, 2 sites and an API with sub 100ms response times. we have never lost data or experienced downtime worse than other dbs i've used in the past. at the end of the day you just need to do your job properly and read the documentation, not blame the tool when you can't use it properly. *disclaimer - this is not to say postgres isn't awesome.

kicolobo 12y ago

Actually, they posted thw wrong link. That article is not written by wwwdesigned, but by me. Here is the original text: http://www.itexto.com.br/devkico/en/?p=60 http://www.itexto.com.br/devkico/en/?p=60

jraedisch 12y ago
I actually came there via two other aggregators (Twitter and Prismatic) and thought that I had found the source. Will be more careful next time - sorry about that. In any case it was an interesting read.
- kicolobo 12y ago
  Thanks!
dang 12y ago
We've changed the URL from http://wwwdesigned.com/growing-irrelevance-mongodb/ http://wwwdesigned.com/growing-irrelevance-mongodb/. Did that site publish your article without permission?

anilmujagic 12y ago

I never understood the hype around MongoDB. Maybe it is the fact that I started programming when SQL DBs were the prevalent/mainstream option, and got too much used to it... Anyways, Im glad people are recognizing the hype and realizing that RDBMS has enough to offer.

octix 12y ago

It may be hype, but when MongoDB was released, what other RDBMS was offering the same functionality? I see Posgresql + JSON mentioned, but when was JSON support added? I personally like MongoDB for: - flexible schema (less migration pain) - easy tags implementation - product attributes (list of name-value pairs) - GridFS - store binary files - nested documents for analytics (ex: a record for each day with a nested doc for each hour) I wish MongoDB had - some support of join - multi-master replication I personally used MongoDB as primary storage (yeay dot me), but currently prefer it as secondary storage. As any product it evolves and I expect to see more improvements. I think MongoDB brought NoSQL to the masses :) Just my 0.02. Thanks.

snird 12y ago
Everything you said is true, but I don't think the argument here is about the past, but rather about the future. MongoDB was great and innovative compared to other solutions when it started, but now, it's dragged behind while other solutions are much better.
- jbergens 12y ago
  Then we should probably compare other NOSQL solutions to relational databases. Like CouchDb, CouchBase, FoundationDb, Neo4J, etc.

FallDead 12y ago

Nice writeup, I always felt mongodb as a really fast product prototyping database . After you get to certain point you in web scale I would guess you would use one of these alternate solutions.