This was described in good detail here: http://thelastpickle.com/2011/04/28/Forces-of-Write-and-Read/
On Tue, Jan 22, 2013 at 9:41 AM, Brian Tarbox <tar...@cabotresearch.com>wrote: > Thank you! Since this is a very non-standard way to display data it > might be worth a better explanation in the various online documentation > sets. > > Thank you again. > > Brian > > > On Tue, Jan 22, 2013 at 9:19 AM, Mina Naguib <mina.nag...@adgear.com>wrote: > >> >> >> On 2013-01-22, at 8:59 AM, Brian Tarbox <tar...@cabotresearch.com> wrote: >> >> > The output of this command seems to make no sense unless I think of it >> as 5 completely separate histograms that just happen to be displayed >> together. >> > >> > Using this example output should I read it as: my reads all took either >> 1 or 2 sstable. And separately, I had write latencies of 3,7,19. And >> separately I had read latencies of 2, 8,69, etc? >> > >> > In other words...each row isn't really a row...i.e. on those 16033 >> reads from a single SSTable I didn't have 0 write latency, 0 read latency, >> 0 row size and 0 column count. Is that right? >> >> Correct. A number in any of the metric columns is a count value bucketed >> in the offset on that row. There are no relationships between other >> columns on the same row. >> >> So your first row says "16033 reads were satisfied by 1 sstable". The >> other metrics (for example, latency of these reads) is reflected in the >> histogram under "Read Latency", under various other bucketed offsets. >> >> > >> > Offset SSTables Write Latency Read Latency Row >> Size Column Count >> > 1 16033 0 0 >> 0 0 >> > 2 303 0 0 >> 0 1 >> > 3 0 0 0 >> 0 0 >> > 4 0 0 0 >> 0 0 >> > 5 0 0 0 >> 0 0 >> > 6 0 0 0 >> 0 0 >> > 7 0 0 0 >> 0 0 >> > 8 0 0 2 >> 0 0 >> > 10 0 0 0 >> 0 6261 >> > 12 0 0 2 >> 0 117 >> > 14 0 0 8 >> 0 0 >> > 17 0 3 69 >> 0 255 >> > 20 0 7 163 >> 0 0 >> > 24 0 19 1369 >> 0 0 >> > >> >> >
