5 ms·

The Verdict on MongoDB

28 points by sylvinus 13y ago

zemo 13y ago
>Modern web applications that have to scale for millions of transactions except MongoDB doesn't support transactions. >Initially, the lock scope of MongoDB was database wide, but later versions have a scope per database. that's just an editing error, it should say that initially the scope was instance wide, but now it's database wide.
troymc 13y ago
Maybe it makes sense to use MongoDB when you're just getting started, before you fully understand the data, so it's easy to add new attributes/columns etc. But why even bother with MongoDB? You could just use a text editor to make bunch of JSON text files, with one record per file. Then, once you better-understand the data, and you haven't made many "schema" changes for a while, you can set up a SQL database and import everything.
- fiatmoney 13y ago
  One better: use a SQL database with a PK, and a text field containing your JSON data. If your DB is Postgres, it'll even let you parse & query the JSON on the DB side.
- jasonmccay 13y ago
  People who swing hammers all day look at screwdrivers as the most confounding things. Why would you ever use a screw when you have nails?
cmer 13y ago
Here's my verdict in MongoDB after using it for a few years in a very high traffic application: I personally love most concepts behind Mongo. Schemaless, simple replication and sharing, JavaScript console, just to name a few. MongoDB is pretty much my dream database. However, the ugly truth is that it doesn't work as advertised (this was 2-3 years ago). Replication would often crash or stall leaving us with only one option: DELETE OUR ENTIRE DATA SET and start fresh. Acknowledged by 10gen at the time. This happened 3 times. Mongo was fast until we hit a wall. That was was at around 200GB for us, which is not that much when you put things in perspective. It was ridiculous. Running a given query took 1 ms and running it again right after could take up to 15 seconds. You'd think the second time would be faster. The global write lock is just insane. This simply cannot work in a high traffic application. Our app was write heavy and this bit us in the ass quite a bit. We didn't feel this until much later, after we were fully invested in mongo. Lastly, 10gen was literally the worst tech company I ever dealt with. They we're plain disrespectful to me, calling me cheap for not wanting to shell out 100k/year on a support contract. I was willing to pay them their hourly support rate (which is very high, but that's fine) to have them fix their replication bugs with our dataset. For us, MongoDB was a terrible mistake that I'll never make again. I'm glad the truth has been coming out over the last couple of years.
- bsg75 13y ago
  > Running a given query took 1 ms and running it again right after could take up to 15 seconds. You'd think the second time would be faster. Were you able to determine why this was? It does seem backwards, given the data should be cached at some layer.
  - cmer 13y ago
    We never figured it out...
    - bsg75 13y ago
      Was this issue raised with 10gen? Either way, was your experience the per-incident support was lacking because you did not have a support contract? It becomes interesting, because for $100K per year, I could budget for a lot of choices.
      - cmer 13y ago
        They refused to give us per incident support because they figured we could afford the yearly support plan (this was post acquisition at a public company) We eventually just gave up on the whole thing.
- earless1 13y ago
  If you had a chance to make the decision again, what would you choose instead of Mongo?
  - cmer 13y ago
    MySQL or PostgreSQL. Exactly what we did at my new startup. We actually did something that's quite unpopular here but it was the right choice for us. We started with Postgres and eventually ran in all sorts of performance problems after hitting a certain scale. We realized that nobody in the company knew anything about PG and that good consultants were extremely hard to find. On the flip side, everybody had good to excellent knowledge of MySQL and we happen to have a friend who's one of the best MySQL guys in the world. Pretty handy. We switched from PostgreSQL to MySQL and couldn't be happier. I think the lesson for us was: go with what you know and master, and with what's easy to fix, rather than what people on hackernews tell you to use.
ww520 13y ago
This reads like an advertisement for MongoDB. Is it the real verdict?
- bobzimuta 13y ago
  That's a resounding Lana-like yuuuuup.
