We use RethinkDB

Re:We use RethinkDB by tracker1 on Wednesday March 11, 2015 @04:18PM (#9186867)

FYI, with MongoDB, just because you can't and shouldn't index everything, doesn't mean you can't have any indexes... if your most common fields bring your queries down, they're still pretty helpful.

I actually really like where RethinkDB is headed, and within the year most of my issues should be resolved.

Another couple databases to consider, depending on your needs would be ElasticSearch and Cassandra... it reallly depends on your use case.

[ Parent | on HN ]

Re:We use RethinkDB by coffeemug on Wednesday March 11, 2015 @04:25PM (#9186922)

Could you list your issues with Rethink? It would really help for product prioritization.

[ Parent | on HN ]

Re:We use RethinkDB by tracker1 on Wednesday March 11, 2015 @04:36PM (#9187015)

As mentioned in another thread, automagic failover the one still pending, and geospatial indexes/searches (now in the product).

It's wild how many options there are that tailor themselves to all kinds of data out there.

[ Parent | on HN ]

Re:We use RethinkDB by pests on Wednesday March 11, 2015 @05:55PM (#9187659)

I'm not involved with RethinkDB but I lurk on their github issues and I'm pretty confident that automagic failover is dependent on them getting (their own implementation of) Raft integrated with everything. Looks like its getting close as a whole slew of issues were opened just the other day relating to Raft work.

[ Parent | on HN ]

Re:We use RethinkDB by jefficient on Wednesday March 11, 2015 @05:41PM (#9187567)

Are unique indexes planned for any of the upcoming releases?

[ Parent | on HN ]

Re:We use RethinkDB by coffeemug on Wednesday March 11, 2015 @05:53PM (#9187644)

The primary index for the table is always unique.

We do not plan to implement secondary unique indexes. The philosophy behind RethinkDB is that if a feature cannot be efficiently scaled across multiple nodes we don't add it, and unfortunately unique secondary indexes are one such feature.

AFAIK most NoSQL databases don't implement it, and a few that do take two approaches -- forbid it on multiple shards, or just take a massive performance hit during sharding.

We chose to keep the feature out of the database. This way the application can be architected to account for it, so it remains fast as the database scales up.

[ Parent | on HN ]

Re:We use RethinkDB by mrkurt on Wednesday March 11, 2015 @07:35PM (#9188198)

This is good, for what it's worth. Having different feature sets for sharded vs unsharded is just utterly confusing, and something MongoDB got really wrong.

[ Parent | on HN ]

Re:We use RethinkDB by felipesabino on Wednesday March 11, 2015 @05:53PM (#9187649)

Oh yes, agreed! and we do have some indexes, but unfortunately it isn't enough :(

And we are actually considering ElasticSearch to deal with this querying performance issue.

[ Parent | on HN ]

Re:We use RethinkDB by tracker1 on Wednesday March 11, 2015 @08:10PM (#9188366)

We had a similar issue with queries that didn't match an index... later pages would time out, etc... we limited our results for that class of queries... The next generation will use cassandra with some custom searching/caching... that will work a bit differently.

[ Parent | on HN ]