4 ms·

Most(?) of the articles I read on HN, and then their comments, always seem to put NoSQL in a bad light when people use it for things that "should" be in SQL Wh

Most(?) of the articles I read on HN, and then their comments, always seem to put NoSQL in a bad light when people use it for things that "should" be in SQL What _are_ the "correct" use cases for NoSQL? Everything has always been relational data for me

ubernostrum 9y ago
Depends what you mean by "NoSQL". I've gotten plenty of mileage out of using key-value stores to complement relational databases. They're good at acting as task queues and caches, for example.
shakna 9y ago
Something I made that was simpler as NoSQL: a comment system. Specifically a page had a list of comments, and a comment was a date/time and some text. There was no cross-referencing or nesting, just a basic ordered list. There is a relationship there, but it's a simple 1:1 relationship.
BoorishBears 9y ago
We designed an analytics framework that wouldn't gain much from SQL. Our analytics events are arbitrary JSON (with a few required keys like time). The SQL version of that would be to have a column for each required key, and putting all the non-required JSON in a column, and processing that column as JSON/JSONB. Instead we used Elasticsearch and got an efficient layout of our data for queries, and got visualizations for "free" (Kibana)
marcosdumay 9y ago
You can use a NoSQL database when your registers have no relation with each other (not even in different tables). Still, it's not automatically a good choice just because the above applies. It's guaranteed only to not be an horrible choice. The real answer is that nearly nobody has applications where NoSQL is a better choice than SQL databases. And those few that do will know it very well, so they don't need to ask around on internet forums.
jalayir 9y ago
> What _are_ the "correct" use cases for NoSQL? When you need a highly available and reliable DB for your application, then you need a cluster approach for data replication. Most popular SQL DBs are single-node, with some application-level clustering solutions, so the only option is to scale vertically. However, a lot of no-SQL DBs like Redis and DynamoDB do clustering/replication closer to the iron.
dragonwriter 9y ago
> What _are_ the "correct" use cases for NoSQL? Depends on which noSQL. GraphDBs make sense when your application needs efficient graph queries. Eventually-consistent, distributed stores make sense when your application needs very high availability and can tolerate eventual consistency. NoSQL can also be justified on non-technical grounds as a temporary workaround for poor administrative policy regarding SQL databases, it most likely once the DBA group realizes that you've built a critical non-SQL datastore, the policies will be extended to them as well if the basic problem hasn't been corrected.
metaphorm 9y ago
> What _are_ the "correct" use cases for NoSQL? there are many and the different use cases for it that I know of aren't really connected by a theme or any criterion that can be generalized. this is my own observations only, and not a statement based on theory. the wisdom of experience. take it for what it's worth. 1. application state persistence. persisting the app state in something closer to its native representation (JSON, for example) is convenient sometimes. if all you really want to do is save the state and then reload it later in another session you've got a strong use case for some kind of NoSQL. Note that application state persistence is very different than object state persistence. The app state is specific to a single user at a single point in time. Object state might have multiple users (anyone that can manipulate that object) and multiple points in time (e.g. objects that are persisted for long periods of time). 2. Key:Value store for cacheing. this is the most basic, canonical use case. Memcached, redis, etc. 3. data structures that SQL is poorly suited for. Graphs and Trees come to mind. if you find your SQL schema suddenly becoming bogged down in M2M through tables, you probably have a good use case for a Graph oriented datastore. 4. Time series. arguably this is just a subset of relational data, or a domain specific language extension over traditional SQL, but still, it feels a little different in practice.

ubernostrum 9y ago

Depends what you mean by "NoSQL". I've gotten plenty of mileage out of using key-value stores to complement relational databases. They're good at acting as task queues and caches, for example.

shakna 9y ago

Something I made that was simpler as NoSQL: a comment system. Specifically a page had a list of comments, and a comment was a date/time and some text. There was no cross-referencing or nesting, just a basic ordered list. There is a relationship there, but it's a simple 1:1 relationship.

BoorishBears 9y ago

We designed an analytics framework that wouldn't gain much from SQL. Our analytics events are arbitrary JSON (with a few required keys like time). The SQL version of that would be to have a column for each required key, and putting all the non-required JSON in a column, and processing that column as JSON/JSONB. Instead we used Elasticsearch and got an efficient layout of our data for queries, and got visualizations for "free" (Kibana)

marcosdumay 9y ago

You can use a NoSQL database when your registers have no relation with each other (not even in different tables). Still, it's not automatically a good choice just because the above applies. It's guaranteed only to not be an horrible choice. The real answer is that nearly nobody has applications where NoSQL is a better choice than SQL databases. And those few that do will know it very well, so they don't need to ask around on internet forums.

jalayir 9y ago

> What _are_ the "correct" use cases for NoSQL? When you need a highly available and reliable DB for your application, then you need a cluster approach for data replication. Most popular SQL DBs are single-node, with some application-level clustering solutions, so the only option is to scale vertically. However, a lot of no-SQL DBs like Redis and DynamoDB do clustering/replication closer to the iron.

dragonwriter 9y ago

> What _are_ the "correct" use cases for NoSQL? Depends on which noSQL. GraphDBs make sense when your application needs efficient graph queries. Eventually-consistent, distributed stores make sense when your application needs very high availability and can tolerate eventual consistency. NoSQL can also be justified on non-technical grounds as a temporary workaround for poor administrative policy regarding SQL databases, it most likely once the DBA group realizes that you've built a critical non-SQL datastore, the policies will be extended to them as well if the basic problem hasn't been corrected.

metaphorm 9y ago

> What _are_ the "correct" use cases for NoSQL? there are many and the different use cases for it that I know of aren't really connected by a theme or any criterion that can be generalized. this is my own observations only, and not a statement based on theory. the wisdom of experience. take it for what it's worth. 1. application state persistence. persisting the app state in something closer to its native representation (JSON, for example) is convenient sometimes. if all you really want to do is save the state and then reload it later in another session you've got a strong use case for some kind of NoSQL. Note that application state persistence is very different than object state persistence. The app state is specific to a single user at a single point in time. Object state might have multiple users (anyone that can manipulate that object) and multiple points in time (e.g. objects that are persisted for long periods of time). 2. Key:Value store for cacheing. this is the most basic, canonical use case. Memcached, redis, etc. 3. data structures that SQL is poorly suited for. Graphs and Trees come to mind. if you find your SQL schema suddenly becoming bogged down in M2M through tables, you probably have a good use case for a Graph oriented datastore. 4. Time series. arguably this is just a subset of relational data, or a domain specific language extension over traditional SQL, but still, it feels a little different in practice.