31–40 of 58 posts
> I expect to be able to click on a table and see the rows inside - like all the tools out there for Mongo, MySQL, PostgreSQL, etc. He does have a point there. It is slightly annoying having to type out a query when I just want to browse the data. (No real biggie though..)
Well, the author cares enough about RethinkDB to test it, even if he's a mongodb fan, even if his first benchmark was wrong, he was right to publish it: you all helped him when you pinpointed the problems in his tests... Thanks you for that. I don't see any marketing here, just the "do your own benchmark" best practice, and the "share with community" best practice... Does it make it a perfect benchmark? No, but at le…
> the author has corrected the discrepancies since then As of the time I posted this comment, the blog post still seems to be comparing indexed MongoDB operations against non-indexed RethinkDB operations. Under those conditions I'd expect RethinkDB to be at least 1000x slower than MongoDB. The fact that he's finding that RethinkDB is only 3x slower than MongoDB makes me think that there are still other major problems…
I would say that you probably should look at your API because I've never used a database that required me to explicitly define which indexes I want to use for a read. But I've never used RethinkDB so maybe there is a legitimate reason.
Well, the author cares enough about RethinkDB to test it, even if he's a mongodb fan, even if his first benchmark was wrong, he was right to publish it: you all helped him when you pinpointed the problems in his tests... Thanks you for that. I don't see any marketing here, just the "do your own benchmark" best practice, and the "share with community" best practice... Does it make it a perfect benchmark? No, but at le…
> the author has corrected the discrepancies since then As of the time I posted this comment, the blog post still seems to be comparing indexed MongoDB operations against non-indexed RethinkDB operations. Under those conditions I'd expect RethinkDB to be at least 1000x slower than MongoDB. The fact that he's finding that RethinkDB is only 3x slower than MongoDB makes me think that there are still other major problems…
> [...] I've never used a database that required me to explicitly define which indexes I want to use for a read. [...]
In a way, it's traditional (IBM IMS/DB, 1960s).
Well, the author cares enough about RethinkDB to test it, even if he's a mongodb fan, even if his first benchmark was wrong, he was right to publish it: you all helped him when you pinpointed the problems in his tests... Thanks you for that. I don't see any marketing here, just the "do your own benchmark" best practice, and the "share with community" best practice... Does it make it a perfect benchmark? No, but at le…
> the author has corrected the discrepancies since then As of the time I posted this comment, the blog post still seems to be comparing indexed MongoDB operations against non-indexed RethinkDB operations. Under those conditions I'd expect RethinkDB to be at least 1000x slower than MongoDB. The fact that he's finding that RethinkDB is only 3x slower than MongoDB makes me think that there are still other major problems…
- I don't see any mongodb index creation, so mongodb is inserting with no index while rethinkdb is inserting with the index. That's probably why there's a gap between the two
- there's no mongodb index, and rethinkdb queries do not make use of the index (this is probably why rethinkdb is not 1000x slower: both aren't using indexes)
- the $in query should be last_update: random_timestamp(), there's no need for $in here
- his insertion code creates 100K memory clones of the object to insert in the mongodb version only, not in rethinkdb
I'm sad to add: what the author is benchmarking here is the likely performance of a system he could build with either db. It's not necessarily bad (save for bad press) that he's bad at benchmarking: the mistakes he's made in his benchmark are similar to the mistakes he'll make in his code.
But yes, the author may use some help!
Well, the author cares enough about RethinkDB to test it, even if he's a mongodb fan, even if his first benchmark was wrong, he was right to publish it: you all helped him when you pinpointed the problems in his tests... Thanks you for that. I don't see any marketing here, just the "do your own benchmark" best practice, and the "share with community" best practice... Does it make it a perfect benchmark? No, but at le…
> the author has corrected the discrepancies since then As of the time I posted this comment, the blog post still seems to be comparing indexed MongoDB operations against non-indexed RethinkDB operations. Under those conditions I'd expect RethinkDB to be at least 1000x slower than MongoDB. The fact that he's finding that RethinkDB is only 3x slower than MongoDB makes me think that there are still other major problems…
Well, the author cares enough about RethinkDB to test it, even if he's a mongodb fan, even if his first benchmark was wrong, he was right to publish it: you all helped him when you pinpointed the problems in his tests... Thanks you for that. I don't see any marketing here, just the "do your own benchmark" best practice, and the "share with community" best practice... Does it make it a perfect benchmark? No, but at le…
> the author has corrected the discrepancies since then As of the time I posted this comment, the blog post still seems to be comparing indexed MongoDB operations against non-indexed RethinkDB operations. Under those conditions I'd expect RethinkDB to be at least 1000x slower than MongoDB. The fact that he's finding that RethinkDB is only 3x slower than MongoDB makes me think that there are still other major problems…
It's madness to expect someone new to database benchmarking to implement a correct fully featured benchmark client. They are going to stumble enough on database and instance configuration as it is.
It seems unfair and restrictive, but benchmarking is hard, and even where users get everything else right every data load is different.
It's easy to see why companies don't want writeups like this one dominating searches for " performance".
> I expect to be able to click on a table and see the rows inside - like all the tools out there for Mongo, MySQL, PostgreSQL, etc. He does have a point there. It is slightly annoying having to type out a query when I just want to browse the data. (No real biggie though..)
It's not a good point, though. Writing a rudimentary tool of that type would take perhaps an hour.
It does affect the initial experience though. The admin panel looks so slick I just assumed I would be able to click on the table and it would jump to the data. When it didn't I was surprised and initially blamed myself and fired up the console to see if there were any errors showing. It just affects the polish of the panel.
As I said though it is a minor point for an excellent product.
Earlier quoted context omitted.
Maybe you didn't get the joke. The joke is not about MongoDB, but about MongoDB fanbois that care only about some very narrow definition of "performance". The wider message is that DBs are way more complex beasts that is meaningful to test this way. Obviously there are cases in which MongoDB is a great choice, but equally obviously tests like this should not be a reason for the choice.
I do understand that second degree, but I don't think the author is a fanboy... At work, we're also Mongodb users. If tomorrow we try to benchmark against Cassandra, performance will probably be the selling point. I don't think it's absurd to compare mongodb and rethinkdb, they're very similar dbs. As for the benchmark, I agree it doesn't explore every facet of both databases and focus on performance... That's what b…
The title of the post is "RethinkDB reviewed by a MongoDB fan"
> I expect to be able to click on a table and see the rows inside - like all the tools out there for Mongo, MySQL, PostgreSQL, etc. He does have a point there. It is slightly annoying having to type out a query when I just want to browse the data. (No real biggie though..)