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

21–30 of 85 posts

Re: Our take on RethinkDB vs. MongoDB

#21

Post by coffeemug »

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…

Actually, 'brew install rethinkdb' is now available. I'll update the install page with it in a moment.

EDIT: https://github.com/rethinkdb/rethinkdb/issues/269

Re: Our take on RethinkDB vs. MongoDB

#23

Post by optimiz3 »

My company uses MongoDB. Our biggest pain points are:

1. MongoDB has massive storage overhead per field due to the BSON format. Even if you use single character field names, you're still looking at space wasted on null terminators. 32bit fixed length int32s also bloat your storage use. We solve this by serializing our objects as binary blobs into the DB, and only using extra fields when we need an index.

2. In Mongo, the entire DB eventually gets paged into memory and relies on the OS paging system which murders performance. For a humongous DB, not so much.

3. #1 and #2 force #3, which is sharding. MongoDB requires deploying a "config cluster" - 3 additional instances to manage sharding (annoying that the nodes themselves cannot manage this, and expensive from an ops/cost standpoint).

What I would like to know is:

1. What is the storage overhead per field of a document in RethinkDB? If it's greater than 1 byte, I'm wary.

2. Where is the .Net driver?

Re: Our take on RethinkDB vs. MongoDB

#24

Post by coffeemug »

wiremine wrote: post #19
coffeemug wrote: post #4

Earlier quoted context omitted.

Hi, slava @ rethink here. People have been using Rethink for lots of projects, but there are still some showstoppers we have to work out (better docs notwithstanding) -- remember, the product has been in the wild for less than 90 days. What did you try to do with a many-to-many join? We could help you with writing the query, and could add syntax sugar to the language to make it easier if it makes sense.

> "remember, the product has been in the wild for less than 90 days." I hear you, and, FWIW, I'm excited about Rethink. To rephrase my question/observation: your article clearly lays out why you think it is better than MongoDB, using some quotes from people who agree with you. However, without some real-world data, it is still an argument rooted in theory. I like theory, but I also like to take real-world data to my…

I also hear you, there will be real data soon. We just want to be careful about making sure everything is sound before publishing information.

As for many-to-many joins, I'll write something up about it, thanks!!

Re: Our take on RethinkDB vs. MongoDB

#25

Post by coffeemug »

optimiz3 wrote: post #23

My company uses MongoDB. Our biggest pain points are: 1. MongoDB has massive storage overhead per field due to the BSON format. Even if you use single character field names, you're still looking at space wasted on null terminators. 32bit fixed length int32s also bloat your storage use. We solve this by serializing our objects as binary blobs into the DB, and only using extra fields when we need an index. 2. In Mongo,…

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 be seeing many more drivers soon.

Re: Our take on RethinkDB vs. MongoDB

#27

Post by rubyrescue »

Riak 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" in that it SEEMS like an operational savings because it was designed by developers.

Re: Our take on RethinkDB vs. MongoDB

#28

Post by desireco42 »

coffeemug wrote: post #21
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…

Actually, 'brew install rethinkdb' is now available. I'll update the install page with it in a moment. EDIT: https://github.com/rethinkdb/rethinkdb/issues/269

Thank you :), again it is not really serious gripe as regular installer does the job just fine, but I tend to install all apps like that and this helps.

+1 for sure for this one

btw, when I was installing it, I tried that even before checking on homepage :)

Re: Our take on RethinkDB vs. MongoDB

#29

Post by optimiz3 »

coffeemug wrote: post #25
optimiz3 wrote: post #23

My company uses MongoDB. Our biggest pain points are: 1. MongoDB has massive storage overhead per field due to the BSON format. Even if you use single character field names, you're still looking at space wasted on null terminators. 32bit fixed length int32s also bloat your storage use. We solve this by serializing our objects as binary blobs into the DB, and only using extra fields when we need an index. 2. In Mongo,…

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.

Re: Our take on RethinkDB vs. MongoDB

#30

Post by coffeemug »

rubyrescue wrote: post #27

Riak 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"…

That's an interesting take -- I think the Basho team positions Riak as an operations-oriented system (at least that's how I always thought about it, though I haven't used Riak in production).
Post reply on HN