Ok, my point is that you're wrong. I guess I'll leave it at that.

Edit: Or not quite...

Sure sounds like a raison d'etre to me...

http://www.kchodorow.com/blog/2010/0...ry-of-mongodb/

Sure, mongo's still web scale.

I'm curious as to if there's a real answer to this:

http://www.quora.com/MongoDB/How-muc...B-have?share=1

The thing is that I want MongoDB be good - I wrote a pretty substantial piece of software using it (a CRUD app builder, it's like Web Access) and I know it's easier to use, especially from Scala, than Postgres + JSON for most of what I'm doing in this new project. But nothing I'm reading gives me confidence that it's the best technical choice and every MongoDB user/advocate seems to have the same attitude that jjshabado and the mongo drone from the webscale video have. Short on technical details and long on unncessary snark and mongodb web-scale, lol relational non-arguments.

You seem upset. Do you work for Mongo or something? I was enjoying the discussion but then you kinda got butt hurt and stopped caring

It would be more credible if MongoDB is the product of their experience in scaling out with the app engine, but all this is saying is that MongoDB is derived from a database prototype that was originally designed to be part of a scalable application stack, but failed to reach any kind of scale whatsoever. And part of this initial "scalable" design apparently was unsafe writes by default so it's hard to give them benefit of the doubt. Since they had no pressing production needs, my guess is that the design is optimized for speed of feature development. Using mmap for storage, v8 for query engine, no worries about consistency, etc - mongodb is as close to a nothing product as you get, at least on the storage side of the equation: http://nyeggen.com/blog/2013/10/18/t...ly-of-mongodb/

While going back and forth between Oracle and Mongo is fun you're missing the most important point. Even if Oracle was free or really cheap it would still suck. I know quite a few people that had to work with it and the count of people that enjoyed it or would pick it if they had a say in the matter is still at 0 (and they are not paying for it just implementing stuff to run with it or use it or whatever).

I'm not upset, I just don't care to go back and forth over something as silly as this. I mean, what were we discussing that was interesting? If you have specific questions or comments I'll gladly address them.

And that's not a shot at candybar at all - I was just as guilty - but once I realize that a discussion isn't going anywhere I've been trying to get better at ending it.

I think Mongo has a lot of problems and I've mentioned a bunch of those in this thread.

What technical details do you want? I mean your most technical point was that MongoDB use to have a global write lock and still has a database level write lock and so something something its not meant for horizontal scaling.

I talked earlier about unsafe writes and how we treat them as either we don't care about losing a tiny percent of data or we use safe writes/other redundancy methods to protect ourselves.

And we weren't even debating NoSQL vs relational databases, so I'm not sure what your point is there. If we were, my answer would be the same as before where they both have their uses. Go back and read what you wrote, you're the one that kept framing the argument in weird ways "cassandra vs mongo" or some imaginary world with just Oracle and Mongo.

And failing.

This has more to do with the fact that anyone working with an Oracle database is also likely to be maintaining some old, creaky legacy software that's too profitable to kill but doesn't have a bright enough prospect to rewrite, while also dealing with a cranky DBA who's mostly checked out, rarely helpful, and uses the full power of Oracle's configurability to create traps that justify their salary and establish superiority over mere mortal developers that keep falling in them.

Oracle is a horrible, horrible company but I have a lot of respect for their technology.

But it has all these features and reliability or something!

But seriously, I agree.

What makes MongoDB scale well? And Postgres not so well? I've referenced a whole bunch of articles that talk about MongoDB's issues with reliability, issues with sharding, issues with high loads and issues providing high availability - not much of a point in me rephrasing them, is there?

First, I should point out that I feel like you've been arguing with a strawman version of me without actually reading what I wrote.

So here I state that I don't know the latest on Postgres scaling. Nor do I care that much. Feel free to explain to me why Postgres scaling is better.

My experience with Oracle doing horizontal scaling was a nightmare. In fact the project ended up failing and the company wasted a good amount of money on trying it before going with a beefier machine and settling for a much delayed read-only replica of the master.

Why is Mongo good at scaling? How about the basics?

* http://docs.mongodb.org/manual/sharding/
* http://docs.mongodb.org/manual/replication/
** Note you can read from your replicas and run long running queries against them instead of against the primary node.
* Migrating/Modifying document collections is easy, releases are easy and faster

Or feel free to talk to any of the numerous large companies using Mongo why they like it.

As for the other issues, many of them are issues that should be known when you choose to use Mongo (and/or have already been addressed). For example I don't really have sympathy for people that fell prey to the unsafe write problem. Yes its a stupid default, but its documented and known about. Same with the global locks. If you chose Mongo to scale even though you knew you were doing a ton of writes and reads on the collection at the same time, that was silly and a poor tool choice.

Edit: Not to mention, I should point out again that Horizontal scalability is far from the main reason we chose it. But there's still a far cry from what Mongo offers and the position you were advocating about how Mongo isn't built for scaling at all.

And since I'm already going to waste the next hour or so before I take off for the night I might as well answer this (I already did before deleting it, but here we go again).

The main joke is about fan-boy-ism vs. picking the right tool for the job. It then makes fun of Mongo not because it can't scale really well but because of the way it scales really well and how people just skip over those details when they're in fan-boy mode.

If you're ok with the tradeoffs Mongo makes, its a good tool.

And, I'd say that the most fan-boy-ism in this thread has come from you about Postgres and in a weird way Oracle (with your implications that its significantly better than all other non-Postgres competition). I have no problem pointing out Mongo's flaws (like pointing out to Dave how MR on Mongo is next to useless).

WTF is this.

http://www.dbms2.com/2011/07/27/mong...and-use-cases/ (Notice the date)

Why don't you post some content now? Tell me how Postgres is significantly better.

My experience with Oracle was horrible. I don't imagine Postgres has significantly better scaling, but I admitted that I could be wrong.

And yet in all of your bitching and moaning about this you haven't actually told me how I'm wrong. Where are the large horizontally scaled Postgres databases?

Oracle/Weblogic costs our company $27 million/year in licensing. I don't think support is even included in that. Every time we try to wean off one of their products they just shift the licensing around so we still pay the same.

Any new company would be insane to go down that road.

This: http://instagram-engineering.tumblr....s-at-instagram

doesn't make Postgres horizontal scaling seem particularly easy. Seems to involve a lot of custom code and functionality.

http://highscalability.com/skype-pla...-billion-users

Seems similar. You need to add a bunch of custom logic/tools to make it work well.

But features! Reliability!

This is from 2008:

http://highscalability.com/skype-pla...-billion-users

And how it works is really not that different from MySQL or SQL Server or Oracle or whatever. What's slightly complicating is that some limitations start appearing when your data is not all on the same instance, which means your application may have to change at that point but most of those limitations are problems that MongoDB doesn't solve to start with (cross-table joins, consistency issues, transactions, etc). Fundamentally speaking, scaling RDBMS is mostly a solved problem. Simplify schema, partition tables, replicate for failover, provision ahead of time. There are some rough edges and unsolvable problems (CAP theorem) but mostly where databases differ are when things screw up and how you recover from failures.

Again, I agree with you that MongoDB makes things easier. But tons and tons of people have run Oracle at ridiculous scale so it's hard to imagine that Oracle's at fault technically.

Candybar, I already linked that. And the point being they're not doing that with Postgres. They're doing that with Postgres + a bunch of custom application code + some extra tools.

And, of course, once you put that time and effort and money into building a custom solution - its almost always going to be better than a general solution. But its way more work. Which gets back to the exact thing that seemed to set you off:

I'd rather horizontally scale Mongo or Cassandra over a traditional RDMS.

Your application doesn't have code? Isn't the whole point of NoSQL moving what used be parts of RDBMS into application code? At scale, everyone writes custom code - if you're not, you're probably not at scale.

Then what are you going on about and why were you confused about what I wrote?

Edit: And I completely disagree with the idea that Oracle has been run by tons and tons of people at ridiculous scale. This statement would be true 10 years ago but "ridiculous scale" has changed significantly and the people at the cutting edge aint using Oracle.

I think what turns me off about this discussion is that you seem purposefully obtuse.

Needing code 'for logical partitioning'. For example with Mongo the database handles routing your query to the correct shard. With Postgres you need to do that before querying.