AdrianRossouw 13y ago
I was trying to get feedback on this in an ask hn earlier: Ask HN: When is MongoDB the Right Tool for the Job? https://news.ycombinator.com/item?id=7446919 https://news.ycombinator.com/item?id=7446919 edit added title of post.
fooyc 13y ago
Well, as a dev I'm obviously not a fan or Eventual Consistency at all.
nailer 13y ago
What about reliability? Current stable official node mongodb native driver throws away exceptions in callbacks, as acknowledged by MongoDB Inc. There have been other 'surprises' in the past.
gaoshan 13y ago
To be fair this is an article that takes the opinions of employees of Rackspace, specifically, to deliver it's "verdict" which isn't a verdict so much as a collection of pluses and minuses. More importantly, Rackspace offers a Mongodb service (which they plug at the end of the article) so take their opinion with a grain of salt. Kind of like a Chevrolet dealer writing an article offering a "verdict" on the Chevy Volt that consists of opinions of Chevy engineers and mechanics and ending the article with a link to their showroom selection. Not invalid but not objective and not really a verdict.
- AdrianRossouw 13y ago
  that's the same reason i discount any of these type of things from mongodb.com, which are pretty well resulted in the search results. especially because the only reason I can see for everybody using mongodb is because it's popular.
benwilber0 13y ago
what was the point of this article other than to just plug their hosted mongodb service
angrybits 13y ago
I think this article is just google bait, there is nothing of any real consequence in it.
zenonu 13y ago
Schemaless databases are such an awful concept for any data you actually care about. After 12 years in the industry, I've realized any natural controls (e.g. schema) you can place on maintaining the integrity of your data, the better off you'll be long-term. Data matters the most. Your UI will be a tired POS in 3 years. Your backend data store won't scale for your new business problems. It'll be time to migrate, and then you'll start by asking yourself how clean and well-managed your data is.
- lampe3 13y ago
  you can still do schemafull databases with NOSQL databases but its in your hands to do it or not do it. All the problems you list you can have on SQL databases too It has to do with discipline to keep your data clean not with SQL or NoSQL
  - dasil003 13y ago
    Oops! He didn't say NoSQL or SQL anywhere in his comment.

28 points by sylvinus 13y ago

zemo 13y ago

>Modern web applications that have to scale for millions of transactions except MongoDB doesn't support transactions. >Initially, the lock scope of MongoDB was database wide, but later versions have a scope per database. that's just an editing error, it should say that initially the scope was instance wide, but now it's database wide.

troymc 13y ago

Maybe it makes sense to use MongoDB when you're just getting started, before you fully understand the data, so it's easy to add new attributes/columns etc. But why even bother with MongoDB? You could just use a text editor to make bunch of JSON text files, with one record per file. Then, once you better-understand the data, and you haven't made many "schema" changes for a while, you can set up a SQL database and import everything.

fiatmoney 13y ago
One better: use a SQL database with a PK, and a text field containing your JSON data. If your DB is Postgres, it'll even let you parse & query the JSON on the DB side.
jasonmccay 13y ago
People who swing hammers all day look at screwdrivers as the most confounding things. Why would you ever use a screw when you have nails?

cmer 13y ago

Here's my verdict in MongoDB after using it for a few years in a very high traffic application: I personally love most concepts behind Mongo. Schemaless, simple replication and sharing, JavaScript console, just to name a few. MongoDB is pretty much my dream database. However, the ugly truth is that it doesn't work as advertised (this was 2-3 years ago). Replication would often crash or stall leaving us with only one option: DELETE OUR ENTIRE DATA SET and start fresh. Acknowledged by 10gen at the time. This happened 3 times. Mongo was fast until we hit a wall. That was was at around 200GB for us, which is not that much when you put things in perspective. It was ridiculous. Running a given query took 1 ms and running it again right after could take up to 15 seconds. You'd think the second time would be faster. The global write lock is just insane. This simply cannot work in a high traffic application. Our app was write heavy and this bit us in the ass quite a bit. We didn't feel this until much later, after we were fully invested in mongo. Lastly, 10gen was literally the worst tech company I ever dealt with. They we're plain disrespectful to me, calling me cheap for not wanting to shell out 100k/year on a support contract. I was willing to pay them their hourly support rate (which is very high, but that's fine) to have them fix their replication bugs with our dataset. For us, MongoDB was a terrible mistake that I'll never make again. I'm glad the truth has been coming out over the last couple of years.

