6 ms·

Having used mongo in a professional context, I'm sort of amused by how much vitriol it gets. It has it's flaws, but it's not that bad. I think it's been a bit m

Having used mongo in a professional context, I'm sort of amused by how much vitriol it gets. It has it's flaws, but it's not that bad. I think it's been a bit misbranded as the thing you use to "scale", which ticks people off. To me, when I use mongo, I mostly use it because it's the most convenient option. It's very easy to develop against, and awesome for prototyping and a lot of times it's good enough that you never need to replace it after the prototype phase. Relational databases are great, but they're almost an optimization -- they're way more useful after the problem set has been well defined and you have a much better sense of data access patterns and how you should lay out your tables and so on. But a lot of times that information isn't obvious upfront, and mongo is great in that context.

brainlock 13y ago
> Relational databases are great, but they're almost an optimization -- they're way more useful after the problem set has been well defined and you have a much better sense of data access patterns and how you should lay out your tables and so on. But a lot of times that information isn't obvious upfront, and mongo is great in that context. I think it's exactly the other way around. I prefer to lay out tables in a way that reflects the meaning and the relationship in the data. Only later, if there is a bottleneck somewhere, I might add a cache (i.e. de-normalize) to better fit the specific data access patterns that were causing trouble.
- threeseed 13y ago
  You missed the point. Since most companies now are doing Agile development there isn't the big upfront design process where the data model is clearly understood at the beginning. Instead you have this situation where the schema is continually evolving week by week and hence this is why schema less systems can be appealing. It isn't about performance.
  - kpmah 13y ago
    I would argue if you don't know how your data is going to be used then you should use the most flexible option - a normalised relational database. This gives you the most flexibility when querying, whereas with a denormalised database you need to know how you're going to query it ahead of time. Unless you want to abandon any semblance of performance.
  - hcarvalhoalves 13y ago
    IMO, this is the worst argument. There are multiple schema evolution tools for SQL, there's nothing stopping your team from changing the schema every week - plus, it's not hard, certainly less hard than having to maintain code that deals with multiple document schemas at once.
    - threeseed 13y ago
      The point is that if you using an ORM and have domain classes then it is unnecessary and annoying step. You have to make changes in two places rather than just one. Most people using MongoDB I know are seasoned enterprise Java developers and we have used many schema management tools for the last decade. It is a giant relief to be finally rid of them.
      - hcarvalhoalves 13y ago
        IMO, it sounds like the wrong remedy for the right diagnostic. I would never throw away the database because I'm duplicating information between ORM and domain classes. This seems more related to the particular constraints imposed by your codebase/architecture than the database. Right now I'm writing a REST API that will be consumed by web and mobile apps. It would impractical to duplicate validation across all codebases. Rather, I'm leveraging the database checks to get form validation on all clients for free. The application layer is thin, adding a field amounts to adding one line and running a command. I believe it boils down to which component rules the system: application or data layer.
    - JonnieCache 13y ago
      Rails-style migrations (did they invent them? I have no idea. I currently use Sequel's implementation) allow you to change the schema as often as you want. I often write half a dozen of them over the course of a feature branch. The rest of the team merges them in, and when they boot the app they get a message saying they have migrations to run. It's always been supremely reliable, even after complex merges. It gets more involved when you have multiple interacting DBs, but what doesn't? You have to write sensible migrations of course, or you can get into trouble. This is a feature. Obviously wide-ranging schema changes may require you to rewrite a lot of your app code, but I don't see how that's different for a schemaless database. My bigger worry is that every "schemaless" app still has a schema, just one that isn't well defined, similarly to how an app with a big mess of flags and boolean logic still has a state machine representation, it just isn't codified, or even finite or deterministic for all the developers know.
  - SideburnsOfDoom 13y ago
    > most companies now are doing Agile development ... you have this situation where the schema is continually evolving week by week I haven't seen that level of churn in any of the agile places that I have worked and it is not an inevitable consequence of agile working. If you don't want schema churn, then don't do that.
- prawks 13y ago
  I think if your understanding of the domain is complete enough that you can map out a relatively wholesome definition of the relationships of data then you're probably right. I think the advantage the parent is talking about is when you're exploring a domain that you do not have as deep of an understanding in. Schema-less data storage can be helpful in that exploration, as it allows you to dive in and get messy without much upfront consideration. Then afterwards you can step back with what you've learned/seen/experienced and build out your conceptual model of the problem domain.
  - brainlock 13y ago
    Thanks for spelling that out, I see that it can be a useful exploration tool. For me though, the act of thinking about a problem in terms of data and relationships helps a lot in exploring and understanding what I'm dealing with. Even more so in an agile setting, where things can and will be changed often - the schema is no exception, it can be changed. No need to cast in stone the first schema you came up with. But that's just my preferred way of approaching the problem :-)
    - splawn 13y ago
      I share your preference, but I am always curious how others do things. IMO the datastore is the most important piece of a CRUD app, because it is the foundation that everything hangs off of. So from my point of view tracking changes to its structure is extremely important in avoiding major headaches. How do developers manage this without a schema definition? Mongo's popularity has always made me second guess my assumptions about how important I think this is.
      - threeseed 13y ago
        See I disagree. As a developer the core of a system for me is not the datastore but the code. I have my domain model in code e.g. User.java and it gets stored transparently and correctly to the database using the ORM every time I save it. The ORM will never compromise the integrity of the database by say trying to store a Date in the wrong format. So you have to ask yourself what is the schema getting me ? It doesn't help with validation or business rules enforcement since I do that in code anyway. And it doesn't help with integrity since in the case of Java my data is strongly typed so no chance of storing types incorrectly.
