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

71–79 of 79 posts

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

#71

Post by coffeemug »

pandemicsyn wrote: post #67
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/

Hey, sorry you (and everyone else) ran into this! This will go away in the next version (1.13), because we're removing the requirement for protobufs and supporting a pure json transport interface. It turns out to be both faster, easier to setup, and paradoxically more space efficient.

See https://github.com/rethinkdb/rethinkdb/issues/1868 for more details.

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

#72

Post by shin_lao »

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…

It's great to see someone with a lot of enthusiasm, but I submit you think too much like a programmer and not enough like a database administrator.

What problem does your product solve that, for example, PostgreSQL doesn't?

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

#73

Post by coldtea »

fidotron wrote: post #26
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 totally the opposite, and blame you entirely for provoking what follows! SQL at this point is passed expiry. The simple reason is we now have plenty of decent scripting languages to run as interactive prompts, all of which are far better at interfacing with the rest of the system than SQL is. Exposing a sane, direct, API in those languages gets you much more than SQL, along with having removed multiple layers of…

>I'm totally the opposite, and blame you entirely for provoking what follows! SQL at this point is passed expiry.

Actually it's the very opposite.

SQL is a higher level abstraction for all this ad-hoc junk, based on actual mathematical principles (relational algebra), and it's also declarative, instead of imperative.

Furthermore, all this NoSQL query systems now emerging are nothing new. They were tried in the 70s and early 80s, and people found out that they sucked. Before SQL what we had was, well, NoSQL.

Wanting a flexible schema-less db or one that's denormalised for certain needs (like Google's or Facebook's) makes sense.

Replacing SQL and RBDMS for the common tasks they are used (company logistics and accounting, etc) with NoSQL is a regression to the primitive past. I guess people not knowning (computing) history are doomed to repeat it.

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

#75

Post by RivieraKid »

coffeemug wrote: post #62
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 r…

Thanks, that definitely helps.

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

#76

Post by dkhenry »

kclay wrote: post #64
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.

I was about to abandon my Java driver for your Scala driver at one point. Scala is just a better language in so many regards.

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

#77

Post by kclay »

dkhenry wrote: post #76
kclay wrote: post #64

Earlier quoted context omitted.

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.

I was about to abandon my Java driver for your Scala driver at one point. Scala is just a better language in so many regards.

I feel your pain, If I had to do it all in java I would of cried to no end.

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

#78

Post by egeozcan »

coffeemug wrote: post #9
egeozcan wrote: post #8

Earlier quoted context omitted.

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

Hi, do you have any plans to support FreeBSD?

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

#79

Post by transientbug »

pandemicsyn wrote: post #67
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/

Bit late on this (school gets the better of me most days), but thanks! I'm glad (and happy) that PyRethinkORM has been helpful to someone.
Post reply on HN