ALL COVERED TOPICS

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

NAVIGATE MAIN CATEGORIES

Close

NoSQL: The Alternative to MySQL Sharding

Lynn Monson (@lmonson) has a very good list of possible issues while scaling out with MySQL (relational db):

You’re going to have to face a few realities:

  1. Master DB machines go down or get sick. Given a number of read slaves of that master, it’s non trivial to figure out which of the slaves becomes the new master and how to get the other read slaves to begin replicating from that new master at the proper point. (Amazon’s upcoming RDS read slaves are, therefore, pretty amazing technology)
  2. When master DB machines go down, you will incur a delay in setting up a new master
  3. How do you add new shards and rebalance the data?
  4. You need a way to know which shard to talk to. Perhaps by implementing your own version of Consistent Hashing?
  5. Caching is also your problem. You can use off the shelf systems, say memcached, to reduce the work but its till not zero work.
  6. You will most likely give up distributed joins between the various shards.

On the other hand, not all NoSQL databases are solving all these issues.

Original title and link: NoSQL: The Alternative to MySQL Sharding (NoSQL databases © myNoSQL)

via: http://lmonson.com/blog/?p=204