8 ms·

NoSQL Took Away The Relational Model And Gave Nothing Back

77 points by ArturSoler 16y ago

dagheti 16y ago
The name relational model is quite unfortunate, as it leads to confusion about what the model is (not much to do with 'relationships'). The key concepts are using sets to store data (making you think about your data in a way where duplication of tuples and orderings don't mean anything), and always using values instead of pointers to store your data and references. I think that these concepts are very useful when it comes to managing data, but they seem to get lost in the all the talk about "relationships" and "sql" and "structured tables".
wgj 16y ago
I know Ben Black and I can assure you he is very experienced with NoSQL data stores. He is calling for more attention to the query interface to these various data stores. He's specifically not saying they should be relational or dismissing other merits of NoSQL.
nailer 16y ago
'With NoSQL all relationships have been pushed back onto the poor programmer to implement in code rather than the database managing it. ' OK I'll bite. Yes. I, the poor programmer, want to implement relationships in my code, rather than adding a secondary language to my application to manage relationships (the database itself never 'managed this' for me, I had to do it manually).
- gaius 16y ago
  Welcome to MySQL in 1995. You'll be wanting to "manage" transactions next...
  - jbooth 16y ago
    Yeah, I do actually, because I want a storage system to be a storage system and an application layer to be an application layer. I've seen corporate code bases consisting of entirely PL/SQL before, it's a nightmare. No thanks, from both a maintenance perspective and a performance perspective. YMMV.
    - gaius 16y ago
      Yep, nothing says performance and reliability like doing everything in the app. Here's a neat trick - for every query SELECT * FROM TABLE, then filter and sort it in the application too.
      - jbooth 16y ago
        Here's a better trick - treat a database as an indexed storage layer that's doing the minimum of CPU work or complicated transactional conditions that create lots of blocking and bottleneck conditions for threads on your monolithic back end. And then implement the app logic in some slow-ass web language that doesn't hold a candle to your database's optimized C. What happens when your web server can't keep up? Buy another web server. That's an easily solvable problem. A saturated DB, on the other hand, is very hard to fix, especially if all of your application logic is running in it and would require a rewrite to scale.
        gaius 16y ago
        There's an awful lot more to computing than websites. FWIW I work on a "non-scalable" RDBMS that comfortably handles thousands of commits/sec, tens of thousands of selects/sec and tens of terabytes of data. All done with stored procs, one database, no need for "sharding" either. Will it scale indefinitely? No, but neither will anything else. The limits of the RDBMS are orders of magnitude greater than the NoSQL crowd think they are.
        mmt 16y ago
        The limits of the RDBMS are orders of magnitude greater than the NoSQL crowd think they are. Agreed. There's a couple of orders of magnitude just from I/O improvement in hardware, using conventional[1] hardware, configured intelligently. There's at least another order of magnitude in optimizations that aren't possible in NoSQL's strawman[2], such as separate tablespaces for data and index, partial indexes, and a galaxy of query tuning from an EXPLAIN that actuall provides a query plan. [1] Meaning commodity-priced, nothing fancier than $400 RAID cards and spinning disks. [2] MySQL
  - nailer 16y ago
    I never said I required, or tried to implement transactions. In fact I can tell you know I'm pretty sure a CMS and push based communications app are running quite fine without transactions. What I do have is: * One language which handles both app logic and relationships, as mentioned above. * A fidelity of types between storage and application (I'm using Mongo, so documents are stored as documents, not fields and rows) * Apparently, some speed benefits should I need it in future, at the expense of losing the aforementioned features I don't need. Please don't put words into my mouth: * It's not nice. * It's against the HN guidelines * If your argument was of substance you wouldn't need to do it. It saddens me this kind of nastiness gets upvotes.
