advertise
« Paper: No Relation: The Mixed Blessings of Non-Relational Databases | Main | GemFire: Solving the hardest problems in data management »
Thursday
Oct292009

Digg - Looking to the Future with Cassandra

Digg has been researching ways to scale our database infrastructure for some time now. We’ve adopted a traditional vertically partitioned master-slave configuration with MySQL, and also investigated sharding MySQL with IDDB. Ultimately, these solutions left us wanting. In the case of the traditional architecture, the lack of redundancy on the write masters is painful, and both approaches have significant management overhead to keep running.

Since it was already necessary to abandon data normalization and consistency to make these approaches work, we felt comfortable looking at more exotic, non-relational data stores. After considering HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort, and Dynomite, we settled on Cassandra.

Each system has its own strengths and weaknesses, but Cassandra has a good blend of everything. It offers column-oriented data storage, so you have a bit more structure than plain key/value stores. It operates in a distributed, highly available, peer-to-peer cluster. While it’s currently lacking some core features, it gets us closer to where we want to be than the other solutions.

continue... 

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (2)

Interesting! I just wrote a blog article about Cassandra vs. HBase, and what each is stronger at. Maybe anyone reading this would find it interesting... http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/

October 29, 2009 | Unregistered CommenterBradford

This is a false dichotomy.
There is nothing to stop you pre-computing the results when using a relational database.
Some relational databases will even make this completely transparent and automatic for you by using "materialised views".

There are real and useful differences between relational and key-value databases, but this is not one of them.

November 2, 2009 | Unregistered CommenterNoel Grandin

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>