The cassandra FAQ answers the question as to why reads are slower than
writes as follows:
http://wiki.apache.org/cassandra/FAQ#reads_slower_writes
This drawback is unfortunate for systems that use time-based row
keys. In such systems, row data will generally not be fragmented very
much, if at all, but reads suffer because the assumption is that all
data is fragmented. Even further, in a real-time system where reads
occur quickly after writes, if the data is in memory, the sstables are
still checked.
I've been working on a patch that I hope will make read performance
comparable to write performance, if not faster in the cases where no
disk access is involved for the reads. The assumption is that for a
time-based row key the data will be fragmented only at the edges of
memtable flushes. Therefore, only 2 reads need occur either to the
current memtable in memory and the newest sstable, or 2 adjacent
sstables. In the case of real-time reads, I've further split the
single memtable into 2 memtables so that the 2 required reads will
happen against 2 memtables. The read algorithm is to search for the
first fragment until it is found and then only read from the adjacent
memtable or sstable.
I haven't uncovered any showstoppers with this approach, yet. I'm
hoping that by posting this message, someone might alert me if they
detect any flaws with this approach.
