cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Time Less <timelessn...@gmail.com>
Subject Re: Worst case #iops to read a row
Date Mon, 12 Apr 2010 20:45:49 GMT
> >> worst case is 2 or 3, depending on row size:
> >>
> >> one seek to read the right row index block
> >> one seek to read the row header (bloom filter + column index)
> >> if it's a big row, one seek to read the column block (block size is
> >> configurable, default is 256KB)
> >
> > [This is all per-sstable that contains the row]
>

I'm confused. That's really worst-case? 3 iops?

What if we have 10B rows in the column family? What sort of index do you use
that would only require one iop to find the row index block?

And what about multiple revisions of data, ie: if there were N updates and M
deletes on the key before a major compaction? And what about Bloom Filter
false positives? What if the client asks a node that doesn't have the key?
None of those cause iops?

Forgive my naïveté, but having worked with large datasets all my life, I'm
having a really hard time wrapping my head around what sort of data
structures and cluster layout would allow you to retrieve data in so few
iops.

-- 
timeless(ness)

Mime
View raw message