bsg75 13y ago
> Running a given query took 1 ms and running it again right after could take up to 15 seconds. You'd think the second time would be faster. Were you able to determine why this was? It does seem backwards, given the data should be cached at some layer.
- cmer 13y ago
  We never figured it out...
  - bsg75 13y ago
    Was this issue raised with 10gen? Either way, was your experience the per-incident support was lacking because you did not have a support contract? It becomes interesting, because for $100K per year, I could budget for a lot of choices.
    - cmer 13y ago
      They refused to give us per incident support because they figured we could afford the yearly support plan (this was post acquisition at a public company) We eventually just gave up on the whole thing.
earless1 13y ago
If you had a chance to make the decision again, what would you choose instead of Mongo?
- cmer 13y ago
  MySQL or PostgreSQL. Exactly what we did at my new startup. We actually did something that's quite unpopular here but it was the right choice for us. We started with Postgres and eventually ran in all sorts of performance problems after hitting a certain scale. We realized that nobody in the company knew anything about PG and that good consultants were extremely hard to find. On the flip side, everybody had good to excellent knowledge of MySQL and we happen to have a friend who's one of the best MySQL guys in the world. Pretty handy. We switched from PostgreSQL to MySQL and couldn't be happier. I think the lesson for us was: go with what you know and master, and with what's easy to fix, rather than what people on hackernews tell you to use.

ww520 13y ago

This reads like an advertisement for MongoDB. Is it the real verdict?

bobzimuta 13y ago
That's a resounding Lana-like yuuuuup.

AdrianRossouw 13y ago

I was trying to get feedback on this in an ask hn earlier: Ask HN: When is MongoDB the Right Tool for the Job? https://news.ycombinator.com/item?id=7446919 https://news.ycombinator.com/item?id=7446919 edit added title of post.

fooyc 13y ago

Well, as a dev I'm obviously not a fan or Eventual Consistency at all.

nailer 13y ago

What about reliability? Current stable official node mongodb native driver throws away exceptions in callbacks, as acknowledged by MongoDB Inc. There have been other 'surprises' in the past.

gaoshan 13y ago

To be fair this is an article that takes the opinions of employees of Rackspace, specifically, to deliver it's "verdict" which isn't a verdict so much as a collection of pluses and minuses. More importantly, Rackspace offers a Mongodb service (which they plug at the end of the article) so take their opinion with a grain of salt. Kind of like a Chevrolet dealer writing an article offering a "verdict" on the Chevy Volt that consists of opinions of Chevy engineers and mechanics and ending the article with a link to their showroom selection. Not invalid but not objective and not really a verdict.

AdrianRossouw 13y ago
that's the same reason i discount any of these type of things from mongodb.com, which are pretty well resulted in the search results. especially because the only reason I can see for everybody using mongodb is because it's popular.

benwilber0 13y ago

what was the point of this article other than to just plug their hosted mongodb service

angrybits 13y ago

I think this article is just google bait, there is nothing of any real consequence in it.

zenonu 13y ago

Schemaless databases are such an awful concept for any data you actually care about. After 12 years in the industry, I've realized any natural controls (e.g. schema) you can place on maintaining the integrity of your data, the better off you'll be long-term. Data matters the most. Your UI will be a tired POS in 3 years. Your backend data store won't scale for your new business problems. It'll be time to migrate, and then you'll start by asking yourself how clean and well-managed your data is.

lampe3 13y ago
you can still do schemafull databases with NOSQL databases but its in your hands to do it or not do it. All the problems you list you can have on SQL databases too It has to do with discipline to keep your data clean not with SQL or NoSQL
- dasil003 13y ago
  Oops! He didn't say NoSQL or SQL anywhere in his comment.