Retrospective from Postmark on outages (MongoDB)

Re:Retrospective from Postmark on outages (MongoDB) by thibaut_barrere on Saturday March 31, 2012 @12:42PM (#3780729)

> Every case I've seen has been the data traffic exceeding the capacity of the system. There is no database that works well under those circumstances.

Is there a benchmark somewhere comparing the memory/disk consumption of MongoDB vs. other datastores?

If there's a significant overhead (and my early tests tend to show that there was - but I didn't make a strict benchmark though), then it would become very related to MongoDB then.

(honest and real question, I'm a MongoDB user btw, as well as Redis, MySQL, Postgresql etc).

[ Parent | on HN ]

Re:Retrospective from Postmark on outages (MongoDB) by rogerbinns on Saturday March 31, 2012 @04:08PM (#3781386)

The main overhead for MongoDB's storage is that the "column name" (keys) is stored in every record rather than just once as with traditional SQL database and some of the other NoSQL solutions. That is why you'll often see developers using very short key names, and one use for an "ORM" to translate between developer friendly names and short stored names.

Of course this can be solved fairly easily by the MongoDB developers by having a table mapping between short tokens/numbers and the long names. This is the ticket:

https://jira.mongodb.org/browse/SERVER-863

This is someone's measurements with different key names:

http://christophermaier.name/blog/2011/05/22/MongoDB-key-nam...

[ Parent | on HN ]

Re:Retrospective from Postmark on outages (MongoDB) by thibaut_barrere on Sunday April 01, 2012 @04:12AM (#3783098)

Thanks for the links.

My question goes further though, as someone who has worked with, and implemented too, column-based stores: I'm curious to compare the respective space/ram consumption for the data part, too.

I think I'll write such a benchmark one day :)

[ Parent | on HN ]