antirez 16y ago
NoSQL does not mean nothing... Redis does not use the Relational Model not because it promotes a simple key-value model, but because it proposes a different paradigm and data model based on fundamental data structures. MongoDB for instance does not took away the relational model at all, in some way. So what NoSQL are we talking about? :) NoSQL was a good marketing idea at start, but now it's starting to be really misleading.
- silentbicycle 16y ago
  The term "NoSQL" has always been misleading. The various "NoSQL" systems have very different underlying models, and defining them by their lack of SQL makes discussions about tend to develop an adversarial, "us vs. them" tone. It adds way too much noise. I don't care about "NoSQL" - I like Postgres and SQLite. What makes the individual "NoSQL" databases interesting, though? Redis is in a design sweet spot, IMHO. The pure key-value stores seem way too low-level to me, but the support for atomic operations on lists, sets, etc. in Redis is very handy. It also works well as a cache for other databases, and newer commands like BLPOP are very cool. While I haven't used CouchDB much, its model is also interesting, and I can see its trade-offs being an excellent fit for certain problems (just not mine).
  - checker 16y ago
    Some say NoSQL = "Not Only SQL", implying that there are alternatives to purely relational DB's. I think this definition fits better than the implied purely unrelational DB.
    - silentbicycle 16y ago
      Agreed, but that's just damage control, after a whole bunch of "Death to relational databases!!!" hype. Of course there are alternatives to RDBMSs. What are filesystems if not hierarchial databases? "NoSQL" is about as useful as rallying behind "languages without camel-case" (NoCC!).
raganwald 16y ago
I'll bite as well. Are NoSQL databases faster? Smaller? Simpler? If any of these statements are true, then they are giving something back, although quite possibly that trade-off is not of interest to the author. I am reminded of another Holy War (beware! reminded-of is not a euphemism for is-just-like): "Ruby took away the power of static typing and gave nothing back."
- deleted 16y ago
  [deleted]
- bmelton 16y ago
  Generally, the pros and cons list should be isolated down to a given implementation. While you can vaguely state that NoSQL data stores are fast, and that horizontal scaling is generally easier on NoSQL, that isn't always the case, and doesn't apply to anywhere close to every situation. MongoDB offers some REALLY cool features that enhance development speed. Inserting into a table that doesn't exist? It creates the table on the fly. Querying from a table that doesn't exist just returns an empty result set (instead of an error, or exception). If I had to speak in specifics though, I think it's pretty easy to say that NoSQL stores allow for querying very large datasets faster than you could on a relational store on similar hardware.
mjw 16y ago
I see it as a high-level vs low-level thing. The relational model is a high-level language for describing the structure of data. And a pretty elegant one if you can look past the awkwardness of dealing with current SQL databases (not a fault of the model itself). That said if you want to scale and tune things you often need to drop down to a lower-level view in order to get things done, hence NoSQL. But that's not to say the relational model isn't still useful, or that it shouldn't inform any formal reasoning done about data in NoSQL systems. I have some more thoughts on this here: http://matthew.yumptious.com/2009/07/databases/nosql-and-the-relational-model-dont-throw-the-baby-out-with-the-bathwater/ http://matthew.yumptious.com/2009/07/databases/nosql-and-the...
- mjw 16y ago
  To the downvoter - curious what exactly you disagreed with?
  - raganwald 16y ago
    Up to you, but I'd say let that kind of thing slide. The ideal is that if someone disagrees, they'll explain themselves. Downvoting is supposed to be a mechanism for voting on whether a point adds to the discussion or not. So either (a) your point did not add to the discussion, in which case further discussion about your point just adds to the noise without contributing signal, or (b) the person or persons downvoting disagree with you but are too lazy to contribute to the discussion by explaining their perspective. In which case, why worry about them? Responses--whether positive or negative--are discussion gold. Downvotes aren't worth the worry.
    - deleted 16y ago
      [deleted]
steveklabnik 16y ago
Flamebait title is wrong. From the article: Update: Benjamin Black said he was the source of the quote and also said I was wrong about what he meant, ill-informed even. His point: The meaning of the statement was that NoSQL systems (really the various map-reduce systems) are lacking a standard model for describing and querying and that developing one should be a high priority task for them.
- toddh 16y ago
  The title was a quote, so it was not wrong, what he disagreed with was the interpretation.
  - steveklabnik 16y ago
    It's most certainly misleading.
