Bradford Stephens (CEO Drawn to Scale):

Today, we’re announcing that we’ve ported MongoDB onto Spire as a platform. What this means is:

1. You can easily scale your MongoDB cluster to 200+ TB
2. You don’t need to change a line of code in your app to make it scale
3. You can use ANSI SQL (yes, joins), Mongo queries, and Hadoop on the same data.

Just a couple of thoughts:

1. the push of NoSQL databases to get SQL support is growing extremely fast. But I still doubt this is happening thanks to the advantages of SQL, but more due to the 30 years of investments in the SQL ecosystem.
2. I don’t agree with Bradford’s “MongoQL is also great because unlike SQL, there is only one flavor”. As far as I can tell, MongoDB comes with 3 flavors of queries: the object-based query language, the aggregation framework (a combination of object-based QL and pipelining) and the Javascript-based MapReduce
3. last but not least, what are Ryan Rawson’s thoughts about Drawn to Scale going Mongo.

Original title and link: Drawn to Scale Announces Spire for Mongo (NoSQL database©myNoSQL)

via: http://drawntoscale.com/announcing-spire-for-mongo/

MongoDB 2.4 is out:

Highlights of MongoDB 2.4 include:

• Hash-based Sharding
• Capped Arrays
• Text Search (Beta)
• Geospatial Enhancements
• Faster Counts
• Working Set Analyzer
• V8 JavaScript engine

Original title and link: MongoDB 2.4 Released: Hash-Based Sharding, Geo Enhancements, Text Search (NoSQL database©myNoSQL)

via: http://blog.mongodb.org/post/45754637343/mongodb-2-4-released

Kristina Chodorow¹ shared a good list of tests to put a MongoDB cluster through:

Here are some exercises to battle-test your MongoDB instance before going into production. You’ll need a Database Master (aka DM) to make bad things happen to your MongoDB install and one or more players to try to fix it.

Netflix is using a series of tools that perform similar tests against their Cassandra clusters. With a small twist: they are run against the production clusters.

Original title and link: Battle-Test Your MongoDB Cluster (NoSQL database©myNoSQL)

via: http://architects.dzone.com/articles/databases-and-dragons-battle

MongoDB 2.2 introduced thetouch command, which loads data from the data storage layer into memory. The touch command will load a collection’s documents, indexes or both into memory. This can be ideal to preheat a newly started server, in order to avoid page faults and slow performance once the server is brought into production. You can also use this when adding a new secondary to an existing replica set to ensure speedy subsequent reads.

I could see how this command could be useful for a caching system, but I haven’t seen it in any database. It’s probably a workaround for the memory mapped files mechanism used by MongoDB’s persistence.

Original title and link: MongoDB Touch Command (NoSQL database©myNoSQL)

via: http://blog.mongodb.org/post/44706549534/mongodb-tip-the-touch-command

Francois Zaninotto:

MongoDB 2.1 introduced the aggregation framework, a faster alternative to Map/Reduce for common aggregation operations. If you took a look at the documentation and examples, you may have found the feature intimidating. Once you tame it, this new feature reveals itself as a very powerful beast. So read on to discover its true power through a series of examples.

The aggregation framework is indeed an interesting feature of MongoDB. And it’s definitely more useful compared to MongoDB’s MapReduce which came with quite a few limitations. Now MongoDB has 3 different languages: the object-based query language, the aggregation framework (still object-based but using different operators and execution model) and the Javascript-based MapReduce.

Original title and link: Comparing MongoDB New Aggregation Framework and SQL (NoSQL database©myNoSQL)

via: http://architects.dzone.com/articles/comparing-mongodb-new

Rackspace in a post explaining why they bought into MongoDB through the acquisition of ObjectRocket:

MongoDB is easy to get started, but complex to manage and scale.

I bet 10gen loves reading things like this. It also serves well the adoption of MongoDB.

Original title and link: MongoDB Represents the Perfect Opportunity for Rackspace’s Fanatical Support (NoSQL database©myNoSQL)

via: http://www.rackspace.com/blog/why-mongodb/

The Mortar blog:

Mongo was built for data storage and retrieval, and Hadoop was written for data processing. So naturally, data processing is often better offloaded to Hadoop. Here’s why:

1. Easier, more expressive language
2. Libraries to build on
3. Big performance improvements
4. Separate workloads mean less load

For the how part, the post recommends their own Hadoop-as-a-Service platform and a set of libraries the Mortar platform provides.

✚ While browsing the Mortar blog and website I couldn’t find any information related to the costs of transferring data. The AWS services usually have a data transfer dimension, which most often has an important impact on the total costs of a solution.

Original title and link: Integrating MongoDB and Hadoop: Why & How (NoSQL database©myNoSQL)

via: http://blog.mortardata.com/post/43080668046/mongodb-hadoop-why-how

In this post, we’ll see how to install MongoDB support for Pig and we’ll illustrate it with an example where we join 2 MongoDB collections with Pig and store the result in a new collection.

Color me very biased this time, but all these (especially the JOIN) can be done directly using RethinkDB.

Original title and link: Using Hadoop Pig With MongoDB (NoSQL database©myNoSQL)

via: http://chimpler.wordpress.com/2013/02/07/using-hadoop-pig-with-mongodb/

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