9 ms·

CoSQL: SQL and noSQL are really just two sides of the same coin

60 points by jforman 16y ago

rch 16y ago
This article turned out better than I thought it would. Here's why: "In this article we present a mathematical data model for the most common noSQL databases—namely, key/value relationships—and demonstrate that this data model is the mathematical dual of SQL's relational data model of foreign-/primary-key relationships."
- Confusion 16y ago
  Seeing the author immediately increased my expectations: http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist) http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist...
  - luke_s 16y ago
    Erik Meijer gave a presentation on this during YOW 2010, in Melbourne. The ideas are very deep, and I hope they will be taken on board by the IT industry and find practical applications. It would be nice to think that at YOW we witnessed part of the birth of an idea, that will revolutionise the way think about data storage.
    - endgame 16y ago
      That was a fantastic conference. I enjoyed Erik's presentations. Guy Steele's lecture was also very good, but his keynote with Richard P. Gabriel was incredible. He's actually done the 50 in 50 keynote before: http://blip.tv/file/1472720 http://blip.tv/file/1472720
- cploonker 16y ago
  I agree. If noSQL/SQL vendors start providing a common query mechanism for both SQL and coSQL, it will lead to huge adoption of noSQL products resulting in a huge transformational effect on data persistence.
antirez 16y ago
the author mentions Redis but fails to analyze the peculiar data model of Redis that I think can't be considered mathematically dual with SQL's relational model... unless you want to use every row of a table as a node with fields for pointers and build skip lists out of that... The fact that Redis is analyzed as a KV store is already a big enough proof by the over simplification that the author is performing here, in the name of proving his point.
- mooftard 16y ago
  "Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets." Damn, the oversimplifiers got to http://redis.io/ http://redis.io/ too! Are you saying that the key types in Redis make it special? Slightly-more-than-simple-types do not sound too special. What's it got going on?
- bogomips 16y ago
  http://code.google.com/p/redis/ http://code.google.com/p/redis/ "Redis - A persistent key-value database" http://redis.io/ http://redis.io/ "Redis is an open source, advanced key-value store" I'm not sure what sort of extended commentary you expected about Redis - it isn't quite as important of a project as you seem to think it is (seriously, are you always commenting on HN?) EDIT: In case this wasn't already painfully clear, Antirez has an annoying habit of constantly moving the goal lines, making it virtually impossible to discuss Redis in any context unless it is pure, unbridled awe and praise. Then again, Antirez is a HN "celebrity" so expect nonsense like the above to be voted up by the proles.
  - deleted 16y ago
    [deleted]
  - antirez 16y ago
    1) one thing is communication, one thing is math. For communication we need to write in the project home page that Redis is a key-value store, as people see this outer shell when they still don't know the project. But it is easy to realize that inside every of the supported values types lives another, nested, data model. 2) I'm not making any assumption on the importance of Redis. The fact is, the article mentions it, then draws conclusions not applicable to Redis. 3) I don't see how I move the goal lines, please if you have any kind of intellectual honor, let's discuss why exactly my statement is not true: Redis was listed in the article, than a pure key-value model (a map between a constant value and another constant value) is analyzed, even if Redis does not fit. Moreover the article has no real point as even with a simple model like the key value one I can model any complex data model (I can use every key-val pair as a node for a B-Tree and build an SQL DB on top of that), what this means, that all the databases are equivalent? It is clear to most people that the new databases are mainly a new set of compromises between consistency, complexity of operations, implementation tradeoffs. The fact that mathematically is the same is no sense. Are all the turing-complete languages the same? Edit: I see you created your account 9 hours ago. In Sicily you fit perfectly in a category called "cowards".
techtalsky 16y ago
I actually see this article as a good sign. This kind of article could set the tone for the beginning of sane discussion about the SQL/coSQL ecosystem and how to move forward in developing a shared toolset for developers.
a18x 16y ago
I'm amazed how people tend to overcomplicate simple things. Isn't the noSQL algebra is just relational algebra without the Cartesian product operator?
- kenjackson 16y ago
  Huh? I'm going to need more than hand waving to get that assertion. Please expand.
  - a18x 16y ago
    My assertion means that relational algebra without Cartesian product operator can be used for noSQL databases, except graph databases. Primitive operators of relational algebra such as projection, selection and set operators are pretty much scalable. Cartesian product is not. Authors mentioned that property of the Cartesian product in the example with WWW database. In order to emulate Cartesian product in noSQL developers have to use external tools such as Map Reduce which has nothing to do with databases. http://typicalprogrammer.com/?p=16 http://typicalprogrammer.com/?p=16
  - a18x 16y ago
    Continuation of the previous post... Why wouldn’t the noSQL providers use SQL as a starting point? Take SQL standard, relax transactional requirements from ACID to BASE, add functions for searching in columns, add a note that execution of queries with Cartesian product may be extremely slow (with Map Reduce or other parallelization technology. Let the database vendors compete in that field). I recommend book “Data-Intensive Text Processing with MapReduce” by Jimmy Lin and Chris Dyer book for further reading on how to implement relational joins with MapReduce. DML and DDL will be changed substantially, though. Drop or relax relational constraints, different table definition etc. As for coSQL, it looks to me like it introduces Codasyl-syle queries instead of relational algebra.

