8 ms·

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 cac

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, like this one. In its current state it looks more like a prototyping tool that allows you to delay some tech decisions until your product matures, rather than a production tool. Or it is just me that wants at least 5 major versions on his production database.

mjallday 13y ago
Same reason MySQL sticks around when there are alternatives that make it harder to shoot yourself in the foot: Easy to get started, works well enough to make an MVP.
rdtsc 13y ago
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.
- misiti3780 13y ago
  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
  - rdtsc 13y ago
    > 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.
    - briancaw2 13y ago
      It could just be the case that everyone complains about their database and the HN crowd uses a lot of MongoDB. There's certainly more total MySql/MSSQL griping, whether or not gripers/users is higher for MongoDB isn't really obvious.
      - rdtsc 13y ago
        As I pointed out MongoDB inc (ex 10gen) made some decision in relation to how they marketed and set up their product that made many turn their heads.
  - idProQuo 13y ago
    I want to like Mongo, I'm all about "cutting my teeth on the bleeding edge", but I don't know what to think about MongoDB. Most conversations about it seem to go like this: Lover: MongoDB is so much faster and easier than old school SQL! Hater: It's fast and easy because it doesn't check if it's written data correctly, which leads to corrupt data. Lover: Well you could always turn on the write lock. Hater: If you turn on the write lock, it becomes slower than normal SQL databases. Lover: Well you're just trying to use it the same way you use SQL. MongoDB is great for some problems and not so great for other problems. Hater: What problems is MongoDB better at solving? And then that's the end. I've never heard a convincing use case for this thing. If you can change that for me and give me one, I'd be delighted to listen.
threeseed 13y ago
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.
- Pxtl 13y ago
  > 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?
  - konstantintin 13y ago
    are there no problems with mongo 'once you get over a few million rows'?
  - alrs 13y ago
    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.
  - stonewhite 13y ago
    One thing you don't know or faced yet is that mongo fails, and sometimes it fails so hard that you would rather kick some rocks. For example, if you start a background index generation on an eventually consistent replica set, indexing on secondary nodes are done foreground. Which means you only accept reads from slaves but slaves are unresponsive because of the index generation. In this state, if you try to do anything fancy your data will go corrupt. Only way out is to wait through the outage (which I find it pretty hard to do so). This is still not solved in 2.4, waiting for 2.6. Replica sets with all secondaries which can't elect a primary because it lost a node, or the mostly random primary-secondary switches that drops all connections, seldomly primary reelecting itself meanwhile dropping connections for no apparent reasons. Mongo offers tin foil hats for integrity, consistency and reliability. So yeah, I'd rather examine and understand why an SQL query is slow. Because it is at least deterministic, which in mongo nothing really is. Postgres supports free form json, XML or hstore document formats by the way, couchDb has its own specific features as a document db too. I still don't see why people want to go on with mongo this bad.
taude 13y ago
I think the premise of prototyping tool is pretty accurate. It makes easy to get something up and running and defer any operational knowledge until later. That being said, I don't see why people can't iterate their apps quickly on time-proven relational datastores. While having JavaScript through the stack is nice, I found writing Mongo Queries a PITA with all the curly-braces, etc...

mjallday 13y ago

Same reason MySQL sticks around when there are alternatives that make it harder to shoot yourself in the foot: Easy to get started, works well enough to make an MVP.

rdtsc 13y ago

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.

misiti3780 13y ago
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
- rdtsc 13y ago
  > 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.
  - briancaw2 13y ago
    It could just be the case that everyone complains about their database and the HN crowd uses a lot of MongoDB. There's certainly more total MySql/MSSQL griping, whether or not gripers/users is higher for MongoDB isn't really obvious.
    - rdtsc 13y ago
      As I pointed out MongoDB inc (ex 10gen) made some decision in relation to how they marketed and set up their product that made many turn their heads.
- idProQuo 13y ago
  I want to like Mongo, I'm all about "cutting my teeth on the bleeding edge", but I don't know what to think about MongoDB. Most conversations about it seem to go like this: Lover: MongoDB is so much faster and easier than old school SQL! Hater: It's fast and easy because it doesn't check if it's written data correctly, which leads to corrupt data. Lover: Well you could always turn on the write lock. Hater: If you turn on the write lock, it becomes slower than normal SQL databases. Lover: Well you're just trying to use it the same way you use SQL. MongoDB is great for some problems and not so great for other problems. Hater: What problems is MongoDB better at solving? And then that's the end. I've never heard a convincing use case for this thing. If you can change that for me and give me one, I'd be delighted to listen.

threeseed 13y ago

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.

Pxtl 13y ago
> 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?
- konstantintin 13y ago
  are there no problems with mongo 'once you get over a few million rows'?
- alrs 13y ago
  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.
- stonewhite 13y ago
  One thing you don't know or faced yet is that mongo fails, and sometimes it fails so hard that you would rather kick some rocks. For example, if you start a background index generation on an eventually consistent replica set, indexing on secondary nodes are done foreground. Which means you only accept reads from slaves but slaves are unresponsive because of the index generation. In this state, if you try to do anything fancy your data will go corrupt. Only way out is to wait through the outage (which I find it pretty hard to do so). This is still not solved in 2.4, waiting for 2.6. Replica sets with all secondaries which can't elect a primary because it lost a node, or the mostly random primary-secondary switches that drops all connections, seldomly primary reelecting itself meanwhile dropping connections for no apparent reasons. Mongo offers tin foil hats for integrity, consistency and reliability. So yeah, I'd rather examine and understand why an SQL query is slow. Because it is at least deterministic, which in mongo nothing really is. Postgres supports free form json, XML or hstore document formats by the way, couchDb has its own specific features as a document db too. I still don't see why people want to go on with mongo this bad.

taude 13y ago

I think the premise of prototyping tool is pretty accurate. It makes easy to get something up and running and defer any operational knowledge until later. That being said, I don't see why people can't iterate their apps quickly on time-proven relational datastores. While having JavaScript through the stack is nice, I found writing Mongo Queries a PITA with all the curly-braces, etc...