> 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.

Perhaps I am misunderstanding you, but why is this a problem (in the
particular case of time based row keys) given that existence of the
bloom filters which should eliminate the need to go down to the
sstables to any extent more than that they actually contain data for
the row (in almost all cases, subject to bloom filter false
positives)?

Also, for the case of the edges where memtables are flushed, a
write-through row cache should help alleviate that. I forget off hand
whether the row cache is in fact write-through or not though.

-- 
/ Peter Schuller

Reply via email to