Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RethinkDB 2.0 is now production ready

rethinkdb.com

Post reply on HN
Print view View original

71–80 of 156 posts

Re: RethinkDB 2.0 is now production ready

#71

Post by javajosh »

coffeemug wrote: post #29
mping wrote: post #25

Anyone has some numbers on performance? I tried RethinkDB 1.x and the performance wasn't quite there yet, specially bulk import and aggregations.

We'll be publishing a performance report soon (we didn't manage to get it out today). Rough numbers you can expect for 1KB size documents, 25M document database: 40K reads/sec/server, 5K writes/sec/server, roughly linear scalability across nodes. We should be able to get the report out in a couple of days.

Thank you for providing some quick back-of-the-envelope numbers here, which is exactly what most people are looking for at a first pass. One question though - do those numbers change considerably between disk vs SSD?

Re: RethinkDB 2.0 is now production ready

#72

Post by giaour »

ThinkBeat wrote: post #64
expando wrote: post #7

Selling support is a great non-intrusive business model.

Except that it incentivises a company to build a product that requires continuing support. That can be a good thing or a bad thing.

Selling support for terrible (but free!) software is usually known as the "MongoDB model," so it's a proven path to riches in the database market.

Re: RethinkDB 2.0 is now production ready

#76

Post by coffeemug »

javajosh wrote: post #71
coffeemug wrote: post #29

Earlier quoted context omitted.

We'll be publishing a performance report soon (we didn't manage to get it out today). Rough numbers you can expect for 1KB size documents, 25M document database: 40K reads/sec/server, 5K writes/sec/server, roughly linear scalability across nodes. We should be able to get the report out in a couple of days.

Thank you for providing some quick back-of-the-envelope numbers here, which is exactly what most people are looking for at a first pass. One question though - do those numbers change considerably between disk vs SSD?

The numbers were measured on SSD. If the active/hot dataset fits into RAM, the numbers between SSD and rotational don't change much. If the active dataset doesn't fit into RAM, RethinkDB performs significantly worse on rotational.

Re: RethinkDB 2.0 is now production ready

#78

Post by danielmewes »

lobster_johnson wrote: post #51
coffeemug wrote: post #29

Earlier quoted context omitted.

We'll be publishing a performance report soon (we didn't manage to get it out today). Rough numbers you can expect for 1KB size documents, 25M document database: 40K reads/sec/server, 5K writes/sec/server, roughly linear scalability across nodes. We should be able to get the report out in a couple of days.

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/rethinkdb/rethinkdb/issues/3949), but it's not completely trivial and will take us slightly longer to implement.

Re: RethinkDB 2.0 is now production ready

#79

Post by coffeemug »

ThinkBeat wrote: post #64
expando wrote: post #7

Selling support is a great non-intrusive business model.

Except that it incentivises a company to build a product that requires continuing support. That can be a good thing or a bad thing.

> Except that it incentivises a company to build a product that requires continuing support.

People say this a lot, but in our case we really haven't seen this incentive for a couple of reasons.

Large organizations are more than happy to pay for training and development support to accelerate their time to market. It doesn't matter how polished your product is -- databases are complex enough that people are willing to pay for best practices, training, and support.

Similarly, databases are pretty critical pieces of the infrastructure. If anything goes wrong, it can significantly impact the business, so people always want operational/production support.

There are many enterprise services that can be built on top of the product that can be very valuable. You don't have to build a crappy product -- there are plenty of ways to monetize with a great product.

Finally, a bad product will significantly limit growth of the company in the long term. There are lots of options now -- you can't get away with building a crappy product and an artificial monopoly.

If you see a crappy product from a company that offers subscription support, it's probably not because of misaligned incentives. Building databases is really hard, I don't think the business model has much to do with it.

Post reply on HN