philjackson 16y ago
Taking away the relational model was what they gave us.
xpaulbettsx 16y ago
I would disagree - I'd say that NoSQL is an exploration into disassembling the component parts of a RDBMS in order to get performance gains in exchange for losing features that aren't needed for your particular engineering problem.
sofuture 16y ago
It's (still) stupid arguing that NoSQL systems are crappy at proving the things RDBMS systems provide. (Because they are, and no one has ever said differently, it's akin to yelling at a Bugatti Veyron (yeah, I went there) for being so bad at flying.) I'm not using CouchDB because I needed relationships and the RDBMS features of SQL Server but decided at the last minute 'Ehh oh well, let's just try this fancy NoSQL business, I'll rewrite all the RDBMS features into my code'. Believe it or not I'm using CouchDB because I want to run map/reduce on a bunch of JSON! Astounding, right!?
knodi 16y ago
I can't talk about all NoSQL but I can talk about CouchDB as I have worked with it some. It gives multiple write nodes, easy replications and syncing, it gave map reduce. I love it
random42 16y ago
I dont get the big hoopla about NoSQL. Its a different way of doing things than traditional RDBMS (which very successfully served us well for over 20 years). Why cant we just choose the best tool for the job, after looking at pros and cons?
8ren 16y ago
"A relational model of data for large shared data banks" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.1845&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110... He gives criticism of the then existing databases (hierarchical and network), then proposes the relational model and the concept of a query language (though not an actual languages - this predates SQL). Interestingly, one of the hierarchical databases (IMS) is still going strong: http://en.wikipedia.org/wiki/Information_Management_System#History http://en.wikipedia.org/wiki/Information_Management_System#H...
j_baker 16y ago
"The meaning of the statement was that NoSQL systems (really the various map-reduce systems) are lacking a standard model for describing and querying and that developing one should be a high priority task for them." I don't see why the relational model (or some subset thereof) won't work for most NoSQL databases. Key-Value store? It's essentially just a relational database where tables can have one primary key and one other column. Document store? Essentially just a dynamically typed relational database. Graph database? You probably would have to add to the relational model a bit, but Codd did write a bit about recursive queries.

77 points by ArturSoler 16y ago

The name relational model is quite unfortunate, as it leads to confusion about what the model is (not much to do with 'relationships'). The key concepts are using sets to store data (making you think about your data in a way where duplication of tuples and orderings don't mean anything), and always using values instead of pointers to store your data and references. I think that these concepts are very useful when it comes to managing data, but they seem to get lost in the all the talk about "relationships" and "sql" and "structured tables".

wgj 16y ago

I know Ben Black and I can assure you he is very experienced with NoSQL data stores. He is calling for more attention to the query interface to these various data stores. He's specifically not saying they should be relational or dismissing other merits of NoSQL.

nailer 16y ago

'With NoSQL all relationships have been pushed back onto the poor programmer to implement in code rather than the database managing it. ' OK I'll bite. Yes. I, the poor programmer, want to implement relationships in my code, rather than adding a secondary language to my application to manage relationships (the database itself never 'managed this' for me, I had to do it manually).

gaius 16y ago
Welcome to MySQL in 1995. You'll be wanting to "manage" transactions next...
- jbooth 16y ago
  Yeah, I do actually, because I want a storage system to be a storage system and an application layer to be an application layer. I've seen corporate code bases consisting of entirely PL/SQL before, it's a nightmare. No thanks, from both a maintenance perspective and a performance perspective. YMMV.
  - gaius 16y ago
    Yep, nothing says performance and reliability like doing everything in the app. Here's a neat trick - for every query SELECT * FROM TABLE, then filter and sort it in the application too.
    - jbooth 16y ago
      Here's a better trick - treat a database as an indexed storage layer that's doing the minimum of CPU work or complicated transactional conditions that create lots of blocking and bottleneck conditions for threads on your monolithic back end. And then implement the app logic in some slow-ass web language that doesn't hold a candle to your database's optimized C. What happens when your web server can't keep up? Buy another web server. That's an easily solvable problem. A saturated DB, on the other hand, is very hard to fix, especially if all of your application logic is running in it and would require a rewrite to scale.
      - gaius 16y ago
        There's an awful lot more to computing than websites. FWIW I work on a "non-scalable" RDBMS that comfortably handles thousands of commits/sec, tens of thousands of selects/sec and tens of terabytes of data. All done with stored procs, one database, no need for "sharding" either. Will it scale indefinitely? No, but neither will anything else. The limits of the RDBMS are orders of magnitude greater than the NoSQL crowd think they are.
        mmt 16y ago
        The limits of the RDBMS are orders of magnitude greater than the NoSQL crowd think they are. Agreed. There's a couple of orders of magnitude just from I/O improvement in hardware, using conventional[1] hardware, configured intelligently. There's at least another order of magnitude in optimizations that aren't possible in NoSQL's strawman[2], such as separate tablespaces for data and index, partial indexes, and a galaxy of query tuning from an EXPLAIN that actuall provides a query plan. [1] Meaning commodity-priced, nothing fancier than $400 RAID cards and spinning disks. [2] MySQL
- nailer 16y ago
  I never said I required, or tried to implement transactions. In fact I can tell you know I'm pretty sure a CMS and push based communications app are running quite fine without transactions. What I do have is: * One language which handles both app logic and relationships, as mentioned above. * A fidelity of types between storage and application (I'm using Mongo, so documents are stored as documents, not fields and rows) * Apparently, some speed benefits should I need it in future, at the expense of losing the aforementioned features I don't need. Please don't put words into my mouth: * It's not nice. * It's against the HN guidelines * If your argument was of substance you wouldn't need to do it. It saddens me this kind of nastiness gets upvotes.

