Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

rethinkdb.com

Post reply on HN
Print view View original

1–10 of 79 posts

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#2

Post by taf2 »

I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#3

Post by neumino »

taf2 wrote: post #2

I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(

ReQL is a new query language, and indeed requires the user to learn it but

- It's actually easy to learn -- especially with the data explorer

- It's nicer to use than SQL -- You can chain commands in the language you are using

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#4

Post by teraflop »

taf2 wrote: post #2

I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(

One reason is that SQL only lets you work with flat relational tables. MongoDB and RethinkDB let you store complex JSON-like objects as values, and extending SQL to query and manipulate those kinds of structures is hard. The closest attempt I've seen is Google's BigQuery.

Another reason is that SQL does its best to decouple the query (what you're asking for) from the execution plan (how it actually gets evaluated). But for operations like joins, the precise way the query is evaluated can have a huge effect on performance. So it makes sense to design your query language to explicitly expose those knobs to the programmer.

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#6

Post by coffeemug »

taf2 wrote: post #2

I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(

> I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface.

Actually, it's a really good question. I'm one of the ReQL designers at Rethink, and I was the one pushing for no SQL compatibility. Here is some of my reasoning (we could talk about this for days, though):

  * Even SQL designers would tell you SQL isn't a very good
    programming language. It even looks like Cobol! Imagine if
    every language after Cobol decided to be backwards compatible
    -- what sort of world would we live in?
  
  * SQL is really bad for querying hierarchical data with lots of
    empty columns. The quality of experience you get from learning
    a new language designed for JSON, far outweighs the downsides
    of learning it. We're assuming people will be using ReQL
    fifteen years from now.
  
  * Designing a language that embeds into your programming language
    wasn't possible before -- but it is now. That means no more SQL
    injection, no more string manipulation, no more heavy
    ORMs. Well worth it in my opinion.
  
  * The chaining paradigm (largely pinoneered and proven by jQuery)
    is magical for getting people to intuitively understand how to
    write complex queries. No more StackOverflow questions of "How
    do I do X in SQL?" because there is now an intuitive
    consistency to the language.
  
  * SQL compatibility is very, very difficult. The standard is hard
    to implement, and has lots of grey area around the edges. You
    can go for full bug-by-bug compatibility, which would take
    decades. Or you can go for basic compatibility, which confuses
    people. They try to port their application, it works for a
    while, and then breaks in some grey area in production, which
    results in a terrible user experience.
As an example, I'd ponder on why SQL has both the `where` keyword, and the `having` keyword. This alone wouldn't be enough of a reason to design a new language, of course, but this sort of thing permeates SQL. It's 2014. We can do better.

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#8

Post by egeozcan »

farhanpatel wrote: post #7

Has anyone used RethinkDB for a relative large database(100GB+)? I cant seem to find performance benchmarks anywhere.

That's something I've been searching for, too. I actually opened this page, wishing that someone linked to a benchmark for large data sets. Large datasets are the reason I'm trying to move away from mongodb completely, and I've been very happy with postgres but I'm willing to give a try to others.

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#9

Post by coffeemug »

egeozcan wrote: post #8
farhanpatel wrote: post #7

Has anyone used RethinkDB for a relative large database(100GB+)? I cant seem to find performance benchmarks anywhere.

That's something I've been searching for, too. I actually opened this page, wishing that someone linked to a benchmark for large data sets. Large datasets are the reason I'm trying to move away from mongodb completely, and I've been very happy with postgres but I'm willing to give a try to others.

Hi, slava @ rethink here.

We'll be publishing benchmarks and case studies for large data sets in the coming months. You might want to wait for those because there will be tons of info, and lots of bugs that I'm sure are still lurking ironed out. However, if you want to be one of the early adopters and give it try, we'd absolutely love your feedback and will work hard to incorporate it into the product.

You can use our regular channels for feedback (rethinkdb.com/community), your shoot me an e-mail any time -- slava@rethinkdb.com.

Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure

#10

Post by shawn-butler »

coffeemug wrote: post #6
taf2 wrote: post #2

I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(

> I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. Actually, it's a really good question. I'm one of the ReQL designers at Rethink, and I was the one pushing for no SQL compatibility. Here is some of my reasoning (we could talk about this for days, though): * Even SQL designers would tell you SQL isn't a very good programming language. It even looks like Cobol! Imagine i…

HAVING specifies a search condition for a group or an aggregate function.
Post reply on HN