4 ms·

Hilarious video...but it reminds me of the painful fact that I know very little about databases so choosing between SQL and noSQL for my web app just seems arbi

by mburney 16y ago

Hilarious video...but it reminds me of the painful fact that I know very little about databases so choosing between SQL and noSQL for my web app just seems arbitrary for me. I wish there were some simpler explanations out there.

tmountain 16y ago
Traditional SQL databases provide some baked in guarantees regarding relationships between data and data structure. You design a schema and the server ensures that required columns exist, relationships between keys are enforced, and that all data is of the appropriate type. You're also given guarantees that certain things are done atomically. This means that a series of actions are performed with the promise that nothing will interfere between step one and step N. This promise is fulfilled through the use of transactions which incur a performance hit. NoSQL has become an increasingly broad term used to indicate some other storage strategy than traditional SQL databases provide. NoSQL databases tend to operate on a more basic level and omit things like transactions in favor of performance. Schemas are also disregarded to allow arbitrary storage requirements to be addressed with ease; although, you lose the traditional guarantees that a schema can provide. This is just my opinion, but I think it's a lot easier to setup a clusterfuck storage nightmare using a NoSQL database. If you're unfamiliar with SQL and NoSQL, you're most likely going to end up in a safer and more recoverable situation going with something tried and true like PostgreSQL. If you're not sure whether you need a NoSQL system, then you don't need one. They serve a use case and performance requirement that very few websites demand. That being said, when the need does arise, they can be an indispensable for scaling out a large website. Like anything else, they're not a magic bullet that you just drop into your storage strategy and go on your merry way. Rolling them out requires lots of planning just like any other large scale deployment does.
dasil003 16y ago
First learn SQL and the relational paradigm. SQL represents 40 years of experience designing general data stores that work for the widest set of applications. SQL databases solve many very hard problems which you are probably not aware of. If you jump into NoSQL first you will be reimplementing SQL features in your application code, and doing a shitty job of it because you have experience with data stores that actually solve these problems well. The reason for the existence of so many NoSQL databases is the rise of web applications and the need to scale massively. However the majority of apps will never need to scale beyond a single well-tuned database server anyway. By the time they do you will have hard problems to solve regardless of what data store you used. The advantage of SQL is that it's a fantastic hedge on the evolution of your data usage patterns because it is designed to support ad-hoc queries well, and the schema prevents bad application code from thrusting your data into chaos at the first occurrence of a small bug. Realistically if you knew you had to build an app for 5 million daily users, and you knew exactly what it was going to do, then an SQL database very well might be the wrong choice. But in the real world you have a long road ahead before you hit that scale, and you'll have real data to determine what kind of alternate data stores can best handle your load. Personally I'm a huge fan of redis, and its ability to scrape bottlenecks off a MySQL database in a piecemeal fashion.
- steveklabnik 16y ago
  NoSQL isn't just about scale. Sometimes, modeling data relationally is a real bitch, and a document store makes more sense.
  - dasil003 16y ago
    It's not a huge win though, because most of the time you still do have some relational data, and there's no reason you can't dump documents in an SQL database. The fact that the interface is new, shiny and slightly more elegant for this simple degenerate use case doesn't carry much weight with me.
    - steveklabnik 16y ago
      Real admins use the best tool for the job, anyway. "Polyglot persistence" is where it's at: You keep your sessions in Redis, you keep your news feed in MongoDB, and you keep your credit card details in Postgres. This is a false dichotomy.
      - dasil003 16y ago
        There needs to be a threshold of utility before you add an additional data store to your application. Just because you want to use some unstructured data (which was your original example) doesn't mean you need a new data store that's optimally suited to that. You can store documents just great in an SQL database or in the filesystem.
        Devilboy 16y ago
        This is the important bit. Just about every company or web app will have a bunch of relational data and therefore an SQL database of some kind. And storing key-value pairs in an SQL database is really not that hard or inconvenient or slow or whatever - it's gonna be 'good enough' for just about everyone. Why bother supporting an entire extra dedicated KV store when the SQL DB I already have will work just fine? 'Best tool for the job' is an oversimplification.

