Comment by threeseed | Hacker News Reader

Comment by threeseed | Hacker News Reader

You would think someone who claims to be an expert on databases would have a clue about his industry.

MongoDB is a document database and is as different from almost every other NoSQL database as it is from every SQL database. It very much stands alone and requires your domain model to be structured in a particular way. To say that it "represents" NoSQL is ridiculous. And to act like a guide on how to scale MongoDB to store 100GB is a problem is also ridiculous. I can create domain models that almost every SQL database would struggle with that MongoDB could breeze through and vice versa.

And seriously anyone claims Cassandra or Riak are misspent adventures are simply delusional. They are solving real world problems in particular around horizontal scaling today that could never be done as cheaply or easily as before. A master-master cluster that costs nothing, scales linearly and can be managed by a developer. Would love to know what product existed years ago that could do that.

Likewise I take exception with the criticism of MySQL. It is an easy to use, manage and install and has the best tooling bar none. It does what it is intended to do perfectly. Some people who deal exclusively with ORM layers will never see the imperfections and just see the ease of use.

> I can create domain models that almost every SQL database would struggle with that MongoDB could breeze through and vice versa.

I am always interested in learning about models that SQL/"traditional relation model" can't easily (or less easily) represent or query. Last time I asked someone pointed me to Datomic's EAVT (entity-attribute-value-time) model as a good example.

Do you know of any more than EAVT?

One classic example is tree/graph structured data.

I've worked extensively with modeling and querying medical concepts and relationships in RDBMS. I realize there are tools like recursive common table expressions an materialized paths that can aide querying such data, but now that I'm working at a different job using neo4j, I can see how much simpler the medical informatics domain could be modeled and traversed in a graph database.

There's also all the models that requires a lot of partitioning because there will be a lot of data or of simultaneous queries. A relational database is only relational on a single server. Partitioning breaks the relationships (like, no joins between tables that exist on different servers). The new generation of SQL databases like VoltDB and Google F1 target this case, I don't know at which price.

>And to act like a guide on how to scale MongoDB to store 100GB is a problem is also ridiculous

While I agree with a good bit of what you say. I take issue with this. 100GB is not a lot of data by any modern definition. That this guide exists (or existed until it was removed) is a warning sign of hidden gotchas, which is I think what the original author was reacting to. When contemplating a change as big as mongo, those kinds of things make people whose butts are on the line for tech decisions nervous.

Also, that guide didn't say anything about what data structures were being used, the implicit assumption was that you had a properly structured mongo database to begin with.

That 100GB+ guide has re-appeared at a new URL:

  http://blog.mongodb.org/post/62899600960/scaling-advice-from-mongohq

Reply on news.ycombinator.com