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

31–40 of 85 posts

Re: Our take on RethinkDB vs. MongoDB

#31

Post by desireco42 »

desireco42 wrote: post #14

I started using RethinkDB in one of my projects and am looking for excuses to use it in more of them. So far things have been great and honestly my impression is that RethinkDB doesn't get nearly the hype it deserves. I used Mongo before and it is fine db and I don't think I would be sad to use it, however rethink really does so many things better. Again I just started using it and things are really good, I didn't ra…

I would like to add (not to edit original post one more time), that in one of those things I like is query language. I remember how it felt weird initially doing simple things in Mongo, language is very simple and queries make sense and are easy to read.

Re: Our take on RethinkDB vs. MongoDB

#32

Post by taligent »

lucian1900 wrote: post #15
dwnoble wrote: post #7

Earlier quoted context omitted.

Can you expand a little bit on this? What design decisions in MongoDB vs RethinkDB are you referring to?

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.

Re: Our take on RethinkDB vs. MongoDB

#33

Post by bcbrown »

coffeemug wrote: post #22
bfirsh wrote: post #18

This just reads like marketing speak. What are the disadvantages of RethinkDB?

http://www.rethinkdb.com/docs/faq/#when-is-rethinkdb-not-a-g... http://www.rethinkdb.com/docs/advanced-faq/#is-rethinkdb-imm...

You mention comparing against Hadoop for computationally-intensive data analysis. Would Rethink be suitable for a several-terabyte dataset with non-computationally-intensive analytics?

Currently we're using Hive and Python over streaming Hadoop. There's no significant ongoing data accumulation; we're just analyzing the data we have.

Re: Our take on RethinkDB vs. MongoDB

#34

Post by munimkazia »

We have been looking at NewSQL(or even NoSQL) platforms for our databases at my place of work, and we also stumbled upon RethinkDB. While everything these guys say does sound amazing, we were looking for someone who has implemented it, or any third party case study about it. Since we couldn't find any, we decided not to go with RethinkDB for now.

Does anyone here know any big website/service which uses RethinkDB?

Re: Our take on RethinkDB vs. MongoDB

#35

Post by apendleton »

munimkazia wrote: post #34

We have been looking at NewSQL(or even NoSQL) platforms for our databases at my place of work, and we also stumbled upon RethinkDB. While everything these guys say does sound amazing, we were looking for someone who has implemented it, or any third party case study about it. Since we couldn't find any, we decided not to go with RethinkDB for now. Does anyone here know any big website/service which uses RethinkDB?

It's brand-new, and not recommended for production use yet, so I highly doubt that anything like that exists.

Re: Our take on RethinkDB vs. MongoDB

#36

Post by coffeemug »

optimiz3 wrote: post #29
coffeemug wrote: post #25

Earlier quoted context omitted.

1. In the coming release we'll be storing documents on disk via protocol buffers, which, unlike BSON has an extremely low overhead on fields. A few releases after that we'll be able to do much better via compression of attribute name information (though this feature isn't specced yet). 2. No ETA yet, but we're about to publish an updated, better document, better architected client-driver to server API spec, so we'll…

If you use proto-bufs, it means you already have a system for internal auto-schematization. Why not pack all the fields together and use a bit-vector header to signify which fields are present and which fields have default values? I'd LOVE to see a document DB with ~1 bit overhead per field.

Yes, that's pretty much what we're going to do. It's a bit hard to guarantee everything in a fully concurrent, sharded environment so it'll take a bit of time, but that's basically the plan.

Re: Our take on RethinkDB vs. MongoDB

#37

Post by mhd »

How's the general performance and memory consumption on smaller machines, e.g. entry-level VPS's or the lower spectrum of AWS VMs? Don't have any big projects in the pipeline that immediately required sharding etc, but would like to play with it on a few weekend-scale items.

Re: Our take on RethinkDB vs. MongoDB

#38

Post by lucian1900 »

taligent wrote: post #32
lucian1900 wrote: post #15

Earlier 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.

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 model, and Mongo is slow anyway.

Re: Our take on RethinkDB vs. MongoDB

#40

Post by jcdavis »

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.

Post reply on HN