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

141–150 of 156 posts

Re: RethinkDB 2.0 is now production ready

#141

Post by SamReidHughes »

lobster_johnson wrote: post #130
SamReidHughes wrote: post #125

Earlier quoted context omitted.

If you wrote your query with group and count, with no index, then there would be problems with the performance. RethinkDB generally does not do query optimization, except in specific ways (mostly about distributing where the query is run), unless that's changed very recently. You can write that query so that it executes with appropriate memory usage with a map and reduce operation.

Do you think map/reduce would result in performance near what I get from Postgres?

You would get the same behavior that Postgres's would be in terms of how data is traversed and aggregated -- that is, not by building a bunch of groups and counting them after the fact. I do think RethinkDB ought to be able to apply aggregations to group queries on the fly though... I'm not really up to date on that.

Postgres will still have better numbers, I'm sure. It has a schema for starters.

Re: RethinkDB 2.0 is now production ready

#142

Post by SamReidHughes »

rspeer wrote: post #137
lobster_johnson wrote: post #130

Earlier quoted context omitted.

Do you think map/reduce would result in performance near what I get from Postgres?

I haven't used RethinkDB, but I would assume the answer is no. Choosing to use map/reduce is basically a declaration that performance is your lowest priority.

An optimally optimized query by Postgres would be effectively mapping and reducing.

Re: RethinkDB 2.0 is now production ready

#143

Post by rspeer »

SamReidHughes wrote: post #142
rspeer wrote: post #137

Earlier quoted context omitted.

I haven't used RethinkDB, but I would assume the answer is no. Choosing to use map/reduce is basically a declaration that performance is your lowest priority.

An optimally optimized query by Postgres would be effectively mapping and reducing.

And the point is that the converse is definitely not true.

Postgres knows about the structure of your data and where it's located, and can do something reasonably optimal. A generic map/reduce algorithm will have to calculate the same thing as Postgres eventually, but it'll have tons of overhead.

(Also, what is with the fad for running map/reduce in the core of the database? Why would this be a good idea? It was a terrible, performance-killing idea on both Mongo and Riak. Is RethinkDB just participating in this fad to be buzzword-compliant?)

Re: RethinkDB 2.0 is now production ready

#144

Post by lobster_johnson »

SamReidHughes wrote: post #141
lobster_johnson wrote: post #130

Earlier quoted context omitted.

Do you think map/reduce would result in performance near what I get from Postgres?

You would get the same behavior that Postgres's would be in terms of how data is traversed and aggregated -- that is, not by building a bunch of groups and counting them after the fact. I do think RethinkDB ought to be able to apply aggregations to group queries on the fly though... I'm not really up to date on that. Postgres will still have better numbers, I'm sure. It has a schema for starters.

While I don't know RethinkDB is structured internally, I don't see any technical reason why a non-mapreduce group-by needs to load the entire table into memory instead of streaming it, or why a mapreduce group-by needs to be slow. M/R only becomes a slow algorithm once you involve shards and network traffic; any classical relational aggregation plan uses a kind of M/R anyway.

Postgres has a schema, of course, but it still needs to look up the column map (the ItemIdData) in each page as it scans it, the main difference being that this map is of fixed length, whereas in a schemaless page it would be variable-length.

Anyway, I'm hoping RethinkDB will get better at this. I sure like a lot about it.

Re: RethinkDB 2.0 is now production ready

#145

Post by SamReidHughes »

rspeer wrote: post #143
SamReidHughes wrote: post #142

Earlier quoted context omitted.

An optimally optimized query by Postgres would be effectively mapping and reducing.