antirez 16y ago

NoSQL does not mean nothing... Redis does not use the Relational Model not because it promotes a simple key-value model, but because it proposes a different paradigm and data model based on fundamental data structures. MongoDB for instance does not took away the relational model at all, in some way. So what NoSQL are we talking about? :) NoSQL was a good marketing idea at start, but now it's starting to be really misleading.

silentbicycle 16y ago
The term "NoSQL" has always been misleading. The various "NoSQL" systems have very different underlying models, and defining them by their lack of SQL makes discussions about tend to develop an adversarial, "us vs. them" tone. It adds way too much noise. I don't care about "NoSQL" - I like Postgres and SQLite. What makes the individual "NoSQL" databases interesting, though? Redis is in a design sweet spot, IMHO. The pure key-value stores seem way too low-level to me, but the support for atomic operations on lists, sets, etc. in Redis is very handy. It also works well as a cache for other databases, and newer commands like BLPOP are very cool. While I haven't used CouchDB much, its model is also interesting, and I can see its trade-offs being an excellent fit for certain problems (just not mine).
- checker 16y ago
  Some say NoSQL = "Not Only SQL", implying that there are alternatives to purely relational DB's. I think this definition fits better than the implied purely unrelational DB.
  - silentbicycle 16y ago
    Agreed, but that's just damage control, after a whole bunch of "Death to relational databases!!!" hype. Of course there are alternatives to RDBMSs. What are filesystems if not hierarchial databases? "NoSQL" is about as useful as rallying behind "languages without camel-case" (NoCC!).

raganwald 16y ago

I'll bite as well. Are NoSQL databases faster? Smaller? Simpler? If any of these statements are true, then they are giving something back, although quite possibly that trade-off is not of interest to the author. I am reminded of another Holy War (beware! reminded-of is not a euphemism for is-just-like): "Ruby took away the power of static typing and gave nothing back."

deleted 16y ago
[deleted]
bmelton 16y ago
Generally, the pros and cons list should be isolated down to a given implementation. While you can vaguely state that NoSQL data stores are fast, and that horizontal scaling is generally easier on NoSQL, that isn't always the case, and doesn't apply to anywhere close to every situation. MongoDB offers some REALLY cool features that enhance development speed. Inserting into a table that doesn't exist? It creates the table on the fly. Querying from a table that doesn't exist just returns an empty result set (instead of an error, or exception). If I had to speak in specifics though, I think it's pretty easy to say that NoSQL stores allow for querying very large datasets faster than you could on a relational store on similar hardware.

