Amazon DynamoDB与Cassandra比较
这是一篇Jonathan Ellis写的文章，与DynamoDB进行比较，突出Cassandra的优点，但似乎后面的评论，大家并不那么接收Cassandra，尤其是在云主机的环境下。原文在这儿。 这篇文章就不详细的翻译了，因为有很多的废话，捡重要的说吧。 Cassandra和DynamoDB有什么关系呢？按照文章的说法儿，这简直就是一个轮回。Cassandra最初的实现，很大程度上借鉴了Dynamo那篇论文的实现。但是数据存储模型等并没有采用。今年，Amazon推出DynamoDB，除了Dynamo基础之外，更是从Cassandra学习了很多内容。很有意思。以至于作者最后开玩笑说，Cassandra已经是一个uncle了（不做多想^-^）。 具体比较如下：
| Cassandra | DynamoDB | |
|---|---|---|
| Key + columns data model | Yes | Yes |
| Composite key support | Yes | Yes |
| Tuneable consistency | Yes | Most operations |
| Distributed counters | Yes | Yes |
| Largest value supported | 2GB | 64KB |
| Idempotent write batches | Yes | No |
| Time-to-live support | Yes | No |
| Conditional updates | No | Yes |
| Indexes on column values | Yes | No |
| Hadoop integration | M/R, Hive, Pig | M/R, Hive |
| Multi-datacenter support | Full cross-region | Mutiple availability zones only |
| Integrated caching | Yes | Unclear |
| High performance on commodity disks | Yes | N/A |
| Monitorable | Yes | Yes |
| Backups | Low-impact snapshot + incremental | Manually with EMR |
| 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策略，也会因为整个原因读性能严重下降
