any plans of releasing officially supported Java driver? For most enterprise oriented apps, having officially supported Java driver will be great.
Yes! No ETA yet, but we're on it.
RethinkDB 2.0 is now production ready
81–90 of 156 posts
Re: RethinkDB 2.0 is now production ready
#82I wish they did official TypeScript definition files. I'm a bit wary to rely on huge DB API with community definitions only. There are reasons to write TypeScript definitions for documentation generation too, if not for the code as TS.
There is an official spec here: http://rethinkdb.com/docs/writing-drivers/ Not quite TS, but it's well defined and new releases of the spec are carefully managed.
Re: RethinkDB 2.0 is now production ready
#83Cool! I've started to look into RethinkDB in the past, and I'm very interested in the features it claims. However, I only have so much time to investigate new primary storage solutions, and our team has been burned in the past by jumping too quickly on a DB's bandwagon when the reliability, performance, or tooling just wasn't there. As of late, we've come to rely on Aphyr's wonderful Call Me Maybe series[0] as a guid…
Slava @ Rethink here. This is a great point, and we're on it! We have a Raft implementation that unfortunately didn't make it into 2.0 (these things require an enormous amount of patient testing). The implementation is designed explicitly to support robust automatic failover, no interruptions during resharding, and all the edge cases exposed in the Jepsen tests (and many issues that aren't). This should be out in a f…
Another good one for testing distributed systems/databases is blockade: http://blockade.readthedocs.org/en/latest/
Re: RethinkDB 2.0 is now production ready
#84Lots of congratulating on this thread and a hell of a lot of points for a software release. I've been on HN consistently for a long while and I didn't realize there was so much love and hype for RethinkDB here. Have I missed something?
I guess you have. There are a lot of us into alternative databases that are hoping for Rethink to fulfill the original promise of MongoDB. That said, I can't blame you for not devoting a bunch of attention to it. :)
Can you be more specific on the original promise MongoDB didn't fulfill?
Re: RethinkDB 2.0 is now production ready
#85Earlier quoted context omitted.
Slava, CEO @ Rethink here. There are two aspects that you should consider. Firstly, as Daniel pointed out, RethinkDB is licensed under AGPL. An acquirer wouldn't have the legal means to close the source code, and with over 700 forks on GitHub they also couldn't do it practically. But beyond licensing, consider our personal motivations. We've been working on RethinkDB for five years, and had quite a few opportunities…
I hear you talk a lot about real-time — I guess that's a niche that you noticed. But let me add to that: being "distributed" without major pain is also big. There is a niche to be filled on the (loosely defined) "distributed" spectrum between, say, Redis and Cassandra, and so far you seem to be heading right for that place. I like that a lot and plan to use RethinkDB for a number of projects in the near future.
What about Couchbase? Specifically for the niche on the spectrum between Redis and Cassandra.
Re: RethinkDB 2.0 is now production ready
#86Earlier quoted context omitted.
Any work done in 2.0 for improving aggregation performance? The last time I tried with 1.16, I gave up my testing when even the simplest aggregation query (count + group by with what should be a sequential, streaming scan) took literally minutes with RethinkDB, compared to <1s with PostgreSQL. Rethink coredumped before I gave it enough RAM, after which it blew up to around 7GB, whereas Postgres uses virtually no RAM,…
We did a couple of scalability improvements in 2.0, but didn't optimize groups and counts specifically. Would you mind writing me an email with your query or opening an issue at https://github.com/rethinkdb/rethinkdb/issues (unless you have already?)? I'd like to look into it to see how we can best improve this. We're planning to implemented a faster count algorithm that might help with this ( https://github.com/reth…
What I was doing is so trivial, you don't really need this information. This was my reference SQL query:
select path, count(*) from posts group by path;
You can demonstrate RethinkDB's performance issue with any largeish dataset by trying to group on a single field.
The path column in this case has a cardinality of 94, and the whole dataset is about 1 million documents. Some rows are big, some not; each has metadata plus a JSON document. The Postgres table is around 3.1GB (1GB for the main table + a 2.1GB TOAST table). Postgres does a seqscan + hash aggregate in about 1500ms.
It's been months since I did this, and I've since deleted RethinkDB and my test dataset.
Re: RethinkDB 2.0 is now production ready
#87Earlier quoted context omitted.
No, the AGPL uses strong copyleft, so any future derivative work must be released under the same terms (and the same license or later versions if I'm not mistaken). The only possibility is to start a closed source clone that doesn't use any of the original code from zero. The cases in which the community forks a project licensed with a copyleft license (like LibreOffice) has to do with insatisfaction with the directi…
> No, the AGPL uses strong copyleft, so any future derivative work must be released under the same terms (and the same license or later versions if I'm not mistaken). The only possibility is to start a closed source clone that doesn't use any of the original code from zero. Slava @ RethinkDB here. This has one exception -- the copyright owner can choose to start releasing enhancements as closed source, and they would…
One caveat with this: if your project is open source and has accepted submissions from non-affiliated entities, you would either need to get them to assign the rights to that code to RethinkDB or remove them from the source if you were to relicense under something that would break the AGPL. This is where things like code releases come in.
This is also why many open source startups don't accept code submissions from outsiders until they've determined they're going down the path of a consulting-focused business model. It's just too risky.
Re: RethinkDB 2.0 is now production ready
#88For the rubyists out there check out http://nobrainer.io/
Is anyone using nobrainer in production?
We're currently using Mongoid (MongoDB ORM), and an Active Record like ORM for RethinkDB is the main thing holdings us back.
I don't have great insight into nobrainer, but last I checked it seemed like joins wheren't implemented (but on the roadmap).
Re: RethinkDB 2.0 is now production ready
#89Anyone has some numbers on performance? I tried RethinkDB 1.x and the performance wasn't quite there yet, specially bulk import and aggregations.
I contributed the benchmarks to Dan's gorethink driver. Dan is great to collaborate with so if you want to hack on Go and contribute to OSS, consider giving his project a look.
One way to improve writes is to batch them, an example is here.
https://github.com/dancannon/gorethink/blob/master/benchmark...
I believe rethinkdb docs state that 200 is the optimum batch size.
Another way is to enable the soft durability mode.
http://rethinkdb.com/api/javascript/insert/
"In soft durability mode RethinkDB will acknowledge the write immediately after receiving and caching it, but before the write has been committed to disk."
https://github.com/dancannon/gorethink/blob/master/benchmark...
Obviously your business requirements come into play. I prefer the Hard writes because my data is important to me but I do insert debug messages using soft writes in one application I have.
*Edit: Heh I forgot to mention, on my Macbook Pro I was getting 20k w/s while batching and using soft writes.
Individual writes for me are hovering around 10k w/s on the 8 cpu 24gb instance i have. But yeah, define your business reqs then write your own benchmarks and see if the need is met.
Many devs write benchmarks in order to be the fastest and not the correctest. Super lame.
Re: RethinkDB 2.0 is now production ready
#90Congrats Mike & Team!