First, in order to achieve strong consistency in a distributed system with replication enabled, you will always have to write to multiple replicas: provided the number of replicas is the same, whether you're using a consistent-hashing based replication (Cassandra) or a distributed file system (HBase) it really doesn't matter much, as I/O latencies (both network and disk related) will always play a large role here.
That said, you can have different performances if you:
1) Change the replication factor: this is something you can do regardless of the actual system you're using, so it doesn't count.
2) Change the number of "acknowledged" writes/reads as a fraction of the replication factor: strongly consistent systems will always provide at least as much acknowledges as Cassandra's QUORUM, so no big win here.
3) Change the point where you acknowledge writes, either memory, disk or physical sync: this is about durability, and if you use different settings for different systems (i.e. Mongo VS Cassandra) it is apples and oranges.
4) Change your physical storage structure (provided same level of durability as explained above): different databases use different structures, Cassandra uses Memtables+SSTables, which I don't expect to be slower than HBase HDFS-based ones.
So in the end, Cassandra is at least as fast as other distributed databases, even when working in strongly consistent fashion.
And talking about consistency, as already pointed out by Jonathan, Cassandra actually provides a way to allow for strong consistency: also, with its tunable consistency levels, it provides greater freedom to implement different access patterns depending on the use case, as described on the blog post.
We already have an HBase cluster in-house we use together with Hadoop for social analytics.
By the way, we ruled it out as our operational experience with it was a little bit of a pain, in particular around version updates.
Talking about DynamoDB, it is certainly attractive as it scales, is managed by Amazon and all the yadda-yadda, but we didn't want to be lock-in to Amazon, and costs were another concern.
Agreed, we had a pleasant operational experience, except for some not-so-well documented details around auto-bootstrapping and host names, as briefly mentioned in the blog post.
But cluster elasticity and resiliency has been working really good so far.
Exactly: clustering and storage are more and more "commodity" features, as I see it.
The most important thing is going to be what you build upon them, the real value you provide to the user: is data partitioned or replicated? What data manipulation features are provided? And so on ...
Clustering and storage are completely based on Terracotta, and this is great: relying on a rock solid technology gives you the freedom to focus on more advanced features, such as communication, partitioning, data manipulation and querying.
Which is the same reason Voldemort and Riak rely on third-party storage, or HBase relies on Hadoop.
Terrastore already implements lightweight "stored procedures" in terms of server side updates: functions which atomically update a value based on some custom logic.
Future versions will provide map/reduce functions as well, probably in both Java and Javascript.
First, in order to achieve strong consistency in a distributed system with replication enabled, you will always have to write to multiple replicas: provided the number of replicas is the same, whether you're using a consistent-hashing based replication (Cassandra) or a distributed file system (HBase) it really doesn't matter much, as I/O latencies (both network and disk related) will always play a large role here.
That said, you can have different performances if you:
1) Change the replication factor: this is something you can do regardless of the actual system you're using, so it doesn't count.
2) Change the number of "acknowledged" writes/reads as a fraction of the replication factor: strongly consistent systems will always provide at least as much acknowledges as Cassandra's QUORUM, so no big win here.
3) Change the point where you acknowledge writes, either memory, disk or physical sync: this is about durability, and if you use different settings for different systems (i.e. Mongo VS Cassandra) it is apples and oranges.
4) Change your physical storage structure (provided same level of durability as explained above): different databases use different structures, Cassandra uses Memtables+SSTables, which I don't expect to be slower than HBase HDFS-based ones.
So in the end, Cassandra is at least as fast as other distributed databases, even when working in strongly consistent fashion.