incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Worst case #iops to read a row
Date Mon, 12 Apr 2010 20:51:11 GMT
On Mon, Apr 12, 2010 at 3:45 PM, Time Less <timelessness@gmail.com> wrote:
> I'm confused. That's really worst-case? 3 iops?

max 3 per sstable, as RK clarified out.

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

basically what is described in sections 5.3 and 5.4 here:
http://labs.google.com/papers/bigtable.html

It's also covered in video form here:
http://www.facebook.com/video/video.php?v=540974400803

> And what about multiple revisions of data, ie: if there were N updates and M
> deletes on the key before a major compaction?

this is what will determine how many sstables there are.

> And what about Bloom Filter
> false positives?

Then you have more sstables to consider than you otherwise would have.

Note that minor compactions do an excellent job of reducing the
sstable count; they just can't remove tombstoned rows entirely.

> What if the client asks a node that doesn't have the key?

Then there is an extra network hop to the node(s) that do, but we're
talking about disk i/o I assume.

-Jonathan

Mime
View raw message