You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Per Olesen <po...@trifork.com> on 2010/06/04 13:59:32 UTC
Are 6..8 seconds to read 23.000 small rows - as it should be?
Are 6..8 seconds to read 23.000 small rows - as it should be?
I have a quick question on what I think is bad read performance for this simple setup:
<ColumnFamily Name="Dashboard"
ColumnType="Super"
CompareWith="UTF8Type"
CompareSubcolumnsWith="UTF8Type" />
SCF:Dashboard
key:username1 -> {
SC:uniqStr1 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr2 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr3 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr4 -> { col1:val1, col2: val2, ... col8:val8 },
... up to 23.000 "rows"
key:username2 -> {
SC:uniqStr5 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr6 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr7 -> { col1:val1, col2: val2, ... col8:val8 },
SC:uniqStr8 -> { col1:val1, col2: val2, ... col8:val8 },
...
A given key "username1" has e.g. 23.000 super column unique (rows). When I try and simply raw-read all these rows, it takes what I think isn't pretty fast - approximately 6-8 seconds. I know, there are a millions things that affect this, but I would just like to have a yes or no if this really can be as it should be?
My cassandra is a pretty unchanged v0.6.1.
I read using this code:
ColumnParent parent = new ColumnParent("Dashboard");
SlicePredicate predicate = new SlicePredicate();
SliceRange sliceRange = new SliceRange();
sliceRange.setCount(Integer.MAX_VALUE);
sliceRange.setStart(toRawValue(""));
sliceRange.setFinish(toRawValue(""));
predicate.setSlice_range(sliceRange);
// timing this takes 6-8 secs.
return client.get_slice(
"keyspace",
"theusername",
columnParent,
slicePredicate,
ConsistencyLevel.QUORUM
);
My replication factor is 1 and I had two nodes setup in cluster when doing the reads.
Shouldn't this be what cassandra can do dead-fast?
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Mike Malone <mi...@simplegeo.com>.
> > Yes, I know. And I might end up doing this in the end. I do though have
> pretty hard upper limits of how many rows I will end up with for each key,
> but anyways it might be a good idea none the less. Thanks for the advice on
> that one.
>
> You set count to Integer.MAX. Did you try with say 30000? IIRC that
> makes a difference (while it shouldn't) even when you have still less
> than 30000.
>
Er, really? Just off hand, I feel like I've looked through most of the code
that would be relevant and I can't think of any reason that would be the
case. If it is, that definitely seems like a bug, particularly since the
general strategy for fetching "all the things in this row" is to set count
to Integer.MAX_VALUE!
Mike
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Torsten Curdt <tc...@vafer.org>.
> Yes, I know. And I might end up doing this in the end. I do though have pretty hard upper limits of how many rows I will end up with for each key, but anyways it might be a good idea none the less. Thanks for the advice on that one.
You set count to Integer.MAX. Did you try with say 30000? IIRC that
makes a difference (while it shouldn't) even when you have still less
than 30000.
Paging is the way to go.
cheers
--
Torsten
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Per Olesen <po...@trifork.com>.
On Jun 4, 2010, at 5:19 PM, Ben Browning wrote:
> How many subcolumns are in each supercolumn and how large are the
> values? Your example shows 8 subcolumns, but I didn't know if that was
> the actual number. I've been able to read columns out of Cassandra at
> an order of magnitude higher than what you're seeing here but there
> are too many variables to directly compare.
There are very few columns for each SC. About 8, but it varies a bit. The column names and values are pretty small. around 20-30 bytes for each column, I guess. So, we are talking small amounts of data here.
Yes, I know there are too many variables, but I have the feeling - as you also write - that the performance of this simple thing should be orders of magnitude better.
So, how might I go about trying to find out why this takes so long time in my specific setup? Can I get timings of stuff inside cassandra itself?
> Keep in mind that the results from each thrift call has to fit into
> memory - you might be better off paging through the 23000 columns,
> reading a few thousand at a time.
Yes, I know. And I might end up doing this in the end. I do though have pretty hard upper limits of how many rows I will end up with for each key, but anyways it might be a good idea none the less. Thanks for the advice on that one.
Per
SV: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Per Olesen <po...@trifork.com>.
> Ben Browning wrote...
>
>[snip/]
>...
>.... I've been able to read columns out of Cassandra at
>an order of magnitude higher than what you're seeing here but there
>are too many variables to directly compare.
I've been reading with ConsistencyLevel QUORUM in my timings.
If I change to ConsistencyLevel ONE, I get around 4-5x better read performance. But I guess that was to be expected, right.
Hmm.
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Ben Browning <be...@gmail.com>.
How many subcolumns are in each supercolumn and how large are the
values? Your example shows 8 subcolumns, but I didn't know if that was
the actual number. I've been able to read columns out of Cassandra at
an order of magnitude higher than what you're seeing here but there
are too many variables to directly compare.
Keep in mind that the results from each thrift call has to fit into
memory - you might be better off paging through the 23000 columns,
reading a few thousand at a time.
Ben
On Fri, Jun 4, 2010 at 11:01 AM, Per Olesen <po...@trifork.com> wrote:
> On Jun 4, 2010, at 4:46 PM, Jonathan Ellis wrote:
>
>> get_slice reads a single row. do you mean there are 23,000 columns,
>> or are you running get_slice in a loop 23000 times?
>
> Hi Jonathan, thanks for answering!
>
> No, I do only one get_slice call.
>
> There are 23.000 SUPER columns, which I read using get_slice with ColumnParent parameter set to only CF name (Dashboard) and a SlicePredicate, that has "" for begin on super column name and "" for end on super column name.
>
> So, I do one single get_slice to get all the super-columns. This is the thrift call, that takes approx. 6-8 secs.
>
> I then iterate over this after the call, to extract columns for each super-column, but that is not in my timings and it also performs no thrift calls.
>
> Like this:
>
>>> ColumnParent parent = new ColumnParent("Dashboard");
>>>
>>> SlicePredicate predicate = new SlicePredicate();
>>> SliceRange sliceRange = new SliceRange();
>>> sliceRange.setCount(Integer.MAX_VALUE);
>>> sliceRange.setStart(toRawValue(""));
>>> sliceRange.setFinish(toRawValue(""));
>>> predicate.setSlice_range(sliceRange);
>>>
>>> // timing this takes 6-8 secs.
>>> return client.get_slice(
>>> "keyspace",
>>> "theusername",
>>> columnParent,
>>> slicePredicate,
>>> ConsistencyLevel.QUORUM
>>> );
>
>
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Per Olesen <po...@trifork.com>.
On Jun 4, 2010, at 4:46 PM, Jonathan Ellis wrote:
> get_slice reads a single row. do you mean there are 23,000 columns,
> or are you running get_slice in a loop 23000 times?
Hi Jonathan, thanks for answering!
No, I do only one get_slice call.
There are 23.000 SUPER columns, which I read using get_slice with ColumnParent parameter set to only CF name (Dashboard) and a SlicePredicate, that has "" for begin on super column name and "" for end on super column name.
So, I do one single get_slice to get all the super-columns. This is the thrift call, that takes approx. 6-8 secs.
I then iterate over this after the call, to extract columns for each super-column, but that is not in my timings and it also performs no thrift calls.
Like this:
>> ColumnParent parent = new ColumnParent("Dashboard");
>>
>> SlicePredicate predicate = new SlicePredicate();
>> SliceRange sliceRange = new SliceRange();
>> sliceRange.setCount(Integer.MAX_VALUE);
>> sliceRange.setStart(toRawValue(""));
>> sliceRange.setFinish(toRawValue(""));
>> predicate.setSlice_range(sliceRange);
>>
>> // timing this takes 6-8 secs.
>> return client.get_slice(
>> "keyspace",
>> "theusername",
>> columnParent,
>> slicePredicate,
>> ConsistencyLevel.QUORUM
>> );
Re: Are 6..8 seconds to read 23.000 small rows - as it should be?
Posted by Jonathan Ellis <jb...@gmail.com>.
get_slice reads a single row. do you mean there are 23,000 columns,
or are you running get_slice in a loop 23000 times?
On Fri, Jun 4, 2010 at 4:59 AM, Per Olesen <po...@trifork.com> wrote:
> Are 6..8 seconds to read 23.000 small rows - as it should be?
>
> I have a quick question on what I think is bad read performance for this simple setup:
>
> <ColumnFamily Name="Dashboard"
> ColumnType="Super"
> CompareWith="UTF8Type"
> CompareSubcolumnsWith="UTF8Type" />
>
> SCF:Dashboard
> key:username1 -> {
> SC:uniqStr1 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr2 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr3 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr4 -> { col1:val1, col2: val2, ... col8:val8 },
> ... up to 23.000 "rows"
> key:username2 -> {
> SC:uniqStr5 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr6 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr7 -> { col1:val1, col2: val2, ... col8:val8 },
> SC:uniqStr8 -> { col1:val1, col2: val2, ... col8:val8 },
> ...
>
> A given key "username1" has e.g. 23.000 super column unique (rows). When I try and simply raw-read all these rows, it takes what I think isn't pretty fast - approximately 6-8 seconds. I know, there are a millions things that affect this, but I would just like to have a yes or no if this really can be as it should be?
>
> My cassandra is a pretty unchanged v0.6.1.
>
> I read using this code:
>
> ColumnParent parent = new ColumnParent("Dashboard");
>
> SlicePredicate predicate = new SlicePredicate();
> SliceRange sliceRange = new SliceRange();
> sliceRange.setCount(Integer.MAX_VALUE);
> sliceRange.setStart(toRawValue(""));
> sliceRange.setFinish(toRawValue(""));
> predicate.setSlice_range(sliceRange);
>
> // timing this takes 6-8 secs.
> return client.get_slice(
> "keyspace",
> "theusername",
> columnParent,
> slicePredicate,
> ConsistencyLevel.QUORUM
> );
>
> My replication factor is 1 and I had two nodes setup in cluster when doing the reads.
>
> Shouldn't this be what cassandra can do dead-fast?
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com