cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11031) MultiTenant : support “ALLOW FILTERING" for Partition Key
Date Fri, 15 Jul 2016 09:06:20 GMT

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

Alex Petrov edited comment on CASSANDRA-11031 at 7/15/16 9:05 AM:
------------------------------------------------------------------

Thank you for your patch [~jasonstack]. Sorry it took so long to review it. I'll do my best
to keep all the future iterations as short as possible.

>From the first glance, there are many cases that are missing. For example, filtering by
anything but {{=}} wouldn't work.

{code}
createTable("CREATE TABLE %s (a text, b int, v int, PRIMARY KEY ((a, b))) ");

            execute("INSERT INTO %s (a, b, v) VALUES ('a', 2, 1)");
            execute("INSERT INTO %s (a, b, v) VALUES ('a', 3, 1)");
            assertRows(execute("SELECT * FROM %s WHERE a = 'a' AND b > 0 ALLOW FILTERING"),
                       row("a", 2, 1),
                       row("a", 3, 1));
{code}

Would throw 

{code}
org.apache.cassandra.exceptions.InvalidRequestException: Only EQ and IN relation are supported
on the partition key (unless you use the token() function)
{code}

I would start with the unit test, to be honest. Although dtests are also important. Paging
tests might be also good. 

Could you please check out: 
  * combinations of partition and clustering key filtering 
  * compound partition keys and their filtering 
  * non-EQ relations ({{LT}}, {{GT}} etc)
  * {{COMPACT STORAGE}} 
  * collections ({{CONTAINS}} and {{CONTAINS KEY}})
  * different ordering
  * compatibility with 2i

You can take some inspiration for tests from [CASSANDRA-11310] [here|https://github.com/apache/cassandra/commit/a600920cb5ee2866b09ee6c1ebae9518096e5bc4]



was (Author: ifesdjeen):
Thank you for your patch [~jasonstack]. Sorry it took so long to review it. I'll do my best
to keep all the future iterations as short as possible.

>From the first glance, there are many cases that are missing. For example, filtering by
anything but {{=}} wouldn't work.

{code}
createTable("CREATE TABLE %s (a text, b int, v int, PRIMARY KEY ((a, b))) ");

            execute("INSERT INTO %s (a, b, v) VALUES ('a', 2, 1)");
            execute("INSERT INTO %s (a, b, v) VALUES ('a', 3, 1)");
            assertRows(execute("SELECT * FROM %s WHERE a = 'a' AND b > 0 ALLOW FILTERING"),
                       row("a", 2, 1),
                       row("a", 3, 1));
{code}

Would throw 

{code}
org.apache.cassandra.exceptions.InvalidRequestException: Only EQ and IN relation are supported
on the partition key (unless you use the token() function)
{code}

I would start with the unit test, to be honest. Although dtests are also important. Paging
tests might be also good. 

Could you please check out: 
  * combinations of partition and clustering key filtering 
  * compound partition keys and their filtering 
  * non-EQ relations ({{LT}}, {{GT}} etc)
  * {{COMPACT STORAGE}} 

You can take some inspiration for tests from [CASSANDRA-11310].


> MultiTenant : support “ALLOW FILTERING" for 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.patch
>
>
> 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