Uncertain. The issue is still in the planning phase.
We'll only remove range sharding if we're confident that hash-based sharding provides an adequate replacement of course. It's possible we'll keep both.
Excited for this! We've been hoping to switch at least part of our infrastructure to Rethink, but were waiting for 2.0.
Are real benchmarks on the way with this release also? That's one critical thing we've been waiting to see. We want to see how it compares in common load scenarios to Mongo, Postgres, etc
I'm using RethinkDB for a new project I've been working on for the past few months, but I'm curious, why would you move existing infrastructure to RethinkDB? Is there a feature of RethinkDB that's good enough to motivate you to go through that process?
- changefeeds if you want to push data to your clients
- joins (if you are on a system without them - like Mongo)
- human-readable query language (if you are using SQL)
Exactly. Joins and changefeeds being the big ones. We won't switch over everything, at least to start, but there are a few places where switching a collection to RethinkDB could give us huge efficiency/simplicity gains just using joins. And it shouldn't be too hard to switch single collections over by using Compose.io's Transporters to backfill into Mongo.
16 comments
[ 3.0 ms ] story [ 47.1 ms ] threadSince rethink-guys are always in these threads:
What is your opinion on implementing compression/tokumx ?
What about custom-column-sharding, range-sharding, regex-sharding (redislabs has done this)?
Both compression and custom sharding are things we definitely want to do (https://github.com/rethinkdb/rethinkdb/issues/1862 , possibly https://github.com/rethinkdb/rethinkdb/issues/364).
I can't give an ETA on these features yet, but it will probably happen later this year.
Are real benchmarks on the way with this release also? That's one critical thing we've been waiting to see. We want to see how it compares in common load scenarios to Mongo, Postgres, etc
Are there any news on this front?