3 ms·

I can’t address MongoDB, but nosql vs relational generally, there are two reasons: (1) what’s faster than a fast join? No join. With nosql you have more flexib

by jmull 7y ago

I can’t address MongoDB, but nosql vs relational generally, there are two reasons: (1) what’s faster than a fast join? No join. With nosql you have more flexibility to store the data organized in the same way it is accessed. You don’t need to join to another table if the data your app needs is already directly part of the main data the app requests. You do need to understand your access patterns well, and develop migration plans when they change. (2) scalability. nosql databases generally let you scale horizontally more easily/gracefully than relational databases, though there are trade offs. Put it together and you get performance at scale, though you generally need to understand your data access patterns and usually need to be more resilient to inconsistencies.

zozbot234 7y ago
> what’s faster than a fast join? No join. With nosql you have more flexibility to store the data organized in the same way it is accessed. You can definitely do this in PostgreSQL via materialized views. They're directly supported in recent releases, and they don't require you to denormalize the underlying datamodel unlike NoSQL.
- jmull 7y ago
  Well, a materialized view is denormalized data. You distinguish it from the “underlying data model”, but you can do that in nosql as well. Also, materialized views still tend to be oriented to rectangular data, which isn’t always how you want to access data. I agree with the general point that Postgres and other relational databases can do nosql things (and nosql databases can do relational things).
ahachete 7y ago
> You do need to understand your access patterns well, and develop migration plans when they change. This sounds like a minor issue, but it's a huge operational pain. Migrating a data structure to accommodate new queries involves operations and application changes, both substantial. Migrating all data in a consistent way is either extremely hard or requires significant downtime. In my opinion, for most cases, this problem is significantly worse than doing joins in first place.
- jmull 7y ago
  Sure, relational is more flexible. We're talking about tradeoffs which you need to understand to make the right choice for your app/system/service. I don't know what you mean by migrations are extremely hard though.
  - ahachete 7y ago
    A migration in this context may involve rewriting substantial parts of the database. Imagine you need to rewrite a several TB collection. How would you do it? Either you involve in significant downtime, or you face the risk of breaking data consistency in the face of concurrent applications. Mongo cannot do a TB-sized migration atomically (see limitations for transactions) so you are faced with a potential incremental backfill. That will very likely break consistency and create more data problems that it is trying to solve. Last but not least, you need to recode your application heavily. And worse, make it work with two potential schemas at the same time (while backfill happens), and data in, potentially, two places at once. Or incur in hours or days of downtime.
    - jmull 7y ago
      Yes, I'm thinking of incremental migrations. You don't need to break things though. Anyway, from my perspective, the chance you can atomically update a system, whatever kind of database you're using, isn't something you necessarily get. You either don't have reliable control of all clients, middleware components and data stores or can't pay the price of downtime. So for data access pattern changes between components we're talking about incremental migration in any case, that needs to maintain compatibility until all dependent clients/components are updated. > Last but not least, you need to recode your application heavily. I don't think that's generally true. At a high-level, the point of nosql is to store your data more directly in the way your app wants to consume it, so data reorg follows the needs to the app, not the other way around. I guess you're talking about the need for code somewhere to take a more explicit role in managing storage. That generally does exist with nosql and is a maintenance burden, but should not be deeply embedded in your app. It should be a layer with clear separation of concerns, the implementation should be shared so you don't have redundant implementations, etc. I'm not disputing relational databases are more flexible, and mostly simpler when a single instance does the job (though you generally pay back some complexity transforming relational data into the form your clients need). So relational is usually the default/general choice if you don't need performance at scale.
thinkx 7y ago
> though there are trade offs. Please elaborate on this, it would be instructive
stepbeek 7y ago
> You do need to understand your access patterns well, I've found that being able to change quickly is more valuable that the marginal performance boost that mongo would give. Denormalization is possible in postgres. Where have you seen this trade off go well?

by jmull 7y ago

zozbot234 7y ago

> what’s faster than a fast join? No join. With nosql you have more flexibility to store the data organized in the same way it is accessed. You can definitely do this in PostgreSQL via materialized views. They're directly supported in recent releases, and they don't require you to denormalize the underlying datamodel unlike NoSQL.

jmull 7y ago
Well, a materialized view is denormalized data. You distinguish it from the “underlying data model”, but you can do that in nosql as well. Also, materialized views still tend to be oriented to rectangular data, which isn’t always how you want to access data. I agree with the general point that Postgres and other relational databases can do nosql things (and nosql databases can do relational things).

ahachete 7y ago

> You do need to understand your access patterns well, and develop migration plans when they change. This sounds like a minor issue, but it's a huge operational pain. Migrating a data structure to accommodate new queries involves operations and application changes, both substantial. Migrating all data in a consistent way is either extremely hard or requires significant downtime. In my opinion, for most cases, this problem is significantly worse than doing joins in first place.

jmull 7y ago
Sure, relational is more flexible. We're talking about tradeoffs which you need to understand to make the right choice for your app/system/service. I don't know what you mean by migrations are extremely hard though.
- ahachete 7y ago
  A migration in this context may involve rewriting substantial parts of the database. Imagine you need to rewrite a several TB collection. How would you do it? Either you involve in significant downtime, or you face the risk of breaking data consistency in the face of concurrent applications. Mongo cannot do a TB-sized migration atomically (see limitations for transactions) so you are faced with a potential incremental backfill. That will very likely break consistency and create more data problems that it is trying to solve. Last but not least, you need to recode your application heavily. And worse, make it work with two potential schemas at the same time (while backfill happens), and data in, potentially, two places at once. Or incur in hours or days of downtime.
  - jmull 7y ago
    Yes, I'm thinking of incremental migrations. You don't need to break things though. Anyway, from my perspective, the chance you can atomically update a system, whatever kind of database you're using, isn't something you necessarily get. You either don't have reliable control of all clients, middleware components and data stores or can't pay the price of downtime. So for data access pattern changes between components we're talking about incremental migration in any case, that needs to maintain compatibility until all dependent clients/components are updated. > Last but not least, you need to recode your application heavily. I don't think that's generally true. At a high-level, the point of nosql is to store your data more directly in the way your app wants to consume it, so data reorg follows the needs to the app, not the other way around. I guess you're talking about the need for code somewhere to take a more explicit role in managing storage. That generally does exist with nosql and is a maintenance burden, but should not be deeply embedded in your app. It should be a layer with clear separation of concerns, the implementation should be shared so you don't have redundant implementations, etc. I'm not disputing relational databases are more flexible, and mostly simpler when a single instance does the job (though you generally pay back some complexity transforming relational data into the form your clients need). So relational is usually the default/general choice if you don't need performance at scale.

thinkx 7y ago

> though there are trade offs. Please elaborate on this, it would be instructive

stepbeek 7y ago

> You do need to understand your access patterns well, I've found that being able to change quickly is more valuable that the marginal performance boost that mongo would give. Denormalization is possible in postgres. Where have you seen this trade off go well?