mjw 16y ago

I see it as a high-level vs low-level thing. The relational model is a high-level language for describing the structure of data. And a pretty elegant one if you can look past the awkwardness of dealing with current SQL databases (not a fault of the model itself). That said if you want to scale and tune things you often need to drop down to a lower-level view in order to get things done, hence NoSQL. But that's not to say the relational model isn't still useful, or that it shouldn't inform any formal reasoning done about data in NoSQL systems. I have some more thoughts on this here: http://matthew.yumptious.com/2009/07/databases/nosql-and-the-relational-model-dont-throw-the-baby-out-with-the-bathwater/ http://matthew.yumptious.com/2009/07/databases/nosql-and-the...

mjw 16y ago
To the downvoter - curious what exactly you disagreed with?
- raganwald 16y ago
  Up to you, but I'd say let that kind of thing slide. The ideal is that if someone disagrees, they'll explain themselves. Downvoting is supposed to be a mechanism for voting on whether a point adds to the discussion or not. So either (a) your point did not add to the discussion, in which case further discussion about your point just adds to the noise without contributing signal, or (b) the person or persons downvoting disagree with you but are too lazy to contribute to the discussion by explaining their perspective. In which case, why worry about them? Responses--whether positive or negative--are discussion gold. Downvotes aren't worth the worry.
  - deleted 16y ago
    [deleted]

steveklabnik 16y ago

Flamebait title is wrong. From the article: Update: Benjamin Black said he was the source of the quote and also said I was wrong about what he meant, ill-informed even. His point: The meaning of the statement was that NoSQL systems (really the various map-reduce systems) are lacking a standard model for describing and querying and that developing one should be a high priority task for them.

toddh 16y ago
The title was a quote, so it was not wrong, what he disagreed with was the interpretation.
- steveklabnik 16y ago
  It's most certainly misleading.

philjackson 16y ago

Taking away the relational model was what they gave us.

xpaulbettsx 16y ago

I would disagree - I'd say that NoSQL is an exploration into disassembling the component parts of a RDBMS in order to get performance gains in exchange for losing features that aren't needed for your particular engineering problem.

sofuture 16y ago

It's (still) stupid arguing that NoSQL systems are crappy at proving the things RDBMS systems provide. (Because they are, and no one has ever said differently, it's akin to yelling at a Bugatti Veyron (yeah, I went there) for being so bad at flying.) I'm not using CouchDB because I needed relationships and the RDBMS features of SQL Server but decided at the last minute 'Ehh oh well, let's just try this fancy NoSQL business, I'll rewrite all the RDBMS features into my code'. Believe it or not I'm using CouchDB because I want to run map/reduce on a bunch of JSON! Astounding, right!?

knodi 16y ago

I can't talk about all NoSQL but I can talk about CouchDB as I have worked with it some. It gives multiple write nodes, easy replications and syncing, it gave map reduce. I love it

random42 16y ago

I dont get the big hoopla about NoSQL. Its a different way of doing things than traditional RDBMS (which very successfully served us well for over 20 years). Why cant we just choose the best tool for the job, after looking at pros and cons?

8ren 16y ago

"A relational model of data for large shared data banks" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.1845&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110... He gives criticism of the then existing databases (hierarchical and network), then proposes the relational model and the concept of a query language (though not an actual languages - this predates SQL). Interestingly, one of the hierarchical databases (IMS) is still going strong: http://en.wikipedia.org/wiki/Information_Management_System#History http://en.wikipedia.org/wiki/Information_Management_System#H...

j_baker 16y ago

"The meaning of the statement was that NoSQL systems (really the various map-reduce systems) are lacking a standard model for describing and querying and that developing one should be a high priority task for them." I don't see why the relational model (or some subset thereof) won't work for most NoSQL databases. Key-Value store? It's essentially just a relational database where tables can have one primary key and one other column. Document store? Essentially just a dynamically typed relational database. Graph database? You probably would have to add to the relational model a bit, but Codd did write a bit about recursive queries.