60 points by jforman 16y ago

rch 16y ago

This article turned out better than I thought it would. Here's why: "In this article we present a mathematical data model for the most common noSQL databases—namely, key/value relationships—and demonstrate that this data model is the mathematical dual of SQL's relational data model of foreign-/primary-key relationships."

Confusion 16y ago
Seeing the author immediately increased my expectations: http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist) http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist...
- luke_s 16y ago
  Erik Meijer gave a presentation on this during YOW 2010, in Melbourne. The ideas are very deep, and I hope they will be taken on board by the IT industry and find practical applications. It would be nice to think that at YOW we witnessed part of the birth of an idea, that will revolutionise the way think about data storage.
  - endgame 16y ago
    That was a fantastic conference. I enjoyed Erik's presentations. Guy Steele's lecture was also very good, but his keynote with Richard P. Gabriel was incredible. He's actually done the 50 in 50 keynote before: http://blip.tv/file/1472720 http://blip.tv/file/1472720
cploonker 16y ago
I agree. If noSQL/SQL vendors start providing a common query mechanism for both SQL and coSQL, it will lead to huge adoption of noSQL products resulting in a huge transformational effect on data persistence.

antirez 16y ago

the author mentions Redis but fails to analyze the peculiar data model of Redis that I think can't be considered mathematically dual with SQL's relational model... unless you want to use every row of a table as a node with fields for pointers and build skip lists out of that... The fact that Redis is analyzed as a KV store is already a big enough proof by the over simplification that the author is performing here, in the name of proving his point.

mooftard 16y ago
"Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets." Damn, the oversimplifiers got to http://redis.io/ http://redis.io/ too! Are you saying that the key types in Redis make it special? Slightly-more-than-simple-types do not sound too special. What's it got going on?
bogomips 16y ago
http://code.google.com/p/redis/ http://code.google.com/p/redis/ "Redis - A persistent key-value database" http://redis.io/ http://redis.io/ "Redis is an open source, advanced key-value store" I'm not sure what sort of extended commentary you expected about Redis - it isn't quite as important of a project as you seem to think it is (seriously, are you always commenting on HN?) EDIT: In case this wasn't already painfully clear, Antirez has an annoying habit of constantly moving the goal lines, making it virtually impossible to discuss Redis in any context unless it is pure, unbridled awe and praise. Then again, Antirez is a HN "celebrity" so expect nonsense like the above to be voted up by the proles.
- deleted 16y ago
  [deleted]
- antirez 16y ago
  1) one thing is communication, one thing is math. For communication we need to write in the project home page that Redis is a key-value store, as people see this outer shell when they still don't know the project. But it is easy to realize that inside every of the supported values types lives another, nested, data model. 2) I'm not making any assumption on the importance of Redis. The fact is, the article mentions it, then draws conclusions not applicable to Redis. 3) I don't see how I move the goal lines, please if you have any kind of intellectual honor, let's discuss why exactly my statement is not true: Redis was listed in the article, than a pure key-value model (a map between a constant value and another constant value) is analyzed, even if Redis does not fit. Moreover the article has no real point as even with a simple model like the key value one I can model any complex data model (I can use every key-val pair as a node for a B-Tree and build an SQL DB on top of that), what this means, that all the databases are equivalent? It is clear to most people that the new databases are mainly a new set of compromises between consistency, complexity of operations, implementation tradeoffs. The fact that mathematically is the same is no sense. Are all the turing-complete languages the same? Edit: I see you created your account 9 hours ago. In Sicily you fit perfectly in a category called "cowards".

techtalsky 16y ago

I actually see this article as a good sign. This kind of article could set the tone for the beginning of sane discussion about the SQL/coSQL ecosystem and how to move forward in developing a shared toolset for developers.

a18x 16y ago

I'm amazed how people tend to overcomplicate simple things. Isn't the noSQL algebra is just relational algebra without the Cartesian product operator?

kenjackson 16y ago
Huh? I'm going to need more than hand waving to get that assertion. Please expand.
- a18x 16y ago
  My assertion means that relational algebra without Cartesian product operator can be used for noSQL databases, except graph databases. Primitive operators of relational algebra such as projection, selection and set operators are pretty much scalable. Cartesian product is not. Authors mentioned that property of the Cartesian product in the example with WWW database. In order to emulate Cartesian product in noSQL developers have to use external tools such as Map Reduce which has nothing to do with databases. http://typicalprogrammer.com/?p=16 http://typicalprogrammer.com/?p=16
- a18x 16y ago
  Continuation of the previous post... Why wouldn’t the noSQL providers use SQL as a starting point? Take SQL standard, relax transactional requirements from ACID to BASE, add functions for searching in columns, add a note that execution of queries with Cartesian product may be extremely slow (with Map Reduce or other parallelization technology. Let the database vendors compete in that field). I recommend book “Data-Intensive Text Processing with MapReduce” by Jimmy Lin and Chris Dyer book for further reading on how to implement relational joins with MapReduce. DML and DDL will be changed substantially, though. Drop or relax relational constraints, different table definition etc. As for coSQL, it looks to me like it introduces Codasyl-syle queries instead of relational algebra.