4 ms·

Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a

Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.

bitwize 6y ago
> When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort. There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services. No, I'm not kidding. This is literally what people do and recommend.
- c-cube 6y ago
  And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql
  - bitwize 6y ago
    Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.
- cosmodisk 6y ago
  Is this a joke or people seriously do this?
  - bitwize 6y ago
    It's industry best practice -- not a joke. What's more, the recommendation is to have a separate database per service -- one table, one service, one database. Fuethermore, when a join is desired, the best practice is to implement not just a service that joins the data but maintains it in a table/materialized view of its own, along with a message server such as Kafka. The services responsible for the tables to be joined (customers and orders, for instance) put events on this message bus which the joining service subscribes to in order to know when to update its view. See: https://microservices.io/patterns/data/cqrs.html https://microservices.io/patterns/data/cqrs.html And don't get me started on how you do transactions that touch multiple tables in this setup: https://microservices.io/patterns/data/saga.html https://microservices.io/patterns/data/saga.html I have seen these deployed and advocated as the modern way to write business applications in the wild.
- collyw 6y ago
  I bet these people are running on a single server.
stepbeek 6y ago
This is a good point. If we ignore obvious key-value examples, I’m curious about how much data really isn’t relational.

bitwize 6y ago

> When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort. There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services. No, I'm not kidding. This is literally what people do and recommend.

c-cube 6y ago
And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql
- bitwize 6y ago
  Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.
cosmodisk 6y ago
Is this a joke or people seriously do this?
- bitwize 6y ago
  It's industry best practice -- not a joke. What's more, the recommendation is to have a separate database per service -- one table, one service, one database. Fuethermore, when a join is desired, the best practice is to implement not just a service that joins the data but maintains it in a table/materialized view of its own, along with a message server such as Kafka. The services responsible for the tables to be joined (customers and orders, for instance) put events on this message bus which the joining service subscribes to in order to know when to update its view. See: https://microservices.io/patterns/data/cqrs.html https://microservices.io/patterns/data/cqrs.html And don't get me started on how you do transactions that touch multiple tables in this setup: https://microservices.io/patterns/data/saga.html https://microservices.io/patterns/data/saga.html I have seen these deployed and advocated as the modern way to write business applications in the wild.
collyw 6y ago
I bet these people are running on a single server.

stepbeek 6y ago

This is a good point. If we ignore obvious key-value examples, I’m curious about how much data really isn’t relational.