Live data from Hacker News

Scaling MongoDB at Mailbox

tech.dropbox.com

41–50 of 78 posts

Re: Scaling MongoDB at Mailbox

#41

>one performance issue that impacted us was MongoDB’s database-level write lock. People give MSSQL shit for having row-level locks (if you don't use their MVCC option), yet how is it that Mongo runs with a database-wide option and people don't immediately laugh and walk away? Is the hype so powerful that people just shrug about a huge mutex?

People give MSSQL shit for having row-level locks (if you don't use their MVCC option)

Just to clarify, are you talking about MSSQL's tendency to escalate locks (e.g. from row to page to extent to table)? They do that to make locks more manageable, and while in most cases it improves performance, in some high-concurrency situations it can be a gigantic PITA (especially given that the ways to strong-arm it into not escalating is not the most helpful).

Re: Scaling MongoDB at Mailbox

#42

I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…

Marketing. They marketed the hell out of it. Most developers I know have MongoDB mug.

> Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo

They had some strange defaults to start with (to give them serious advantage in small silly benchmarks) like un-acknowledged writes. Yes you read that correctly, for years their default configuration was to throw write requests over the fence and assume they succeeded.

There are some horror stories of people's databases becoming silently corrupted. Those corrupted databases were then backed up and back ups were corrupted.

Eventually they had fixed their defaults but their reputation as an engineering company went down the hill ( I speak for myself here mostly).

From my experience a lot of people using MongoDB don't know what they are using. To them 'unacknowledged writes' and 'database level locks' sounds like Latin. They see short examples, cool mugs, other cool kids talking about how easy MongoDB is and they start using it.

Re: Scaling MongoDB at Mailbox

#43

I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…

Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system.

It is also very easy to use and manage.

Re: Scaling MongoDB at Mailbox

#45
post #42

I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…

Marketing. They marketed the hell out of it. Most developers I know have MongoDB mug. > Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo They had some strange defaults to start with (to give them serious advantage in small silly benchmarks) like un-acknowledged writes. Yes you read that correctly, for years their default configuration was to throw wri…

or - mongo is great for some problems and not so great for other problems. if there is one thing you can figure out hanging out on HN long enough - it's cool to hate on mongodb

Re: Scaling MongoDB at Mailbox

#46

I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…

Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.

> It is also very easy to use and manage.

This is something that SQL database fans don't get. A small start-up can't afford to have a team of guys fiddling with incredibly obscure performance tuning settings.

A developer might not know how to optimize a slow-running Postgre query, but he knows how to cache data and denormalize in a manner that makes the query he wants to run fast. And a document-store plays nice with this.

Any simple relational beauty of SQL databases falls down once you get over a few million rows, and then the hideous hacks and bizarre settings start coming out. At that point you need a pile of domain-specific knowledge to make them play nice.

Mongo takes the domain-specific knowledge out of the equation and lets the developers apply their existing skill-set to the data.

I've you've got a thousand employees? Get a few DBAs and Postgre.

If you've got, like, five?

Re: Scaling MongoDB at Mailbox

#48
post #46

Earlier quoted context omitted.

Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.

> It is also very easy to use and manage. This is something that SQL database fans don't get. A small start-up can't afford to have a team of guys fiddling with incredibly obscure performance tuning settings. A developer might not know how to optimize a slow-running Postgre query, but he knows how to cache data and denormalize in a manner that makes the query he wants to run fast. And a document-store plays nice with…

are there no problems with mongo 'once you get over a few million rows'?

Re: Scaling MongoDB at Mailbox

#49
post #42

Earlier quoted context omitted.

Marketing. They marketed the hell out of it. Most developers I know have MongoDB mug. > Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo They had some strange defaults to start with (to give them serious advantage in small silly benchmarks) like un-acknowledged writes. Yes you read that correctly, for years their default configuration was to throw wri…

or - mongo is great for some problems and not so great for other problems. if there is one thing you can figure out hanging out on HN long enough - it's cool to hate on mongodb

> it's cool to hate on mongodb

Tens of thousands of computer geeks all randomly chose to hate a product. Clearly a coincidence or unlucky alignment of stars, nothing to do with said product, of course.

Re: Scaling MongoDB at Mailbox

#50
post #46

Earlier quoted context omitted.

Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.

> It is also very easy to use and manage. This is something that SQL database fans don't get. A small start-up can't afford to have a team of guys fiddling with incredibly obscure performance tuning settings. A developer might not know how to optimize a slow-running Postgre query, but he knows how to cache data and denormalize in a manner that makes the query he wants to run fast. And a document-store plays nice with…

A small startup that invests in some ops talent is going to run rings around a small startup that optimizes for developers.

People think that staffing up devs creates agility and speed, when in reality it just increases product features.

Scope creep without someone around to voice the needs of operations is a crazy-efficient generator of technical debt.

Post reply on HN