Hacker News Reader

Comment by dwnoble | Hacker News Reader

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.

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.

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.

I wonder what sort of performance you would have gotten using MySQL or PostgreSQL, but denormalizing your data into JSON.

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.

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.

Toxic seems like a strong word to describe standard relational database functionality. Are you seriously recommending that join functionality always be done in the application layer? If so, are you speaking from specific experience, and can you elaborate on your reasoning?

I've seen too many poor re-implementations of relational database functionality in the application layer to ever recommend it as a standard starting point. Doesn't the concept of not prematurely optimizing apply here? Solve the scalability problem when you need to. That may mean moving some join functionality into the application layer, but the solution to any given scalability problem depends on the specifics of the problem. Just throwing out database joins as a rule seems drastic.

Database level joins are toxic for scalability

Tell that to Teradata.

Reply on news.ycombinator.com