My score after the first period was 4-1. But Emin Gün Sirer contested the 1 in the follow up post to 10gen’s reply:

Until recently, MongoDB did not talk about requestStart() and requestDone() in any context except when talking about how to ensure a very weak consistency requirement. Namely, if you don’t use this pair of operations, then a write to the database followed by a read from the database, by the same client, can return old values. So, I write 42 for key k with a WriteConcern.SAFE, read key k, and get some other number, because the Mongo driver can, by default, very well send the first request to one node over one connection, and the second one to another, over another connection. So requestStart() and requestDone() were billed as a mechanism to avoid that scenario; I saw no mention that they were required for correctness in multithreaded settings. I bet there is plenty of multithreaded code that does not follow that pattern. Such code is broken; if you’re a Mongo user, it’d be a good idea to check if you ever use getLastError without a bracketing requestStart() and Done().

5-0.

Original title and link: MongoDB Is Still Broken by Design 5-0 (NoSQL database©myNoSQL)

via: http://hackingdistributed.com/2013/02/07/10gen-response/#id2

Emin Gün Sirer concluding a follow up post to MongoDB fault tolerance is broken by design:

So let us give onto Mongo what is clearly its: it’s mature software with a large install base. If it loses data, it’ll likely do so because of a deliberate design decision, rather than a bug. It’s easy to find Mongo hosting and it’s relatively easy to find people who are experienced with it. So if all your data is really of equal and low value, and you can afford to lose some of it, and your app’s needs are unlikely to grow, then MongoDB can be a fine pick for your application.

Looks like we mostly agree.

Original title and link: When Data Is Worthless - Give MongoDB What Is MongoDB’s (NoSQL database©myNoSQL)

via: http://hackingdistributed.com/2013/02/03/when-data-is-worthless/

Emin Gün Sirer:

So, MongoDB is broken, and not just superficially so; it’s broken by design. If you’re relying on its fault tolerance,a you’re probably using it wrong.

He’s not the first to write about some of the critical issues in MongoDB. Every once in a while, there has been at least one post detailing one of these. But none of them stopped MongoDB’s adoption. Why? My only explanations are that:

1. these posts are not reaching enough people;
2. MongoDB is used mostly for simple scenarios where the occurance of such errors can be ignored
3. those using MongoDB for more complicated scenarios have developed internal, application specific workarounds

Original title and link: MongoDB Fault Tolerance - Broken by Design (NoSQL database©myNoSQL)

via: http://hackingdistributed.com/2013/01/29/mongo-ft/

Yuan Ji:

I want a sequence number generator from MongoDB to give me unique sequence number. The operations are to return current sequence number and also increase the sequence number in the database. In MongoDB, command findAndModify atomically modifies and returns a single document. So we can use this command to query the sequence number and increase it by $inc function.

The solution is interesting and the post includes the Spring-ified code for it. But there’s no word of the possible issues this solution would run into related to contention to update the same record. Even with row level locking and things would be pretty bad for an app needing lots of sequence number. But with MongoDB’s database level locking, things could get pretty ugly.

Original title and link: MongoDB Sequence Number Generators Using findAndModify and Spring Data (NoSQL database©myNoSQL)

via: http://www.jiwhiz.com/post/2013/1/Add_A_Counter_To_MongoDB_With_Spring_Data

SM Sohan expresses his discontent with MongoDB’s JSON-based query representation:

I find the MongoDB API is abusing JSON in a really bad way. JSON is probably a good format for storing the documents in MongoDB, but using JSON for it’s weird API is simply a terrible idea.

Using JSON (nb BSON) for representing queries works well for basic equality matching. But I agree that for more advanced queries it looks quite forced. While definitely not perfect, I prefer (biasedly) RethinkDB’s API. On the other hand, I’m not aware of any proposals to make MongoDB’s query language better. Nor that there would be any willingness to change it.

Update: The (always) entertaining HN thread.

Original title and link: MongoDB Is Abusing JSON With Its Query Language (NoSQL database©myNoSQL)

via: http://smsohan.com/blog/2013/01/17/abusing-json/

Nice data experiment run by Sebastien Goasguen against the CloudStack mailing list:

To get the graphs I grabbed the emails archive from Apache. I used Python to load the mbox files into single Mongo collections. I cleaned the data to avoid replications of senders as well as remove JIRA and Review Board entries. Then with a little bit of PyMongo I made the queries and build the graph with NetworkX. Finished up with the graph visualization and calculations using Gephi. Since there are thousands of emails and threads, there is still some work to pre-process the data, avoid duplicates and match individuals to multiple email addresses.

Three questions:

1. would using a graph database made this experiment easier?
2. would Linkurious be able to generate these graphics?
3. is the code available anywhere so someone else could try to use a graph database and maybe run other types of visualizations?

Original title and link: Social Network Analysis of Apache CloudStack (NoSQL database©myNoSQL)

via: http://sebgoa.blogspot.ch/2013/01/social-network-analysis-of-apache.html

Eric Knorr interviewed Dwight Merriman for InfoWorld: “10gen CEO: Why we’re the NoSQL leader“.

Q: You created the first widely successful NoSQL document database.What did you base that architecture on?

A: It wasn’t based on anything in particular; it’s a career’s worth of learning what works and what doesn’t. We were looking at cloud computing — at needs for horizontal scalability and how we wanted to write code — and we couldn’t find tools that did what we wanted.

Recently, new MongoDB hosting company ObjectRocket launched with the message: “The Cloud Is Broken for MongoDB“. Was it simply bad PR or someone didn’t get the history of MongoDB right?

Original title and link: What Is MongoDB’s Architecture Based On? (NoSQL database©myNoSQL)

via: http://www.infoworld.com/print/211201

The cloud is broken. It’s not designed to properly run persistent data stores like MongoDB. ObjectRocket is designed from the ground up to fix this problem.

Any snarky comments fit perfectly.

James Watters

Original title and link: The Cloud Is Broken for MongoDB (NoSQL database©myNoSQL)

via: http://www.objectrocket.com/details

A post by Pandora FMS team about monitoring options for MongoDB:

If MongoDB goes wrong, all your apps will fail. So monitoring the main variables and configuration parameters of your database is the best option to make sure that your values are right and your users are happy.

The post talks about the tools that come with MongoDB (mongotop, mongostat, the stats available through the MongoDB shell, logfiles, etc.), but also introduces their PandoraFMS library. There’s no word about 10gen’s hosted MongoDB Monitoring Service, nor other MongoDB utilities for monitoring or the latest MongoMem collection memory usage library.

In terms of what are the most interesting stats, Simon Maynard’s 5 things to Monitor in MongoDB and these other 3 metrics should be a good start.

Original title and link: How to Monitor MongoDB (NoSQL database©myNoSQL)

via: http://blog.pandorafms.org/?p=821&buffer_share=0406c