RethinkDB 1.9: Indexing and query runtime performance
rethinkdb.com
rethinkdb.com
1) Their team is extremely responsive. In fact, the most responsive team that I've dealt with on Github. I've posted at least 4 Github issues during various times of the day and evening and I've gotten a response in less than 10 minutes. Most of the time, more than one member responded.
2) They are not over selling their product like MongoDB did. They are very clear about what their product does and doesn't do.
3) Clustering is stupidly simple. You can have one setup within minutes and have your servers geographically located throughout the world.
4) The web UI makes administering the databases easy and fun.
After they get the kinks (stability & docs) fixed, this database will definitely have a bright future.
EDIT: also, thanks for the kind words!
I hope I get a reason to use Rethink soon again, the team has just been great and the product itself is ticking all the right boxes with me.
RethinkDB + Docker is a great setup for me and has made upgrading between versions of RethinkDB less painful, and when combined with tinc, clustering is really easy as well (DigitalOcean, where I'm experimenting with RethinkDB, doesn't support Amazon VPC-like functionality and only recently added support for a private network in one region).
The counter-argument is that they can move so quickly and improve so much because so much is so poorly implemented. While it may seem cynical, I have formed a habit of eliminating projects that still see magnitudes performance improvements from such rudimentary activities. Once they get to the point where a yearly release are a couple of syntax improvements and some minor speedups, it is more likely to be production ready.
- Talking to files with libaio -- we now only support use of blocking I/O calls in a thread pool.
- Use of block devices instead of files, and code optimized for older SSDs that spread writes to different parts of the disk.
- A fsck utility and a utility for extracting data from a corrupted file.
Most other stuff has been rewritten and refactored, though -- RethinkDB was once implemented entirely using callbacks on an epoll loop. Then we introduced coroutines (cooperative green threads that sit atop an epoll loop) into the codebase. Nowadays almost everything is implemented in terms of coroutines -- there aren't many APIs left that take a callback and say it'll get called sometime later. There's even still a secret memcache interface.
The storage engine itself does a bit more now than it used to. Support for secondary indexes, MVCC, efficiently bringing back out-of-date replicas, and better on-disk storage are the main ones I can think of at this hour.
In the past two years our top two goals (hopefully like any high-tech startup) were to build a product that electrifies people and has a solid architecture. The reasoning was that if people don't want the product nothing else matters, and if people do want the product but the architecture doesn't allow rapid changes, we'll lose.
Really good implementations of specific features was priority number three, and while we did a lot of that too, it sometimes took a backseat in light of the first two. That's ok though -- now that we have a rapidly growing user base and a solid technical architecture we can go back and replace placeholder implementations with better ones according to user demand. We're not entirely happy with all our choices, but no one ever is. I think that the overall direction worked out really really well for RethinkDB and its users.
EDIT: gruseom and mrkurt beat me to it.
It performs really well (sub-second queries over millions of rows) but it's licensed by data volume and (more importantly) it's a single-server solution - at some point we're going to need a distributed database.
Is RethinkDB suitable for analytics workloads like this?
For example https://edelweiss.cloudant.com/automat/_design/cryo_2/_view/...
These are the stats for a particular measured value between two dates. Change the dates and you'll see that the return is pretty quick.
Change startkey to "T_Bolo", 1378940038 and you'll get the statistics of that value for the last ~hour. You get sum, but also average and standard deviation.
full disclosure: I work at Cloudant.
cheers, Adam
The author stopped working on it for a little because he was tired of refactoring his code as the protocol changed and figured he would just add all the missing bits once they finished the protocol.
By Tomorrow I will have them updated to APL ( luckily I can do this since no one else has really supplied a pull request :-( )
We strongly recommend all community drivers use a less restrictive license like Apache 2 (or other license of choice).
Also: dkhenry, thanks for all your hard work in helping bring RethinkDB to the Java community!
Also, I understand that 'benchmarking' databases is extremely situational and generally inaccurate. However, without reasonable ways to measure an increase in performance, its really hard for me to make the decision to switch from mongo to rethink.
What I'm trying to ask is, does anyone have any information that can help me decide where, how, when and why should I use make the decision to switch from mongo to rethink? Not just for me but also so that I can show others in my team to get a consensus to switch.
* Technical comparison: http://rethinkdb.com/docs/comparison-tables/
* A slightly more biased comparison: http://rethinkdb.com/docs/rethinkdb-vs-mongodb/