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

Our take on RethinkDB vs. MongoDB

rethinkdb.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Our take on RethinkDB vs. MongoDB

#51

Post by taligent »

lucian1900 wrote: post #38
taligent wrote: post #32

Earlier quoted context omitted.

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.

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 documents to the point where I could make a single query with zero joins to fetch 20 entities worth of data.

Every database is optimal for different use cases.

Re: Our take on RethinkDB vs. MongoDB

#52

Post by coffeemug »

ukd1 wrote: post #45
coffeemug wrote: post #42

Earlier quoted context omitted.

We did some testing and it should be great, especially once https://github.com/rethinkdb/rethinkdb/issues/97 makes it in.

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.

Re: Our take on RethinkDB vs. MongoDB

#53

Post by coffeemug »

etanol wrote: post #47

«An asynchronous, event-driven architecture based on highly optimized coroutine code scales across multiple cores and processors, network cards, and storage systems.» It may be a dumb question, but isn't this statement a bit contradictory? As far as I understand, event-driven design and coroutines (i.e. cooperative multitasking, lighweight threads, etc.) are the techniques usually chosen to AVOID concurrency. How doe…

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 CPU core can process other pending tasks). The code isn't wait-free -- a coroutine might have to wait, but it never ever locks the CPU core itself. So, as long as there is more work to do, the CPU will always be able to do it.

If instead we used threads + locking like traditional systems, we'd have to deal with "hot locks" that block out entire cores. Effectively we solved this problem once and for all, while systems that use threads + locks (like the linux kernel) have to continuously solve it by making sure locks are extremely granular.

Re: Our take on RethinkDB vs. MongoDB

#54

Post by bunkat »

neumino wrote: post #50
bunkat wrote: post #48

Looks very interesting, but this statement in their FAQ is a red flag for me: How can I understand the performance of slow queries? Understanding query performance currently requires a pretty deep understanding of the system. For the moment, the easiest way to get an idea of why your query isn't performing well is to ask us. Wish RethinkDB was a little further along because it seems like it might be a good fit for a…

Michel @ RethinkDB We are building a tool to explain in a nice way how the query is executed, what are the bottlenecks etc. It should make it for 1.5. You can track progress here https://github.com/rethinkdb/rethinkdb/issues/175 (it's kind of empty for now)

Interesting, I'll keep an eye on that. When do you think RethinkDB will be ready for production use?

Re: Our take on RethinkDB vs. MongoDB

#55

Post by neumino »

bunkat wrote: post #54
neumino wrote: post #50

Earlier quoted context omitted.

Michel @ RethinkDB We are building a tool to explain in a nice way how the query is executed, what are the bottlenecks etc. It should make it for 1.5. You can track progress here https://github.com/rethinkdb/rethinkdb/issues/175 (it's kind of empty for now)

Interesting, I'll keep an eye on that. When do you think RethinkDB will be ready for production use?

We aim to be ready for production in 6 months.

Re: Our take on RethinkDB vs. MongoDB

#56

Post by shrughes »

etanol wrote: post #47

«An asynchronous, event-driven architecture based on highly optimized coroutine code scales across multiple cores and processors, network cards, and storage systems.» It may be a dumb question, but isn't this statement a bit contradictory? As far as I understand, event-driven design and coroutines (i.e. cooperative multitasking, lighweight threads, etc.) are the techniques usually chosen to AVOID concurrency. How doe…

You get less overhead by using less often the low-level concurrency primitives that involve cross-core synchronization. Cross-core synchronization happens in rethinkdb mainly when you see an on_thread_t object constructed or destroyed (and also in a few other places) and those get batched when you have more than one per event loop (which is not necessarily good, inflated queue sizes is also something to be wary of). So if you want to attach a bunch of network cards and high-speed storage devices on opposite ends of a handful of CPUs, your throughput won't be hindered by the fact that millions of threads are trying to talk to one another.

Re: Our take on RethinkDB vs. MongoDB

#57

Post by andrewljohnson »

jcdavis wrote: post #40

Not mentioned: RethinkDB doesn't yet support secondary and compound indexes, which is a dealbreaker for a lot of setups Definitely looks interesting though, and I look forward to playing around with it at some point.

Read the article:

"Some key features like secondary indexes and live backup are still in development"

Re: Our take on RethinkDB vs. MongoDB

#58

Post by JulianMorrison »

coffeemug wrote: post #53
etanol wrote: post #47

«An asynchronous, event-driven architecture based on highly optimized coroutine code scales across multiple cores and processors, network cards, and storage systems.» It may be a dumb question, but isn't this statement a bit contradictory? As far as I understand, event-driven design and coroutines (i.e. cooperative multitasking, lighweight threads, etc.) are the techniques usually chosen to AVOID concurrency. How doe…

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?

Re: Our take on RethinkDB vs. MongoDB

#60

Post by coffeemug »

andrewljohnson wrote: post #57
jcdavis wrote: post #40

Not mentioned: RethinkDB doesn't yet support secondary and compound indexes, which is a dealbreaker for a lot of setups Definitely looks interesting though, and I look forward to playing around with it at some point.

Read the article: "Some key features like secondary indexes and live backup are still in development"

Sorry, we added limitations a few hours after posting. I should have been more clear about the fact that they were edited in. I'll try to get better at this live blogging thing :)
Post reply on HN