这是一篇Jonathan Ellis写的文章，与DynamoDB进行比较，突出Cassandra的优点，但似乎后面的评论，大家并不那么接收Cassandra，尤其是在云主机的环境下。原文在这儿。 这篇文章就不详细的翻译了，因为有很多的废话，捡重要的说吧。 Cassandra和DynamoDB有什么关系呢？按照文章的说法儿，这简直就是一个轮回。Cassandra初的实现，很大程度上借鉴了Dynamo那篇论文的实现。但是数据存储模型等并没有采用。今年，Amazon推出DynamoDB，除了Dynamo基础之外，更是从Cassandra学习了很多内容。很有意思。以至于作者后开玩笑说，Cassandra已经是一个uncle了(不做多想^-^)。 具体比较如下：

CassandraDynamoDB

Key + columns data model

Composite key support

Yes

Yes

Tuneable consistency

Most operations

Distributed counters

Largest value supported

Idempotent write batches

No

Time-to-live support

No

Conditional updates

No

Indexes on column values

Hadoop integration

M/R, Hive

Multi-datacenter support

Mutiple availability zones only

Integrated caching

Unclear

High performance on commodity disks

Yes

N/A

Monitorable

Deployable

Anywhere

Only on AWS

上面比较的这些，中规中矩。不过下面反驳的人，主要还是在Amazon云上部署Cassandra要比DynamoDB麻烦，不可控，价格比较贵。大家讨论了半天，到底应该如何定价。我不关心这个。 文章中提到，由于Cassandra的写机制，使得Cassandra在普通的磁盘上表现要远好于DynamoDB，但是如果切换为SSD，Cassandra提升空间小，反而有点不够突出。不过，我认为不会差，我没有测试过DynamoDB，只是根据顺序写能够很好的利用磁盘带宽。 对于Cassandra的模型，我自己持一定保守的态度。Cassandra号称是个提出如此灵活的数据模型的NoSQL。这种模型，首先我认为是非常灵活的，可以只更新部分列，不用更新的时候，要把整个行的数据都读出来。按需更新指定的即可。这样，一行数据，就可以有非常多的column，有多少，可以自己定。其实这里也暗示的，可以用这个机制，用Cassandra实现队列。再辅以数据超时的设置，真的是异常灵活。但是在我看来，这带来了两个坏处：

需要更多的compaction操作，就以为着需要更多的I/O

数据有多份，每次读的时候，如果更新频繁尤其是部分列更新频繁，都要读多个sstable文件，即使是leveled compaction策略，也会因为整个原因读性能严重下降

反正终，都是会让读性能下降。这是一个两难的事情，都有好处，也都有确点。我们需要在实际应用中，不断揣摩，找到Cassandra的佳应用场景。有了实际场景，还是不够的。仍旧需要对Cassandra的深入理解。这也是我这系列文章的主要目的。

【完】