CoSQL: SQL and noSQL are really just two sides of the same coin | Hacker News Reader

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

cacm.acm.org

60 pointsjforman17 comments

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."

Seeing the author immediately increased my expectations: http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist...

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.

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

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.

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.

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.

http://code.google.com/p/redis/

"Redis - A persistent key-value database"

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.

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".

In Sicily you fit perfectly in a category called "cowards"

Weak. I read HN occasionally but haven't contributed in many months. I do pay attention to database theory / NoSQL stories, and I have noticed that you always appear always moving the goalposts around, in a manner that I think actually diminishes productive conversation.

To your core point, the author isn't saying they're all "the same". They're pointing out that the underlying premise is more alike than many -- who perhaps don't spend as much time on the nuances -- might not realize.

@antirez as in any mathematical proof the most generic case is considered first. If X is a special case or is exposing special corner scenarios, I'd assume that could be covered by extension proofs.

I'm not saying Erik's article is bullet proof. But it offers a very interesting perspective on two data models that were considered conflicting.

But should Redis really be part of that list? I feel like the strongest point of Redis is that it realistically allows devs to forget about any complex relational models living outside of the code logic, like the ones referred in the article. Other "NoSql" databases look like Redis, but the huge difference with the latter are its atomic operations on simple data structures (append, inc, push, intersect, union …). Redis is the only database that I know of that safely allows the developer to deal with relational data in such a straightforward, close-to-programming manner, and still talk with it at a pretty low level (without having to use mapper abstractions). The "data structure server" description probably serves the project better than "key-value store" in that sense.

want to consider the most generic case? Don't mention Redis as it is not a KV store from the point of view of the mathematical model proposed inside the article.

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

Huh? I'm going to need more than hand waving to get that assertion. Please expand.

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

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.

Reply on news.ycombinator.com