This comparison speaks better than this - http://www.rethinkdb.com/docs/comparisons/mongodb/
Our take on RethinkDB vs. MongoDB
61–70 of 85 posts
Re: Our take on RethinkDB vs. MongoDB
#62Earlier quoted context omitted.
This is a great question. We start a thread per core, and multiplex thousands of coroutines/events on each thread. When coroutines on different threads need to communicate, we send a message via a highly optimized message bus, so cross-thread communication code is localized. This means each thread is lock-free (i.e. when a coroutine needs to communicate with another coroutine, it sends a message and yields, so the CP…
Sounds very Erlang-ish. Did you copy that deliberately?
We do effectively have an ad-hoc mini Erlang runtime that we wrote at the core of the system. I'm not sure how deliberate that was -- we sort of borrowed performance ideas from many places, tried a lot of different approaches, and settled on this one. Lots of this was definitely inspired by ideas from Erlang.
Re: Our take on RethinkDB vs. MongoDB
#63Riak is NOT operations-oriented. It's nearly impossible to manage operationally without dedicated staff at scale and the tools to introspect and analyze and deal with failures aren't robust enough yet. I know they're just trying to contrast Riak and Cassandra with Couch and Mongo, and that Riak is designed to shard easily without the developer having to think about it. That philosophy actually is "developer-oriented"…
Can you provide an example of where Riak was "nearly impossible to manage operationally without dedicated staff at scale and the tools to introspect and analyze and deal with failures aren't robust enough yet"?
Re: Our take on RethinkDB vs. MongoDB
#64Earlier quoted context omitted.
MongoDB has been durable for a while with journalling. They're only just enabled safe mode (i.e. synchronous) for the clients by default, but this is something different to being durable. If you want a durable write; you should not disable journalling and use safe mode / getlasterror with the desired writeconcern setting - http://docs.mongodb.org/manual/reference/command/getLastErro...
> If you want a durable write; you should not disable journalling and use safe mode / getlasterror with the desired writeconcern setting Sure. Which is the default approach of almost all of the drivers.
Not quite true; historically most (i.e. official) defaulted to safe=false.
Also safe=true only makes sure the server acknowledged your write; writeconcern allows you to wait for it to be written to the journal or more.
Also, journalling is not controllable via client drivers, only via startup flags / config options.
Re: Our take on RethinkDB vs. MongoDB
#65Earlier quoted context omitted.
When I last tested I maxed out at about 700 inserts / sec with nothing else happening (MBP Retina, SSD, etc) - it's not bad, but not as fast as Mongo. I'm going to benchmark it when I get some time!
This is a known limitation -- it will be resolved when we fix https://github.com/rethinkdb/rethinkdb/issues/207 . We just picked the safest default (fsync per op) and shipped the product. #207 will make things a little smarter.
700 inserts / sec is still quite a lot for a single laptop and I'm sure it will get better over time.
:-)
Re: Our take on RethinkDB vs. MongoDB
#66Earlier quoted context omitted.
Sounds very Erlang-ish. Did you copy that deliberately?
We do effectively have an ad-hoc mini Erlang runtime that we wrote at the core of the system. I'm not sure how deliberate that was -- we sort of borrowed performance ideas from many places, tried a lot of different approaches, and settled on this one. Lots of this was definitely inspired by ideas from Erlang.
There definitely seems to be a version of Greenspun's Tenth Rule for Erlang. But I think Greenspunning has gotten too bad a name – sometimes implementing a subset of a classical system is exactly what you ought to do, for example when your problem allows you to exploit certain invariants that don't hold in the general case, or for some reason using the classical system itself (Erlang in this case) is not an option.
Re: Our take on RethinkDB vs. MongoDB
#67Earlier quoted context omitted.
We do effectively have an ad-hoc mini Erlang runtime that we wrote at the core of the system. I'm not sure how deliberate that was -- we sort of borrowed performance ideas from many places, tried a lot of different approaches, and settled on this one. Lots of this was definitely inspired by ideas from Erlang.
There definitely seems to be a version of Greenspun's Tenth Rule for Erlang. But I think Greenspunning has gotten too bad a name – sometimes implementing a subset of a classical system is exactly what you ought to do, for example when your problem allows you to exploit certain invariants that don't hold in the general case, or for some reason using the classical system itself (Erlang in this case) is not an option.
Right! Rethink has an adhoc Erlang runtime for message processing, and an adhoc lisp for the query language. I'm both ashamed and proud of this at the same time :)
Re: Our take on RethinkDB vs. MongoDB
#68Riak is NOT operations-oriented. It's nearly impossible to manage operationally without dedicated staff at scale and the tools to introspect and analyze and deal with failures aren't robust enough yet. I know they're just trying to contrast Riak and Cassandra with Couch and Mongo, and that Riak is designed to shard easily without the developer having to think about it. That philosophy actually is "developer-oriented"…
Chief Architect at Basho here:
Saying Riak is categorically non-operations-oriented is a bit hyperbolic, but I will be the first to acknowledge that we need even more visibility into failure-recovery / degraded mode situations. I've spoken to a few customers who have "cheat sheets" of Erlang console commands they use to debug things like handoff slowness or poor performance in general. This alone means we need to do better,
On the other hand, Riak continues to function in scenarios where other databases would be completely unavailable. I'll take immature visibility during those situations over complete unavailability any day,
I appreciate your feedback - I can assure you that this is something we're constantly working on and you'll see improvements with each release.
Finally, if you've been bitten by anything specific you'd like to see fixed, we do all our development in the open at http://github.com/basho, so github issues, pull requests, etc go right into our internal tools and workflows.
Cheers,
Andy Gross
Re: Our take on RethinkDB vs. MongoDB
#69Earlier quoted context omitted.
Rethink has durability, MVCC, joins, logical sharding, excellent admin tools, etc. All things that serious databases tend to have and Mongo doesn't.
MongoDB IS durable now by default, has a third party MVCC implementation (MongoMVCC) and has pretty decent admin tools. And this idea that joins is a requirement for a "serious" database makes absolutely no sense. Database level joins are toxic for scalability and IMHO should always be done in the application layer.
Database level joins are toxic for scalability and IMHO should always be done in the application layer.
Not having database level joins is toxic for scalability for so many reasons.
MongoDB reminds me of MySQL : The Early Years. When every ignorant design decision and missing functionality was somehow actually a benefit. Then it gained them and most nervously smiled and moved on.
Re: Our take on RethinkDB vs. MongoDB
#70Earlier quoted context omitted.
Mongo in its most durable mode (which btw isn't what, say, Postres would call durable) is really slow. Why even bother with it anymore? First party MVCC is the only one that matters. It affects vital things like backups, analytical queries and transactions. Joins are extremely useful. If a database does the sharding, it is almost always better for it to do the joins as well. Performance can be good with the right mod…
So we are in agreeance then. MongoDB IS durable but it will be slower doing so. Hardly a surprise there. And still have to disagree about the joins but hey agree to disagree. As for MongoDB performance well making a blanket statement is pretty silly. On a previous project I had queries that were upwards of 40x faster in MongoDB than MySQL. Why ? Because MongoDB allows the ability to embed documents within other docum…
I wonder what sort of performance you would have gotten using MySQL or PostgreSQL, but denormalizing your data into JSON.