Live data from Hacker News

RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

rethinkdb.com

11–20 of 105 posts

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#11
post #9

Does RethinkDB do multiple atomic updates?

Nope, operations on a single document are atomic, but not on multiple documents. MongoDB works the same way.

AFAIK, the only NoSQL DB with support for multi-doc transactions is HyperDex [0].

[0] - http://hyperdex.org/

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#12
post #11
post #9

Does RethinkDB do multiple atomic updates?

Nope, operations on a single document are atomic, but not on multiple documents. MongoDB works the same way. AFAIK, the only NoSQL DB with support for multi-doc transactions is HyperDex [0]. [0] - http://hyperdex.org/

OrientDB also has multi-document transactions, I believe.

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#13
post #5

Seems a bit unconventional to manually specify which index you'd like to use when writing queries. This would normally be something handled by a query optimizer. Of course, many DBMS provide some facility for specifying indices manually through query hinting, but for non-trivial queries, the optimizer often can do a better job than a programmer at picking the most efficient query plan.

Hi, I implemented secondary indexes in RethinkDb.

This was an intentional choice we made for a couple of reasons. The most pragmatic one was that we don't have an optimizer and we thought that secondary indexes could still be useful to a lot of people without one. And we've found it's always better to ship early and get feedback sooner rather than later.

Another reason though is we're not totally sure we're sold on the state of the art of query optimizers. From what we've seen they can introduce a number of non intuitive behaviors and it can be hard to tell which operations will use which index. Query optimizers are nice when they work correctly but they don't always work correctly so for the first release of secondary indexes we opted to make something that had very clear precise semantics and then build on it. We will eventually have a query optimizer but it's a big problem and we don't just want to implement what others have because we think we can do better.

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#14
post #4

I love RethinkDB API. It makes joins possible without going through mapreduce. Though I am using MongoDB currently, I plan on switching to RethinkDB as soon as it is more stable and provides better performance. Excited to see the team making progress on all fronts.

It makes joins possible without going through mapreduce.

This is pure gold https://twitter.com/shit_hn_says material :)

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#15
post #5

Seems a bit unconventional to manually specify which index you'd like to use when writing queries. This would normally be something handled by a query optimizer. Of course, many DBMS provide some facility for specifying indices manually through query hinting, but for non-trivial queries, the optimizer often can do a better job than a programmer at picking the most efficient query plan.

Hi, I implemented secondary indexes in RethinkDb. This was an intentional choice we made for a couple of reasons. The most pragmatic one was that we don't have an optimizer and we thought that secondary indexes could still be useful to a lot of people without one. And we've found it's always better to ship early and get feedback sooner rather than later. Another reason though is we're not totally sure we're sold on t…

+1, a good approach could be to still make users able to specify manually what index to use even when the optimizer will be available. Sometimes humans just know better.

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#16
post #11
post #9

Does RethinkDB do multiple atomic updates?

Nope, operations on a single document are atomic, but not on multiple documents. MongoDB works the same way. AFAIK, the only NoSQL DB with support for multi-doc transactions is HyperDex [0]. [0] - http://hyperdex.org/

Also http://www.rethinkdb.com/docs/advanced-faq/. RethinkDB started out as a MySQL driver that was lock-free and did schema updates non-stupidly, but it sounds like they've abandoned ACID and schema enforcement entirely like almost all NoSQL systems (as if what I wanted is faster wrong answers).

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#17
post #15

Earlier quoted context omitted.

Hi, I implemented secondary indexes in RethinkDb. This was an intentional choice we made for a couple of reasons. The most pragmatic one was that we don't have an optimizer and we thought that secondary indexes could still be useful to a lot of people without one. And we've found it's always better to ship early and get feedback sooner rather than later. Another reason though is we're not totally sure we're sold on t…

+1, a good approach could be to still make users able to specify manually what index to use even when the optimizer will be available. Sometimes humans just know better.

That's something we'll make sure to keep around indefintely. I always hate things that are too magically, which optimizers frequently seem to me, but I also get why they're useful to people. The best compromise I think is to give people the magic and a way to opt out of the magic.

Re: RethinkDB 1.5 released: secondary indexes, soft durability, perf improvements

#18
post #11
post #9

Does RethinkDB do multiple atomic updates?

Nope, operations on a single document are atomic, but not on multiple documents. MongoDB works the same way. AFAIK, the only NoSQL DB with support for multi-doc transactions is HyperDex [0]. [0] - http://hyperdex.org/

I believe MarkLogic does too.
Post reply on HN