And the point is that the converse is definitely not true. Postgres knows about the structure of your data and where it's located, and can do something reasonably optimal. A generic map/reduce algorithm will have to calculate the same thing as Postgres eventually, but it'll have tons of overhead. (Also, what is with the fad for running map/reduce in the core of the database ? Why would this be a good idea? It was a t…

There is no relevant knowledge that Postgres has that RethinkDB lacks that lets it evaluate the query more efficiently (besides maybe a row layout with fixed offsets so that it doesn't haven't parse documents, but that's not relevant to the reported problem). A generic map reduce certainly would have more overhead, obviously, but not running-out-of-memory overhead reported above, just the overhead of merging big documents.

The reason you run queries in "the core" of a database is because copying all the data outside the database and doing computations there would be far worse.

Re: RethinkDB 2.0 is now production ready

#146

Post by SamReidHughes »

lobster_johnson wrote: post #144
SamReidHughes wrote: post #141

Earlier quoted context omitted.

You would get the same behavior that Postgres's would be in terms of how data is traversed and aggregated -- that is, not by building a bunch of groups and counting them after the fact. I do think RethinkDB ought to be able to apply aggregations to group queries on the fly though... I'm not really up to date on that. Postgres will still have better numbers, I'm sure. It has a schema for starters.

While I don't know RethinkDB is structured internally, I don't see any technical reason why a non-mapreduce group-by needs to load the entire table into memory instead of streaming it, or why a mapreduce group-by needs to be slow. M/R only becomes a slow algorithm once you involve shards and network traffic; any classical relational aggregation plan uses a kind of M/R anyway. Postgres has a schema, of course, but it…

Generally speaking RethinkDB doesn't query optimize, except in deterministic ways, unless they've changed policy on this. I don't see any reason why a plain group/aggregate query couldn't be evaluated appropriately -- I know it is when the grouping is done using an index, maybe it is now when the grouping is done otherwise (I don't know, but it would be sensible, I'm out of date).

Re: RethinkDB 2.0 is now production ready

#147

Post by lobster_johnson »

rspeer wrote: post #143
SamReidHughes wrote: post #142

Earlier quoted context omitted.

An optimally optimized query by Postgres would be effectively mapping and reducing.

And the point is that the converse is definitely not true. Postgres knows about the structure of your data and where it's located, and can do something reasonably optimal. A generic map/reduce algorithm will have to calculate the same thing as Postgres eventually, but it'll have tons of overhead. (Also, what is with the fad for running map/reduce in the core of the database ? Why would this be a good idea? It was a t…

While there have been some truly misguided mapreduce implementations, mapreduce is just a computation model that isn't inherently slower than others: A relational aggregation of the type you get with SQL like:

  select foo, count(*) from bar group by foo
...is essentially a mapreduce, although most databases probably don't use a reduce buffer larger than 2. (But they would benefit from it if they could use hardware vectorization, I believe.)

Mapreduce works great if you are already sequentially churning through a large subset of a table, which is typically the case with aggregations such as "count" and "sum". Where mapreduce is foolish is when you try using mapreduce for real-time queries that only seek to extract a tiny subset of the dataset.

Re: RethinkDB 2.0 is now production ready

#148

Post by SamReidHughes »

SamReidHughes wrote: post #146
lobster_johnson wrote: post #144

Earlier quoted context omitted.

While I don't know RethinkDB is structured internally, I don't see any technical reason why a non-mapreduce group-by needs to load the entire table into memory instead of streaming it, or why a mapreduce group-by needs to be slow. M/R only becomes a slow algorithm once you involve shards and network traffic; any classical relational aggregation plan uses a kind of M/R anyway. Postgres has a schema, of course, but it…

Generally speaking RethinkDB doesn't query optimize, except in deterministic ways, unless they've changed policy on this. I don't see any reason why a plain group/aggregate query couldn't be evaluated appropriately -- I know it is when the grouping is done using an index, maybe it is now when the grouping is done otherwise (I don't know, but it would be sensible, I'm out of date).

(Also it would be nice if it did/does, because performance will still be terrible if you have too many groups, otherwise.)

Re: RethinkDB 2.0 is now production ready

#149

Post by danielmewes »

e12e wrote: post #134
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.

Rough numbers indeed - you forgot to define what a "server" is -- dedicated hw 16 core xeon with 4xssd in hw raid0 or a Digital Ocean vps with 512MB ram? ;-)

Daniel @ RethinkDB here. We'll release the details shortly. This was running on 12 core Xeon servers with 2 SSDs each in software RAID 0. There were also additional read queries running at the same time as the write queries, and the read throughput that coffeemug posted is the sustainable increase in reads/s that you get when adding an additional server to a cluster. Single-server performance is much higher due to missing network / message encoding overhead.

I realize these numbers alone are still not very meaningful and there are many remaining questions (size and structure of the data set, exact queries performed etc). Rest assured that all of these details will be mentioned in the actual performance report that should be up soon.

Re: RethinkDB 2.0 is now production ready

#150

Post by danielmewes »

lobster_johnson wrote: post #86
danielmewes wrote: post #78

Earlier quoted context omitted.

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; (I don't have the exact Rethink query written down, but it was analogous to the SQL version.) 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 t…

Thanks for the info. I'll look into this. The fact that we are running out of memory suggests that we're doing something wrong for this query.
Post reply on HN