cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-821) get_range_slice performance
Date Mon, 15 Mar 2010 19:43:27 GMT


Jonathan Ellis commented on CASSANDRA-821:

This is a huge step in the right direction.

The main cleanup that needs to happen is, the sstable iterator should take the same QueryFilter
`filter` as the memtable ones, so that the reducing iterator can indeed reduce to a single
Row (via cf.addall) and the "pull rows out of the iterator" step stays simple, w/o a second
round of filtering.  readColumnsForRow should go away entirely this way.

(Table.flusherLock only needs to be acquired for accesses to CFS.memtable variable, btw. 
I've updated the comment in its definition to make this more clear.)

Minor point: by convention, IteratingRow should become IIteratingRow, and needs apache license

> get_range_slice performance
> ---------------------------
>                 Key: CASSANDRA-821
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 0.6
>            Reporter: Brandon Williams
>            Assignee: Johan Oskarsson
>            Priority: Minor
>             Fix For: 0.7
>         Attachments: CASSANDRA-821.patch
> get_range_slice performance isn't that great.  CASSANDRA-799 helped in the case when
the memtable isn't flushed, but overall the operations per second and latency is still pretty
bad.  On a quad core node with a trivial amount of data I see around 130-150 ops per second
with set to slice 100 keys at a time, and latency is 300-500ms.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message