In his “what I’ve learned while using MongoDB for an year” post, Simon Maynard recommends 5 metrics to always monitor:

1. index sizes
2. current ops
3. index misses
4. replication lag
5. I/O performance

The 1st and the 3rd are about making sure all your MongoDB working set (including indexes) fits in RAM.

Original title and link: 5 Things to Monitor in MongoDB (NoSQL database©myNoSQL)

via: http://snmaynard.com/2012/10/17/things-i-wish-i-knew-about-mongodb-a-year-ago/

Rick Copeland describes the results of his experiment designing and testing a MongoDB-based monitoring system. Some of his findings are quite interesting:

1. So documents that grow and grow and grow are a real performance-killer with MongoDB.
2. BSON actually stores documents as an association list thus lookups are not constant-speed

One aspect that the post doesn’t cover is how MongoDB behaves when there’s a lot of data contention which is usually the case for tracking systems.

Original title and link: Designing a MongoDB Schema for a Monitoring System (NoSQL database©myNoSQL)

via: http://blog.pythonisito.com/2012/09/mongodb-schema-design-at-scale.html?spref=tw

Diego Basch:

So, one gem install and two lines of code later I was happily inserting documents into a MongoDB server on my puny AWS Micro instance somewhere in Oregon. It worked just fine for all of three weeks.

It is to MongoDB’s credit if they convinced people that all you need to run MongoDB is to install it, install a Ruby library, and start inserting data without ever needing to look at the documentation.

Original title and link: I’ll Give MongoDB Another Try. In Ten Years… Or Maybe Just Read the Docs First (NoSQL database©myNoSQL)

via: http://diegobasch.com/ill-give-mongodb-another-try-in-ten-years

Robby Grossman talked at Boston Riak meetup about Shareaholic’s migration from MongoDB to Riak and their requirements and evaluation of top contenders: HBase, Cassandra, Riak.

Why not MongoDB?

• working set needs to fit in memory
• global write lock blocks all queries despite not having transactions/joins
• standbys not “hot”

Bullet point format pros and cons for HBase, Cassandra, and Riak are in the slides.

via: http://blog.shareaholic.com/2012/08/migrating-to-riak-at-shareaholic/

10gen President Max Schireson for PandoDaily:

10Gen’s vision is to build a software platform company akin to Redhat or Oracle, Schireson says. “That’s the type of company we want to build,” he says. “Those companies don’t get acquired.”

Original title and link: 10Gen: That’s the Type of Company We Want to Build (NoSQL database©myNoSQL)

via: http://pandodaily.com/2012/09/03/how-10gen-is-pulling-engineers-from-wall-street-to-become-an-anchor-of-nyc-tech/

Jeff Cogswell compares some short code samples in an attempt to answer the much bigger question:

But what about the programmers, who write the client code that access the databases? Where do the disagreements leave them? From a programming perspective, is SQL really that horrible and outdated? Or is the new NoSQL really that awful to work with? Perhaps they both have strengths and good points.

I confess that reading the above made me curious about what the article would conclude. Unfortunately, by the time I’ve read the first comparison (JavaScript in NodeJS using SQL vs Mongo) I realized my expectations were too high. For a few reasons:

1. it would have been impossible to compare the APIs of all relevant NoSQL databases with a relational database;
2. it would have been very difficult to choose a generic, representative enough use case;
3. the results would have always been heavily influenced by the quality of drivers and libraries used.

Last but not least, many of the merits of the NoSQL databases are related to operational complexity and not programming complexity. As someone that did a fare amount of coding and close to zero operations, I would probably feel OK accepting a bit of programming complexity for simplified operations. But that might be just a biased opinion.

Original title and link: Which Is Better for Programmers: SQL vs. NoSQL? (NoSQL database©myNoSQL)

via: http://slashdot.org/topic/bi/sql-vs-nosql-which-is-better/

Sergio Bossa tells the story of migrating the Atlas platform from using MongoDB to Cassandra emphasizing the reasons behind their decision:

• It works on the JVM, and we have lots of in-house experience on it.
• It scales in terms of processing and storage capacity.
• Its column-based data model gives us some advanced capabilities we will talk about in a few minutes.
• Its tunable consistency levels provide greater control over high availability and consistency requirements.

As regards what made them look into a different solution:

• We need higher resiliency to faults: MongoDB provides replica sets, but we’re experiencing lots of problems with replication lags and during replica synchronization.
• We need higher scalability: MongoDB global lock and huge memory requirements aren’t already going to cope well with our growing data set.

Original title and link: From MongoDB to Cassandra: Why Atlas Platform Is Migrating (NoSQL database©myNoSQL)

via: http://metabroadcast.com/blog/looking-with-cassandra-into-the-future-of-atlas