cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ZhaoYang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11031) MultiTenant : support “ALLOW FILTERING" for First Partition Key
Date Thu, 05 May 2016 10:17:12 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270470#comment-15270470
] 

ZhaoYang edited comment on CASSANDRA-11031 at 5/5/16 10:16 AM:
---------------------------------------------------------------

[~slebresne] Thank you.  I think the performance will be better than `allow filtering on clustering
key`, is it?

> we can support allow filtering on Partition Key, as far as I know, Partition Key is in
memory.

I think I was wrong about the implementation. I thought that all partition key are in offheap
memory and c* could it before fetching columns.

> as this is a new feature and a pretty minor one imo for the reason discussed above, it
should really only go to trunk at this point. This will change the patch substantially.

 I will make PR based on 3.x

> even if we support filtering on missing partition key, I really don't see a reason to
special case it only for the first one. The code should be more generic than this.

How about only equal condition?

> we'd obviously need the patch to have some testing coverage to consider it.

sure. dtest: https://github.com/riptano/cassandra-dtest/pull/969/files




was (Author: jasonstack):
[~slebresne] Thank you.  I think the performance will be better than `allow filtering on clustering
key`, is it?

> we can support allow filtering on Partition Key, as far as I know, Partition Key is in
memory.

I think I was wrong about the implementation. I thought that all partition key are in offheap
memory and c* could it before fetching columns.

> as this is a new feature and a pretty minor one imo for the reason discussed above, it
should really only go to trunk at this point. This will change the patch substantially.

 I will make PR based on 3.x

> even if we support filtering on missing partition key, I really don't see a reason to
special case it only for the first one. The code should be more generic than this.

How about only equal condition?

> we'd obviously need the patch to have some testing coverage to consider it.

sure. I will add to c*-dtest?



> MultiTenant : support “ALLOW FILTERING" for First Partition Key
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-11031
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11031
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: ZhaoYang
>            Assignee: ZhaoYang
>            Priority: Minor
>             Fix For: 3.x
>
>         Attachments: CASSANDRA-11031-3.7
>
>
> Currently, Allow Filtering only works for secondary Index column or clustering columns.
And it's slow, because Cassandra will read all data from SSTABLE from hard-disk to memory
to filter.
> But we can support allow filtering on Partition Key, as far as I know, Partition Key
is in memory, so we can easily filter them, and then read required data from SSTable.
> This will similar to "Select * from table" which scan through entire cluster.
> CREATE TABLE multi_tenant_table (
> 	tenant_id text,
> 	pk2 text,
> 	c1 text,
> 	c2 text,
> 	v1 text,
> 	v2 text,
> 	PRIMARY KEY ((tenant_id,pk2),c1,c2)
> ) ;
> Select * from multi_tenant_table where tenant_id = "datastax" allow filtering;



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message