> > 2) Cassandra has a less efficient memory footprint data pinned in > memory (or cached). With 3 replicas on Cassandra, each element of data > pinned in-memory is kept in memory on 3 servers, wheras in hbase only > region masters keep the data in memory, so there is only one-copy of > each data element. > > True in the general case, but if you want to optimize for READ.ONE. We > can make our caches work like hbase. > https://issues.apache.org/jira/browse/CASSANDRA-1314. >
Forgive my limited understanding of Cassandra, but I don't understand that issue commentary. Can you clarify? "snitch that prefers a single replica for all reads to a given key" sounds like 1/2 of "electing a master for a row range". However, the other half is assuring that all writes must include this replica. Otherwise if you did N3/W2/R1, you might write to the two copies that were not the "single preferred replica master". Did I understand that correctly? > #4 Not a fair comparison. If hbase is happy working with 2/3 replicas > it is not equal to Write.ALL Read.ONE. > Agreed. The reason I included it is that people discuss both N3/W2/R2 and N3/W3/R1 as possible matches for hbase functionality. They refer to N3/W3/R1 because it allows reads to come from a single server, just like in hbase.
