NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Sharding: All content tagged as Sharding in NoSQL databases and polyglot persistence

3 Reasons to Use MongoDB

Ryan Angilly:

MongoDB is teh awesome because of a simple query syntax, the ability to shard data across machines easily, and the ability to store files in GridFS while taking advantage of replication & sharding.

Indeed, I think the combination of query syntax and GridFS makes MongoDB unique.

Sharding is supported by many other NoSQL databases and for many of these things are even simpler than having mongod, mongos, etc. Between document databases, CouchDB has recently got BigCouch to address the scaling issue[1].

As regards querying, one could say that having MapReduce around would get you similar functionality to MongoDB queries. But starting with users’ familiarity with using queries vs programmatic querying and up to execution behavior MongoDB queries and MapReduce are quite different.

  1. Even before BigCouch, there were different solutions for scaling CouchDB  ()

Original title and link for this post: 3 Reasons to Use MongoDB (published on the NoSQL blog: myNoSQL)


Think Twice Before Sharding

Andrew Glover:

In plain English: sharding without considering the long term consequences is dangerous. Think twice before sharding, especially if you’re considering it before all else. In fact, if you do find yourself considering sharding at the outset, then perhaps you should be looking at a NoSQL alternative to the relational model.

NoSQL databases solution to this is… sharding.

Original title and link for this post: Think Twice Before Sharding (published on the NoSQL blog: myNoSQL)


Single Server vs Sharding vs Dynamo Style Systems

Funny video from Basho guys (physically) demonstrating what’s happening with your data when a server crashes

Next time, send the mugs to people and use real servers for such demos!

MongoDB Sharding Explained

Kristina Chodorow (@kchodorow) explains MongoDB’s sharding implementation (nb still in alpha at the time of this writing):

Sharding is the not-so-revolutionary way that MongoDB scales writes (it’s very similar to techniques described in the Big Table paper and by PNUTS)

MongoDB Sharding

Credit Kristina Chodorow

On the same topic of MongoDB sharding, you’ve probably heard already about the “8000000 operations per second with our sharded storage” published on the same blog. I’d like to strongly encourage you once again to check the facts (nb which are almost completely missing this time) before admitting such benchmarks/numbers.