5 ms·

SQL relies on joins. Joins are fine for reasonably sized databases, but on internet scale joins have miserable performance. "Document" based databases such as M

SQL relies on joins. Joins are fine for reasonably sized databases, but on internet scale joins have miserable performance. "Document" based databases such as Mongo are designed to avoid joins. MongoDB has automatic sharding, which is very important for horizontal scaling of writes. For MySQL you have to do manual sharding which is extremely hard. And finally, document oriented databases are schemaless, which means there is no downtime when you add/remove fields.

gbuk2013 5y ago
That’s the theory, in practice “no schema” in my recent painful experience translates to “move the schema into the apps” which really sucks when you have a bunch of interdependent services owned by different teams. And you still need to do joins to enrich data from different collections. I want Postgres back. :(
- flowerlad 5y ago
  > really sucks when you have a bunch of interdependent services owned by different teams. That's true. The strictness of SQL lets you use SQL as the integration point. Without it you'd have to write a service on top as the integration layer.
- laichzeit0 5y ago
  It’s exactly that. Shifting the problem from schema-on-write to schema-on-read. It’s like dynamic vs statically typed. Personally, I don’t like it at all, none of your problems have magically disappeared, you just shifted it to runtime (or the application layer, as you say).
  - vel0city 5y ago
    In many document databases these days you can have required fields and types enforced by the database to ensure all documents in the collection have at least a certain schema. https://docs.mongodb.com/manual/core/schema-validation/#restrictions https://docs.mongodb.com/manual/core/schema-validation/#rest...
- jjav 5y ago
  > “move the schema into the apps” Exactly. There is always a schema, there has to be. It's just a question of whether it can easily be seen or if it is buried in a thousand places in the code.
fredros 5y ago
> but on internet scale joins have miserable performance. Please define internet scale. Joining 10s of billions of rows using clickhouse here.
- flowerlad 5y ago
  Clickhouse is OLAP. We are talking OLTP.
ksec 5y ago
>For MySQL you have to do manual sharding which is extremely hard. Vitess [1] and PlanetScale [2] ? [1] https://vitess.io https://vitess.io [2] https://www.planetscale.com https://www.planetscale.com
McGlockenshire 5y ago
This entire post sounds like the "MongoDB is web scale" video that is now a decade old. "Internet scale" is meaningless jargon. "Joins are slow" is a meme based on now-ancient MySQL performance. Schemaless / document databases have a place and a purpose, but nine times out of ten the data we're dealing with day to day has a known and rigid structure that changes infrequently.
bogomipz 5y ago
>""Document" based databases such as Mongo are designed to avoid joins." That is not something specific to document databases that is an approach taken by NOSQL datastores. It's known as denormalization which has its own share of issues that then need to be addressed.

gbuk2013 5y ago

That’s the theory, in practice “no schema” in my recent painful experience translates to “move the schema into the apps” which really sucks when you have a bunch of interdependent services owned by different teams. And you still need to do joins to enrich data from different collections. I want Postgres back. :(

flowerlad 5y ago
> really sucks when you have a bunch of interdependent services owned by different teams. That's true. The strictness of SQL lets you use SQL as the integration point. Without it you'd have to write a service on top as the integration layer.
laichzeit0 5y ago
It’s exactly that. Shifting the problem from schema-on-write to schema-on-read. It’s like dynamic vs statically typed. Personally, I don’t like it at all, none of your problems have magically disappeared, you just shifted it to runtime (or the application layer, as you say).
- vel0city 5y ago
  In many document databases these days you can have required fields and types enforced by the database to ensure all documents in the collection have at least a certain schema. https://docs.mongodb.com/manual/core/schema-validation/#restrictions https://docs.mongodb.com/manual/core/schema-validation/#rest...
jjav 5y ago
> “move the schema into the apps” Exactly. There is always a schema, there has to be. It's just a question of whether it can easily be seen or if it is buried in a thousand places in the code.

fredros 5y ago

> but on internet scale joins have miserable performance. Please define internet scale. Joining 10s of billions of rows using clickhouse here.

flowerlad 5y ago
Clickhouse is OLAP. We are talking OLTP.

ksec 5y ago

>For MySQL you have to do manual sharding which is extremely hard. Vitess [1] and PlanetScale [2] ? [1] https://vitess.io https://vitess.io [2] https://www.planetscale.com https://www.planetscale.com

McGlockenshire 5y ago

This entire post sounds like the "MongoDB is web scale" video that is now a decade old. "Internet scale" is meaningless jargon. "Joins are slow" is a meme based on now-ancient MySQL performance. Schemaless / document databases have a place and a purpose, but nine times out of ten the data we're dealing with day to day has a known and rigid structure that changes infrequently.

bogomipz 5y ago

>""Document" based databases such as Mongo are designed to avoid joins." That is not something specific to document databases that is an approach taken by NOSQL datastores. It's known as denormalization which has its own share of issues that then need to be addressed.