> 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
