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

61–70 of 79 posts

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

#61

Post by coffeemug »

br1 wrote: post #60
coffeemug wrote: post #27

Earlier quoted context omitted.

You're right, but it's not just `filter`. Any command that can run on a group can run on a full table and vice versa. For example: # get a sample of 3 elements from a table r.table('foo').sample(3) # get a sample of 3 elements from each group r.table('foo').group('category').sample(3) You could say that we created two versions of `filter`, and `sample`, and every other command. But another way to say it is that we us…

As a LINQ user, I expected group('category').sample(3) to sample 3 categories, not to sample inside each category.

In ReQL you can do it with group('category').ungroup().sample(3). It's really powerful once you get the hang of it.

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

#62

Post by coffeemug »

RivieraKid wrote: post #58

What are the three top practical reasons to choose RDB over a traditional database such as Postgres?

There are two main reasons:

1. If you're dealing with JSON, a native JSON database provides a 100x better programming experience than a relational system. 2. Scalability out of the box. You can just add a node, reshard, and keeping going. It's much harder in relational systems.

If you have lots of null columns, hierarchical relationships, or eventual need for scale out, give RethinkDB a try.

If you have traditional rigid data or ACID requirements, stick with a relational DB.

Hope this helps.

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

#63

Post by dkhenry »

RyanZAG wrote: post #53
dkhenry wrote: post #47

Earlier quoted context omitted.

So the way all underlieing communication is done is through a protobuf. So in python I know they hijack the expression and they can then construct the protobuf from the passed in python lambda. In Java land we can't really do that since lambdas are desugared at compile time to just be functions. In Java I can't even overload operators like you can in Scala or C++ to make it a little nicer. The result is your pretty m…

Take a look at this work by jooq: http://blog.jooq.org/2014/03/21/java-8-friday-java-8-will-re... You may be able to utilize a lot of their code for converting the lambda bytecode.. or not. Anyway it's interesting to see how they're dealing with the problem you've run into.

Well that looks promising. I will need to make a JDK8 branch to integrate this.

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

#64

Post by kclay »

dkhenry wrote: post #31

I love the elegance of ReQL and how well it works in dynamic languages, but I still can't figure out a good way to port that lambda syntax used in python into the Java driver.

I could provide some assistance, I've did the scala driver and was making it work with java . When I get some time I'll submit a pull request.

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

#65

Post by weixiyen »

slap_shot wrote: post #25

RethinkDB is my favorite piece of my current tech stack. I tell everybody I know about it, and I'm soon to release some blog posts and speak at a Meetup showing off what it is good at and how to get started - I really just can't say enough good stuff about these guys. A high level overview from someone who has used it in production since 1.10 (about six months): Pros: * ReQL is a beautiful DSL that makes querying and…

Ditto. Also appreciated is the upfront honesty about what their tech can and cannot do currently, and what they plan to do to address limitations / bugs.

I really love their ability to design sensible APIs paired with their honesty, gives me the confidence to begin using this software right now with belief that it will eventually get to a very stable point.

Would not use it for any multi-million$ business just yet but it's perfect for personal projects that require quick iteration which might in the future become big.

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

#66

Post by dataminded »

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…

Background: I've done a fair bit of hiring for analysts and have worked in most facets of analytics/DW including vendor evaluation/selection and implementation.

I think that the lack of a SQL interface is a big negative. It's really hard to find analyst (not programmers) with good technical skills or train them to proficiency in new technologies. I would have a very hard time selling a platform that existing analysts wouldn't be able to use right away and that few people on the market could work with.

Also, designing a new language makes integration with other applications that much harder.

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

#67

Post by pandemicsyn »

transientbug wrote: post #44

RethinkDB is pretty awesome. Its a blast working with it and the Python driver is quite well rewritten, imo. As the author of PyRethinkORM for Python it was ridiculously easy to write compared to an ORM for say SQL which was a major selling point for using RethinkDB behind my last several projects. I'm fairly excited about the ARM port as I've been wanting to use Rethink on a few projects on my BeagleBone White/Black…

The python driver is cool (and PyRethinkORM was super handy!), but setting up the driver to use the optimized protobuf backend was a PITA.

http://www.rethinkdb.com/docs/driver-performance/

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

#68

Post by nXqd »

dataminded wrote: post #66
coffeemug wrote: post #6

Earlier quoted context omitted.

> 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…

Background: I've done a fair bit of hiring for analysts and have worked in most facets of analytics/DW including vendor evaluation/selection and implementation. I think that the lack of a SQL interface is a big negative. It's really hard to find analyst (not programmers) with good technical skills or train them to proficiency in new technologies. I would have a very hard time selling a platform that existing analysts…

You can find the answer to this in coffeemug' post :

"We're assuming people will be using ReQL fifteen years from now."

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

#69

Post by chipotle_coyote »

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'm not really sure how you could wedge SQL into a system that doesn't really have the concept of columns without it being, at the least, a distinctly different dialect.

And, really, if you've worked with some of the "higher level" interfaces to SQL like SQLAlchemy or Laravel's QueryBuilder, ReQL doesn't seem that alien; they all tend to work by method chaining as well. (But they usually don't support everything SQL does, unlike ReQL's interfaces.)

Also: unlike my (admittedly limited) exposure to other NoSQL systems, RethinkDB supports relations and joins -- it's actually a lot easier for an SQL fiend to move to Rethink than any of its competitors.

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

#70

Post by coffeemug »

dataminded wrote: post #66
coffeemug wrote: post #6

Earlier quoted context omitted.

> 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…

Background: I've done a fair bit of hiring for analysts and have worked in most facets of analytics/DW including vendor evaluation/selection and implementation. I think that the lack of a SQL interface is a big negative. It's really hard to find analyst (not programmers) with good technical skills or train them to proficiency in new technologies. I would have a very hard time selling a platform that existing analysts…

That's a great point. Our hypothesis is that great querying capabilities for analysts and great querying capabilities for programmers should look completely different, and be two totally different technologies. We'll eventually ship a solution for analysts, but I don't think a great database product should shoot for a lowest common denominator.
Post reply on HN