by mburney 16y ago

tmountain 16y ago

Traditional SQL databases provide some baked in guarantees regarding relationships between data and data structure. You design a schema and the server ensures that required columns exist, relationships between keys are enforced, and that all data is of the appropriate type. You're also given guarantees that certain things are done atomically. This means that a series of actions are performed with the promise that nothing will interfere between step one and step N. This promise is fulfilled through the use of transactions which incur a performance hit. NoSQL has become an increasingly broad term used to indicate some other storage strategy than traditional SQL databases provide. NoSQL databases tend to operate on a more basic level and omit things like transactions in favor of performance. Schemas are also disregarded to allow arbitrary storage requirements to be addressed with ease; although, you lose the traditional guarantees that a schema can provide. This is just my opinion, but I think it's a lot easier to setup a clusterfuck storage nightmare using a NoSQL database. If you're unfamiliar with SQL and NoSQL, you're most likely going to end up in a safer and more recoverable situation going with something tried and true like PostgreSQL. If you're not sure whether you need a NoSQL system, then you don't need one. They serve a use case and performance requirement that very few websites demand. That being said, when the need does arise, they can be an indispensable for scaling out a large website. Like anything else, they're not a magic bullet that you just drop into your storage strategy and go on your merry way. Rolling them out requires lots of planning just like any other large scale deployment does.

dasil003 16y ago

First learn SQL and the relational paradigm. SQL represents 40 years of experience designing general data stores that work for the widest set of applications. SQL databases solve many very hard problems which you are probably not aware of. If you jump into NoSQL first you will be reimplementing SQL features in your application code, and doing a shitty job of it because you have experience with data stores that actually solve these problems well. The reason for the existence of so many NoSQL databases is the rise of web applications and the need to scale massively. However the majority of apps will never need to scale beyond a single well-tuned database server anyway. By the time they do you will have hard problems to solve regardless of what data store you used. The advantage of SQL is that it's a fantastic hedge on the evolution of your data usage patterns because it is designed to support ad-hoc queries well, and the schema prevents bad application code from thrusting your data into chaos at the first occurrence of a small bug. Realistically if you knew you had to build an app for 5 million daily users, and you knew exactly what it was going to do, then an SQL database very well might be the wrong choice. But in the real world you have a long road ahead before you hit that scale, and you'll have real data to determine what kind of alternate data stores can best handle your load. Personally I'm a huge fan of redis, and its ability to scrape bottlenecks off a MySQL database in a piecemeal fashion.

steveklabnik 16y ago
NoSQL isn't just about scale. Sometimes, modeling data relationally is a real bitch, and a document store makes more sense.
- dasil003 16y ago
  It's not a huge win though, because most of the time you still do have some relational data, and there's no reason you can't dump documents in an SQL database. The fact that the interface is new, shiny and slightly more elegant for this simple degenerate use case doesn't carry much weight with me.
  - steveklabnik 16y ago
    Real admins use the best tool for the job, anyway. "Polyglot persistence" is where it's at: You keep your sessions in Redis, you keep your news feed in MongoDB, and you keep your credit card details in Postgres. This is a false dichotomy.
    - dasil003 16y ago
      There needs to be a threshold of utility before you add an additional data store to your application. Just because you want to use some unstructured data (which was your original example) doesn't mean you need a new data store that's optimally suited to that. You can store documents just great in an SQL database or in the filesystem.
      - Devilboy 16y ago
        This is the important bit. Just about every company or web app will have a bunch of relational data and therefore an SQL database of some kind. And storing key-value pairs in an SQL database is really not that hard or inconvenient or slow or whatever - it's gonna be 'good enough' for just about everyone. Why bother supporting an entire extra dedicated KV store when the SQL DB I already have will work just fine? 'Best tool for the job' is an oversimplification.