Digg - Looking to the Future with Cassandra
Thursday, October 29, 2009 at 8:47AM 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.
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/
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.