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实现队列。再辅以数据超时的设置，真的是异常灵活。但是在我看来，这带来了两个坏处：

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

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

【完】

转载于:https://www.cnblogs.com/sing1ee/archive/2012/06/29/2765051.html