If this was an intelligent piece analysing the pros/cons of MongoDB and when it would be an optimal choice then I could understand it. But this is the equivalent of blog spam from a guy who is selling a SQL Performance book.

Many articles regarding MongoDBs awful memory mapped simple b-tree data storage method have popped up on HN. Martin is merely talking about the politics of MongoDB; to call his links to polyglot methods and his information blog spam is dishonest to say the least. I thought it was a great post and I bet many other HNers who up voted it feel the same way.

> MongoDBs awful memory mapped simple b-tree data storage method

You realise that they are using default kernel implementation? Awful indeed. :)

If you are so anti-MongoDB, would you care to offer an alternative? It must support: - document-like storage (I already have schema on application layer), - simple use / administration, - hot backup, - single node operation.

While this list is mostly outlining why MongoDB is a great DB for my current use case, I am also genuinly interested in better solutions (for that case). So, fire away... :)

Let's see if I can make your day with a shameless plug.

First of all, using the kernel's paging algorithm for a database is awful. It has way less information about your access patterns than the database, so it's going to make a lot of bad decisions, and a bunch of MongoDB's problems with fragmentation and performance cliffs come from using mmap. It's quick and dirty.

Here's the alternative, and it supports the exact same document storage as MongoDB, the same administration interface, actually the same protocol everywhere, hot backup, and however many nodes you want: TokuMX[1]. It does all those things because it's actually mostly MongoDB, just with the storage engine replaced with an engine that works faster, compresses your data, and has more mature things like document-level locking for writers and better multi-document isolation semantics on a single node. Give it a whirl and let us know if you like it.

[1]: http://www.tokutek.com/products/tokumx-for-mongodb

Why is it called a "fractal tree"?

Marketing. No technical reason.

From what I can tell, this has been patented, but was implemented in part by Postgres much earlier.

I promise it hasn't, but I'm curious to see what you're talking about. Link?

See this thread: http://www.postgresql.org/message-id/511BDCAB.2080803@agliod...

That thread is talking about the possible inclusion of our indexing library inside Postgres, and was from before we had open sourced the code. IANAL but I think it would be possible to include the fractal tree library in Postgres now if someone wanted to do it, but none of it has ever been implemented by Postgres.

I stand corrected! Thanks for the info.

Everything you've mentioned is standard to SQL databases. If you have a schema you don't need NoSQL. Use an ORM for SQL for the language of your choice. Pretty much any db will run as a single node but you should never do that in practice, redundancy is security is stability

> If you have a schema you don't need NoSQL

Sure, but by that argument I don't need SQL either. I am not sure what your point is?

Anyway, the selling point (for me) is that I don't need to find some fancy ways to translate my schema to relational schema. For instance, let's say I have some text content in two languages; in relational DB the texts should probably go to a separate table and I should reference the main record by some foreign key. In document-oriented DBs I can just put both of the texts inside the record... To me that makes much more sense.

But yeah, if you are a hardcore SQL user who is used to normalizing the data until it hurts (as someone else commented) it is difficult to break out of the habit.

And after you eliminate SQL as an alternative (in my case) there are not many options left. At least I couldn't find (m)any.

If you know you are only storing two languages, they can go directly on the parent table, named english_text and spanish_text. If you are talking about the easyness of storing a hashmap in NoSQL, ie: { english :'text', spanish : 'text', french: 'text' }

You can achieve this in the same table with the JSON storage type:

http://www.postgresql.org/docs/devel/static/datatype-json.ht...

Really though, a decent ORM will take care of all the foreign key implementation, and a hashmap is well served by a 2nd table called 'texts' with 3 columns. I can see why you would be opposed to this, because of the extra join but given the right indexes it won't be slow at all.