Live data from Hacker News

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

rethinkdb.com

101–105 of 105 posts

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

#101

Earlier quoted context omitted.

I didn't say "execute queries", I said search. Unless you have a tiny amount of data, no indexes means searching is not feasible.

The way you search on a key-value store with no secondary indexes is create the secondary indexes manually as separate tables.

Or just use a database instead of creating problems for no reason.

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

#102
post #63

Earlier quoted context omitted.

I'm sure you'll appreciate the irony of this, but what you described is pretty much the exact mechanism of the MongoDB query optimizer [0]. [0] - http://docs.mongodb.org/manual/core/read-operations/#query-o...

A cost-based optimizer also needs a way to handle the combinatorial explosion of possible plans. For MongoDB, maybe they can be exhaustive or use a simple strategy. But for a SQL DBMS, the search space is way too huge, and you need a way to navigate it intelligently. This "try the plan out" idea has come up many times, and it's a reasonable idea, but it's nothing new and not a complete solution. You need a way to eva…

I am not disputing the value of a cost based optimizer.

I'm just pointing out that if you have an existing plan that seems to be currently working the default should be to not just switch it up without testing that your switch didn't hurt anything. Instead you need to use care.

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

#103
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/

And HyperDex only supports them via a proprietary plug-in.

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

#104
post #100

Earlier quoted context omitted.

The reason we (and probably Mongo folks) do it this way is because JSON is case-sensitive, so making indexes case-insensitive wouldn't work very well. EDIT: it looks like I misread your comment. I was talking about index/field names, while I think you were talking about field values. In this case Sam's comment below is correct -- once we add string.toLower() (which is very easy) you'll be able to do case-insensitive…

Installed and played with (1.3 I think) and it looks very promising but the ability to query and order by case-insensitive text is a requirement for us. Our app deals with user provided names of people, places and things that are commonly searched and sorted. So not using RethinkDB today, but I am 100% in love with what you guys are trying to accomplish.

I added a github issue for this -- https://github.com/rethinkdb/rethinkdb/issues/845. We should solve this soon.

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

#105
post #95

So is this production ready? Excited about this, but I don't have time at the moment to dabble on things I can't use and the last comment regarding this is a post on Quora from the founder saying that it is not production ready yet. 1.0+ version numbers makes you think this isn't beta software anymore, but that doesn't seem to be the case.

We'll bump the version to 2.0 when the product is production ready (the 1.x versioning scheme is an accident that unfortunately we can't do much about).
Post reply on HN