Cassandra Internals – Reading

Those interested in the topic may also want to read this:<p>"Why we’re using HBase (at Adobe)": <a href="http://hstack.org/why-were-using-hbase-part-1/" rel="nofollow">http://hstack.org/why-were-using-hbase-part-1/</a><p>It is a fine "war-story" of picking new technology and making it work without losing data.<p>(It was submitted yesterday by the author here: <a href="http://news.ycombinator.com/item?id=1196382" rel="nofollow">http://news.ycombinator.com/item?id=1196382</a>, but got killed with 5 points, which baffles me. I found it when puzzling out why my submission today was instantly killed, with a different item id ...)<p>[P.S. minor bug report: my 'dead' item has a working link to the article, which it perhaps shouldn't. <a href="http://news.ycombinator.com/item?id=1200833" rel="nofollow">http://news.ycombinator.com/item?id=1200833</a>]

The reason uncached reads are slower in Cassandra is not because the sstable is inherently io-intensive (it's actually better than b-tree based storage on a 1:1 basis) but because in the average case you'll have to merge row fragments from 2-4 sstables to complete the request, since sstables are not update-in-place.

Little misinformative imo. While Cassandra has eventual consistency, reads are not slow necessarily. With the right Cache settings tuned correctly (KeysCached/RowsCached) and available memory, Cassandra actually performs quite well. Cassandra is virtually worthless without those cache features kind of like MySQL is without indexes. They are slower than writes but I think it would've been more proper to talk about how the cache works and more interesting.<p>Like any database, MySQL/Postgres/etc, it's a dark art in terms of understanding how to make it work.

Cached (by Google) text only version: <a href="http://209.85.129.132/search?q=cache:http://www.mikeperham.com/2010/03/17/cassandra-internals-reading/&#38;hl=en&#38;strip=1" rel="nofollow">http://209.85.129.132/search?q=cache:http://www.mikeperham.c...</a>

Cassandra isn't easy to learn like, say, couchdb. But Couch uses JSON (An awesome choice, BTW), and Cassandra uses Thrift.<p>Cassandra is kinda difficult to pick up because there is no SQL equivalent, there are no relationships, joins or "where"s.<p>So, basically, it's an engine without user friendly controls. But - it's probably the most awesomely powerful storage engine yet available in the public domain.<p>Imagine if Google released a server image of one of their storage nodes... ostensibly, that's what Facebook did with Cassandra.