mlieberman85 13y ago
I agree it has its uses but I feel like MongoDB (the company) sometimes puts forth use cases for MongoDB (the database) that are untenable. For example the pre-aggregated reports use case that they tout that fails at any reasonable scale (e.g. hundreds of upserts a second against tens of thousands of documents)
- overgard 13y ago
  Yeah, I can agree with that. A lot of their claims of scalability and benchmarks aren't lies, but they come with a lot of asterisks. I know in my last job we used both mongo and (mainly) microsoft sql server, and frankly, I enjoyed developing against mongodb way better, but if I needed something to be consistently fast, there was no question I'd put it in sql server. (Mongo's query speed can be really variable, and the tools to diagnose query planning kind of suck compared to more established databases)
threeseed 13y ago
A lot of the vitriol seems to come from the PostgreSQL camp. The enemy used to be MySQL but since they lost that fight they seem to enjoy spreading FUD about MongoDB. If they just focused on improving their own product i.e. easy of use, sharding, clustering etc. there wouldn't be a need for MongoDB or even HBase and Cassandra.
- worklogin 13y ago
  Postgres is winning the war with MySQL, if you're going to classify it that way. And from everything I've read and heard on HN, Postgres is constantly improving on clustering/HA fronts.
  - threeseed 13y ago
    No MySQL won many years ago. Every shared hosting provider uses the LAMP stack. And PostgreSQL has a pretty average scalability story. It lacks the simplicity of MongoDB or the flexibility of Cassandra or HBase. It needs a lot of work.
    - neverminder 13y ago
      I wouldn't exactly call that winning. It's like saying that Justin Bieber won because he's so popular. The article seems to focus on features rather than popularity. Yes, MySQL will be used mostly by amateurs for a long time, because for all it's flaws it somewhat compensates with ease of usability. I as a professional however will celebrate the day my company finally finishes the move from MySQL to PostgreSQL.
    - SideburnsOfDoom 13y ago
      > No MySQL won many years ago. Yeah, and Internet Explorer won many years ago. Then it lost. Because it stagnated while the others forged ahead.
    - mindcrime 13y ago
      Every shared hosting provider uses the LAMP stack. The world is a LOT bigger than just shared hosting providers.
kristiandupont 13y ago
To me this whole discussion seems equivalent to the static/dynamic typing war in programming languages. And so far, none of the camps have "won" as has been predicted over and over again. There are tradeoffs to both and people will prefer one over the other for what they will believe are rational reasons but probably really just a series of coincidences.
opendais 13y ago
Most of the vitrol stems from the fact that MongoDB's default settings were unsafe for a very long time and people were burned by it. Imo anyway.
- threeseed 13y ago
  Which is nonsense since every driver since the beginning set the default to be safe. Most of the vitriol comes from people who never even used it.
  - opendais 13y ago
    https://blog.rainforestqa.com/2012-11-05-mongodb-gotchas-and-how-to-avoid-them/ https://blog.rainforestqa.com/2012-11-05-mongodb-gotchas-and... "MongoDB allows very fast writes and updates by default. The tradeoff is that you are not explicitly notified of failures. By default most drivers do asynchronous, 'unsafe' writes - this means that the driver does not return an error directly, similar to INSERT DELAYED with MySQL. If you want to know if something succeeded, you have to manually check for errors using getLastError." We have very, very different definitions of safe defaults. Especially when this fact was poorly documented early on and caused people to be surprised by it. You may wish to consider that other people have different perspectives of what 'safe' means. Safe, to me, means: 1) Fsyncs to journal every write. 2) Returns an error immediately if an error occurred.
  - dev360 13y ago
    The python drivers never made it safe by default.
jeffdavis 13y ago
Informed, perhaps even constructive, criticism is not "vitriol".
jeffdavis 13y ago
"Relational databases are great ... after the problem set has been well defined ... But a lot of times that information isn't obvious upfront, and mongo is great in that context." A lot of people get stuck on the schema because they are trying to make it perfect upfront and hit analysis paralysis. I think that comes from other database systems that make it very hard to change the schema. In postgres, just define a very simple schema and get started with your prototype. It may just have a couple ordinary columns, and then a JSON or JSONB column as a catchall. Then, you can add/remove/rename columns and tables (all O(1) operations) or do more sophisticated transformations/migrations. All of this is transactional, meaning that your app can still be running without seeing an inconsistent (half-migrated) state. I believe this level of flexibility far exceeds what document databases offer.

brainlock 13y ago

> Relational databases are great, but they're almost an optimization -- they're way more useful after the problem set has been well defined and you have a much better sense of data access patterns and how you should lay out your tables and so on. But a lot of times that information isn't obvious upfront, and mongo is great in that context. I think it's exactly the other way around. I prefer to lay out tables in a way that reflects the meaning and the relationship in the data. Only later, if there is a bottleneck somewhere, I might add a cache (i.e. de-normalize) to better fit the specific data access patterns that were causing trouble.

threeseed 13y ago
You missed the point. Since most companies now are doing Agile development there isn't the big upfront design process where the data model is clearly understood at the beginning. Instead you have this situation where the schema is continually evolving week by week and hence this is why schema less systems can be appealing. It isn't about performance.
- kpmah 13y ago
  I would argue if you don't know how your data is going to be used then you should use the most flexible option - a normalised relational database. This gives you the most flexibility when querying, whereas with a denormalised database you need to know how you're going to query it ahead of time. Unless you want to abandon any semblance of performance.
- hcarvalhoalves 13y ago
  IMO, this is the worst argument. There are multiple schema evolution tools for SQL, there's nothing stopping your team from changing the schema every week - plus, it's not hard, certainly less hard than having to maintain code that deals with multiple document schemas at once.
  - threeseed 13y ago
    The point is that if you using an ORM and have domain classes then it is unnecessary and annoying step. You have to make changes in two places rather than just one. Most people using MongoDB I know are seasoned enterprise Java developers and we have used many schema management tools for the last decade. It is a giant relief to be finally rid of them.
    - hcarvalhoalves 13y ago
      IMO, it sounds like the wrong remedy for the right diagnostic. I would never throw away the database because I'm duplicating information between ORM and domain classes. This seems more related to the particular constraints imposed by your codebase/architecture than the database. Right now I'm writing a REST API that will be consumed by web and mobile apps. It would impractical to duplicate validation across all codebases. Rather, I'm leveraging the database checks to get form validation on all clients for free. The application layer is thin, adding a field amounts to adding one line and running a command. I believe it boils down to which component rules the system: application or data layer.
  - JonnieCache 13y ago
    Rails-style migrations (did they invent them? I have no idea. I currently use Sequel's implementation) allow you to change the schema as often as you want. I often write half a dozen of them over the course of a feature branch. The rest of the team merges them in, and when they boot the app they get a message saying they have migrations to run. It's always been supremely reliable, even after complex merges. It gets more involved when you have multiple interacting DBs, but what doesn't? You have to write sensible migrations of course, or you can get into trouble. This is a feature. Obviously wide-ranging schema changes may require you to rewrite a lot of your app code, but I don't see how that's different for a schemaless database. My bigger worry is that every "schemaless" app still has a schema, just one that isn't well defined, similarly to how an app with a big mess of flags and boolean logic still has a state machine representation, it just isn't codified, or even finite or deterministic for all the developers know.
- SideburnsOfDoom 13y ago
  > most companies now are doing Agile development ... you have this situation where the schema is continually evolving week by week I haven't seen that level of churn in any of the agile places that I have worked and it is not an inevitable consequence of agile working. If you don't want schema churn, then don't do that.
prawks 13y ago
I think if your understanding of the domain is complete enough that you can map out a relatively wholesome definition of the relationships of data then you're probably right. I think the advantage the parent is talking about is when you're exploring a domain that you do not have as deep of an understanding in. Schema-less data storage can be helpful in that exploration, as it allows you to dive in and get messy without much upfront consideration. Then afterwards you can step back with what you've learned/seen/experienced and build out your conceptual model of the problem domain.
- brainlock 13y ago
  Thanks for spelling that out, I see that it can be a useful exploration tool. For me though, the act of thinking about a problem in terms of data and relationships helps a lot in exploring and understanding what I'm dealing with. Even more so in an agile setting, where things can and will be changed often - the schema is no exception, it can be changed. No need to cast in stone the first schema you came up with. But that's just my preferred way of approaching the problem :-)
  - splawn 13y ago
    I share your preference, but I am always curious how others do things. IMO the datastore is the most important piece of a CRUD app, because it is the foundation that everything hangs off of. So from my point of view tracking changes to its structure is extremely important in avoiding major headaches. How do developers manage this without a schema definition? Mongo's popularity has always made me second guess my assumptions about how important I think this is.
    - threeseed 13y ago
      See I disagree. As a developer the core of a system for me is not the datastore but the code. I have my domain model in code e.g. User.java and it gets stored transparently and correctly to the database using the ORM every time I save it. The ORM will never compromise the integrity of the database by say trying to store a Date in the wrong format. So you have to ask yourself what is the schema getting me ? It doesn't help with validation or business rules enforcement since I do that in code anyway. And it doesn't help with integrity since in the case of Java my data is strongly typed so no chance of storing types incorrectly.

mlieberman85 13y ago

I agree it has its uses but I feel like MongoDB (the company) sometimes puts forth use cases for MongoDB (the database) that are untenable. For example the pre-aggregated reports use case that they tout that fails at any reasonable scale (e.g. hundreds of upserts a second against tens of thousands of documents)

overgard 13y ago
Yeah, I can agree with that. A lot of their claims of scalability and benchmarks aren't lies, but they come with a lot of asterisks. I know in my last job we used both mongo and (mainly) microsoft sql server, and frankly, I enjoyed developing against mongodb way better, but if I needed something to be consistently fast, there was no question I'd put it in sql server. (Mongo's query speed can be really variable, and the tools to diagnose query planning kind of suck compared to more established databases)

threeseed 13y ago

A lot of the vitriol seems to come from the PostgreSQL camp. The enemy used to be MySQL but since they lost that fight they seem to enjoy spreading FUD about MongoDB. If they just focused on improving their own product i.e. easy of use, sharding, clustering etc. there wouldn't be a need for MongoDB or even HBase and Cassandra.

worklogin 13y ago
Postgres is winning the war with MySQL, if you're going to classify it that way. And from everything I've read and heard on HN, Postgres is constantly improving on clustering/HA fronts.
- threeseed 13y ago
  No MySQL won many years ago. Every shared hosting provider uses the LAMP stack. And PostgreSQL has a pretty average scalability story. It lacks the simplicity of MongoDB or the flexibility of Cassandra or HBase. It needs a lot of work.
  - neverminder 13y ago
    I wouldn't exactly call that winning. It's like saying that Justin Bieber won because he's so popular. The article seems to focus on features rather than popularity. Yes, MySQL will be used mostly by amateurs for a long time, because for all it's flaws it somewhat compensates with ease of usability. I as a professional however will celebrate the day my company finally finishes the move from MySQL to PostgreSQL.
  - SideburnsOfDoom 13y ago
    > No MySQL won many years ago. Yeah, and Internet Explorer won many years ago. Then it lost. Because it stagnated while the others forged ahead.
  - mindcrime 13y ago
    Every shared hosting provider uses the LAMP stack. The world is a LOT bigger than just shared hosting providers.

kristiandupont 13y ago

To me this whole discussion seems equivalent to the static/dynamic typing war in programming languages. And so far, none of the camps have "won" as has been predicted over and over again. There are tradeoffs to both and people will prefer one over the other for what they will believe are rational reasons but probably really just a series of coincidences.

opendais 13y ago

Most of the vitrol stems from the fact that MongoDB's default settings were unsafe for a very long time and people were burned by it. Imo anyway.

threeseed 13y ago
Which is nonsense since every driver since the beginning set the default to be safe. Most of the vitriol comes from people who never even used it.
- opendais 13y ago
  https://blog.rainforestqa.com/2012-11-05-mongodb-gotchas-and-how-to-avoid-them/ https://blog.rainforestqa.com/2012-11-05-mongodb-gotchas-and... "MongoDB allows very fast writes and updates by default. The tradeoff is that you are not explicitly notified of failures. By default most drivers do asynchronous, 'unsafe' writes - this means that the driver does not return an error directly, similar to INSERT DELAYED with MySQL. If you want to know if something succeeded, you have to manually check for errors using getLastError." We have very, very different definitions of safe defaults. Especially when this fact was poorly documented early on and caused people to be surprised by it. You may wish to consider that other people have different perspectives of what 'safe' means. Safe, to me, means: 1) Fsyncs to journal every write. 2) Returns an error immediately if an error occurred.
- dev360 13y ago
  The python drivers never made it safe by default.

jeffdavis 13y ago

Informed, perhaps even constructive, criticism is not "vitriol".

jeffdavis 13y ago

"Relational databases are great ... after the problem set has been well defined ... But a lot of times that information isn't obvious upfront, and mongo is great in that context." A lot of people get stuck on the schema because they are trying to make it perfect upfront and hit analysis paralysis. I think that comes from other database systems that make it very hard to change the schema. In postgres, just define a very simple schema and get started with your prototype. It may just have a couple ordinary columns, and then a JSON or JSONB column as a catchall. Then, you can add/remove/rename columns and tables (all O(1) operations) or do more sophisticated transformations/migrations. All of this is transactional, meaning that your app can still be running without seeing an inconsistent (half-migrated) state. I believe this level of flexibility far exceeds what document databases offer.