3 ms·
"Consistency problems" is a red herring; Cassandra can be easily asked to sacrifice availability for consistency [on a per-request basis], if that's what you wa
by jbellis 14y ago
"Consistency problems" is a red herring; Cassandra can be easily asked to sacrifice availability for consistency [on a per-request basis], if that's what you want: http://www.datastax.com/docs/1.1/dml/data_consistency http://www.datastax.com/docs/1.1/dml/data_consistency
Facebook never used modern Apache Cassandra, so when they tasked a team of experienced Haddop/HDFS engineers to build Messaging, it was natural for them to choose HBase. But the things they've had to do to deal with the problems in that architecture (e.g., sharding into "cells" to deal with namenode SPOF) [1] make me think that they would have done better with Cassandra.
[1] http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase/23 http://www.slideshare.net/brizzzdotcom/facebook-messages-hba...
- dhruba 14y agoIf you have three replicas in casandra and you want your reads to be consistent, you would have to read from at least two replicas . This doubles the number of iops to the disk subsystem. Most disk based storage systems are bottlenecked by random iops, and a solution that requires double-the-iops is a non-starter.
- 3amOpsGuy 14y agoI don't think that's strictly true. With cassandra you choose where the extra reads (or writes) to ensure consistency occur as best suits your use case: * At write time (write quorum) like a traditional replicated datastore * At read time (read quorum) * In the background (read one, with a non-zero chance of read repair) This is quite nice to be able to bend Cassandra on a use case by use case basis (NB: these are not cluster wide approaches, for different columns / circumstances i can choose different patterns).