Cassandra 2.1.13: Using JOIN_RING=False

2017-05-09 Thread Anubhav Kale
Hello,

With some inspiration from the Cassandra Summit talk from last year, we are 
trying to setup a cluster with coordinator-only nodes. We setup join_ring=false 
in env.sh, disabled auth in YAML and the nodes are able to start just fine. 
However, we're running into a few problems

1] The nodes marked with join_ring=false continue to store data. Why ?
2] We tried Python driver's whitelistedpolicy. But we notice message like 
below, so we are not able to send queries to all nodes marked as coordinators. 
We also changed the Scala driver to support whitelisting, but see the same 
thing. What are we missing ?
3] Is there any way to concretely tell that only coordinator nodes are getting 
requests from clients ? We don't have OpsCenter.

Thanks !

2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: [control connection] 
Removing host not found in peers metadata: 
2017-05-09 20:45:25,060 [INFO] cassandra.cluster: Cassandra host 10.80.10.128 
removed
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: Removing host 10.80.10.128
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: [control connection] 
Removing host not found in peers metadata: 
2017-05-09 20:45:25,060 [INFO] cassandra.cluster: Cassandra host 10.80.10.127 
removed
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: Removing host 10.80.10.127
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: [control connection] 
Removing host not found in peers metadata: 
2017-05-09 20:45:25,060 [INFO] cassandra.cluster: Cassandra host 10.80.10.129 
removed
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: Removing host 10.80.10.129
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: [control connection] 
Finished fetching ring info
2017-05-09 20:45:25,060 [DEBUG] cassandra.cluster: [control connection] 
Rebuilding token map due to topology changes
2017-05-09 20:45:25,081 [DEBUG] cassandra.metadata: user functions table not 
found
2017-05-09 20:45:25,081 [DEBUG] cassandra.metadata: user aggregates table not 
found
2017-05-09 20:45:25,098 [DEBUG] cassandra.cluster: Control connection created
2017-05-09 20:45:25,099 [DEBUG] cassandra.pool: Initializing connection for 
host 10.80.10.125
2017-05-09 20:45:25,099 [DEBUG] cassandra.pool: Initializing connection for 
host 10.80.10.126



Re: Smart Table creation for 2D range query

2017-05-09 Thread Jon Haddad
Sure, I don't see why not.  Ultimately this is more or less the same thing
I proposed.   You end up with a slightly different way of encoding a point
in space into a rough geographical area.  Whether you encode them as a tree
structure or some prefix of a geohash is a matter of convenience.  I'm not
sure if there's any performance advantage to using geohashes, from a
Cassandra data model & query perspective, as I haven't spent much time with
them.  Maybe someone who's done this can chime in.

On Tue, May 9, 2017 at 1:16 PM Jim Ancona  wrote:

> Couldn't you use a bucketing strategy for the hash value, much like with
> time series data? That is, choose a partition key granularity that puts a
> reasonable number of rows in a partition, with the actual hash being the
> clustering key. Then ranges that within the partition key granularity could
> be efficiently queried.
>
> Jim
>
> On Tue, May 9, 2017 at 11:19 AM, Jon Haddad 
> wrote:
>
>> The problem with using geohashes is that you can’t efficiently do ranges
>> with random token distribution.  So even if your scalar values are close to
>> each other numerically they’ll likely end up on different nodes, and you
>> end up doing a scatter gather.
>>
>> If the goal is to provide a scalable solution, building a table that
>> functions as an R-Tree or Quad Tree is the only way I know that can solve
>> the problem without scanning the entire cluster.
>>
>> Jon
>>
>> On May 9, 2017, at 10:11 AM, Jim Ancona  wrote:
>>
>> There are clever ways to encode coordinates into a single scalar value
>> where points that are close on a surface are also close in value, making
>> queries efficient. Examples are Geohash
>>  and Google's S2
>> .
>> As Jon mentions, this puts more work on the client, but might give you a
>> lot of querying flexibility when using Cassandra.
>>
>> Jim
>>
>> On Mon, May 8, 2017 at 11:13 PM, Jon Haddad 
>> wrote:
>>
>>> It gets a little tricky when you try to add in the coordinates to the
>>> clustering key if you want to do operations that are more complex.  For
>>> instance, finding all the elements within a radius of point (x,y) isn’t
>>> particularly fun with Cassandra.  I recommend moving that logic into the
>>> application.
>>>
>>> > On May 8, 2017, at 10:06 PM, kurt greaves 
>>> wrote:
>>> >
>>> > Note that will not give you the desired range queries of 0 >= x <= 1
>>> and 0 >= y <= 1.
>>> >
>>> >
>>> > ​Something akin to Jon's solution could give you those range queries
>>> if you made the x and y components part of the clustering key.
>>> >
>>> > For example, a space of (1,1) could contain all x,y coordinates where
>>> x and y are > 0 and <= 1. You would then have a table like:
>>> >
>>> > CREATE TABLE geospatial (
>>> > space text,
>>> > x double,
>>> > y double,
>>> > item text,
>>> > m1,
>>> > m2,
>>> > m3,
>>> > primary key ((space), x, y, m1, m2, m3, m4, m5)
>>> > );
>>> >
>>> > A query of select * where space = '1,1' and x <1 and x >0.5 and y< 0.2
>>> and y>0.1; should yield all x and y pairs and their distinct metadata. Or
>>> something like that anyway.
>>> >
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>>
>>>
>>
>>
>


Re: Smart Table creation for 2D range query

2017-05-09 Thread Jim Ancona
Couldn't you use a bucketing strategy for the hash value, much like with
time series data? That is, choose a partition key granularity that puts a
reasonable number of rows in a partition, with the actual hash being the
clustering key. Then ranges that within the partition key granularity could
be efficiently queried.

Jim

On Tue, May 9, 2017 at 11:19 AM, Jon Haddad 
wrote:

> The problem with using geohashes is that you can’t efficiently do ranges
> with random token distribution.  So even if your scalar values are close to
> each other numerically they’ll likely end up on different nodes, and you
> end up doing a scatter gather.
>
> If the goal is to provide a scalable solution, building a table that
> functions as an R-Tree or Quad Tree is the only way I know that can solve
> the problem without scanning the entire cluster.
>
> Jon
>
> On May 9, 2017, at 10:11 AM, Jim Ancona  wrote:
>
> There are clever ways to encode coordinates into a single scalar value
> where points that are close on a surface are also close in value, making
> queries efficient. Examples are Geohash
>  and Google's S2
> .
> As Jon mentions, this puts more work on the client, but might give you a
> lot of querying flexibility when using Cassandra.
>
> Jim
>
> On Mon, May 8, 2017 at 11:13 PM, Jon Haddad 
> wrote:
>
>> It gets a little tricky when you try to add in the coordinates to the
>> clustering key if you want to do operations that are more complex.  For
>> instance, finding all the elements within a radius of point (x,y) isn’t
>> particularly fun with Cassandra.  I recommend moving that logic into the
>> application.
>>
>> > On May 8, 2017, at 10:06 PM, kurt greaves  wrote:
>> >
>> > Note that will not give you the desired range queries of 0 >= x <= 1
>> and 0 >= y <= 1.
>> >
>> >
>> > ​Something akin to Jon's solution could give you those range queries if
>> you made the x and y components part of the clustering key.
>> >
>> > For example, a space of (1,1) could contain all x,y coordinates where x
>> and y are > 0 and <= 1. You would then have a table like:
>> >
>> > CREATE TABLE geospatial (
>> > space text,
>> > x double,
>> > y double,
>> > item text,
>> > m1,
>> > m2,
>> > m3,
>> > primary key ((space), x, y, m1, m2, m3, m4, m5)
>> > );
>> >
>> > A query of select * where space = '1,1' and x <1 and x >0.5 and y< 0.2
>> and y>0.1; should yield all x and y pairs and their distinct metadata. Or
>> something like that anyway.
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>>
>
>


Repairs on 2.1.12

2017-05-09 Thread Mark Furlong
I have a large cluster running a -dc repair on a ring which has been running 
for nearly two weeks. When I review the logs I can see where my tables are 
reporting as ‘fully synced’ multiple times. I’m looking for some information to 
help me confirm that my repair is not looping and is running properly.

Mark Furlong

Sr. Database Administrator

mfurl...@ancestry.com
M: 801-859-7427
O: 801-705-7115
1300 W Traverse Pkwy
Lehi, UT 84043





​[http://c.mfcreative.com/mars/email/shared-icon/sig-logo.gif]





NoSE: Automated schema design for Cassandra

2017-05-09 Thread Michael Mior
Hi all,

I wanted to share a tool I've been working on that tries to help automate
the schema design process for Cassandra. The short description is that you
provide information on the kind of data you want to store and the queries
and updates you want to issue, and NoSE will perform a cost-based analysis
to suggest an optimal schema.

There's lots of room for improvement and many Cassandra features which are
not currently supported, but hopefully some in the community may still find
it useful as a starting point.

Link to more details and the source code below:

https://michael.mior.ca/projects/nose/

If you're interested in trying it out, don't hesitate to reach out and I'm
happy to help!

Cheers,
--
Michael Mior
mm...@uwaterloo.ca


Re: Smart Table creation for 2D range query

2017-05-09 Thread Jon Haddad
The problem with using geohashes is that you can’t efficiently do ranges with 
random token distribution.  So even if your scalar values are close to each 
other numerically they’ll likely end up on different nodes, and you end up 
doing a scatter gather.

If the goal is to provide a scalable solution, building a table that functions 
as an R-Tree or Quad Tree is the only way I know that can solve the problem 
without scanning the entire cluster.

Jon

> On May 9, 2017, at 10:11 AM, Jim Ancona  wrote:
> 
> There are clever ways to encode coordinates into a single scalar value where 
> points that are close on a surface are also close in value, making queries 
> efficient. Examples are Geohash  and 
> Google's S2 
> .
>  As Jon mentions, this puts more work on the client, but might give you a lot 
> of querying flexibility when using Cassandra.
> 
> Jim
> 
> On Mon, May 8, 2017 at 11:13 PM, Jon Haddad  > wrote:
> It gets a little tricky when you try to add in the coordinates to the 
> clustering key if you want to do operations that are more complex.  For 
> instance, finding all the elements within a radius of point (x,y) isn’t 
> particularly fun with Cassandra.  I recommend moving that logic into the 
> application.
> 
> > On May 8, 2017, at 10:06 PM, kurt greaves  > > wrote:
> >
> > Note that will not give you the desired range queries of 0 >= x <= 1 and 0 
> > >= y <= 1.
> >
> >
> > ​Something akin to Jon's solution could give you those range queries if you 
> > made the x and y components part of the clustering key.
> >
> > For example, a space of (1,1) could contain all x,y coordinates where x and 
> > y are > 0 and <= 1. You would then have a table like:
> >
> > CREATE TABLE geospatial (
> > space text,
> > x double,
> > y double,
> > item text,
> > m1,
> > m2,
> > m3,
> > primary key ((space), x, y, m1, m2, m3, m4, m5)
> > );
> >
> > A query of select * where space = '1,1' and x <1 and x >0.5 and y< 0.2 and 
> > y>0.1; should yield all x and y pairs and their distinct metadata. Or 
> > something like that anyway.
> >
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org 
> 
> For additional commands, e-mail: user-h...@cassandra.apache.org 
> 
> 
> 



Re: Smart Table creation for 2D range query

2017-05-09 Thread Jim Ancona
There are clever ways to encode coordinates into a single scalar value
where points that are close on a surface are also close in value, making
queries efficient. Examples are Geohash
 and Google's S2
.
As Jon mentions, this puts more work on the client, but might give you a
lot of querying flexibility when using Cassandra.

Jim

On Mon, May 8, 2017 at 11:13 PM, Jon Haddad 
wrote:

> It gets a little tricky when you try to add in the coordinates to the
> clustering key if you want to do operations that are more complex.  For
> instance, finding all the elements within a radius of point (x,y) isn’t
> particularly fun with Cassandra.  I recommend moving that logic into the
> application.
>
> > On May 8, 2017, at 10:06 PM, kurt greaves  wrote:
> >
> > Note that will not give you the desired range queries of 0 >= x <= 1 and
> 0 >= y <= 1.
> >
> >
> > ​Something akin to Jon's solution could give you those range queries if
> you made the x and y components part of the clustering key.
> >
> > For example, a space of (1,1) could contain all x,y coordinates where x
> and y are > 0 and <= 1. You would then have a table like:
> >
> > CREATE TABLE geospatial (
> > space text,
> > x double,
> > y double,
> > item text,
> > m1,
> > m2,
> > m3,
> > primary key ((space), x, y, m1, m2, m3, m4, m5)
> > );
> >
> > A query of select * where space = '1,1' and x <1 and x >0.5 and y< 0.2
> and y>0.1; should yield all x and y pairs and their distinct metadata. Or
> something like that anyway.
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>


Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Kant Kodali
Thanks a lot guys!

On Tue, May 9, 2017 at 7:32 AM, Alexander Dejanovski  wrote:

> Hi Kant,
>
> Unless you provide the full partition key, I see no way for Cassandra to
> avoid doing a full table scan.
> In order to know on which specific nodes to search (and in which sstables
> ,etc...) it needs to have a token. The token is a hash of the whole
> partition key.
> For a specific value of column "a" and different values of column "b" you
> always end up with different tokens that have no guaranty to be stored on
> the same node.
> After that, bloom filters, partition indexes, etc... require the full
> token too, so a full scan is further necessary on each node to get the
> data.
>
> TL;DR : no way to avoid a full cluster scan unless you provide the full
> partition key in your where clause.
>
> Cheers,
>
> On Tue, May 9, 2017 at 4:24 PM Jon Haddad 
> wrote:
>
>> Nope, I didn’t comment on that query.   I specifically answered your
>> question about "select * from hello where a='foo' allow filtering;”
>>
>> The query you’ve listed here looks like it would also do a full table
>> scan (again, I don’t see how it would be avoided).
>>
>> I recommend firing up a 3 node cluster using CCM, creating a key space
>> with RF=1, and seeing what it does.
>>
>> On May 9, 2017, at 9:12 AM, Kant Kodali  wrote:
>>
>> Hi,
>>
>> Are you saying The following query select max(b) from hello where a='a1'
>> allow filtering; doesn't result in a table scan? I got the result for
>> this query and yes I just tried tracing it and looks like it is indeed
>> doing a table scan on ReadStage-2 although I am not sure if I am
>> interpreting it right? Finally is there anyway to prevent table scan while
>> providing the partial partition key and get the max b ?
>>
>> 
>> ​
>>
>>
>> On Tue, May 9, 2017 at 6:33 AM, Jon Haddad 
>> wrote:
>>
>>> I don’t see any way it wouldn’t.  Have you tried tracing it?
>>>
>>> > On May 9, 2017, at 8:32 AM, Kant Kodali  wrote:
>>> >
>>> > Hi All,
>>> >
>>> > It looks like Cassandra 3.10 has partial partition key search but does
>>> it result in a table scan? for example I can have the following
>>> >
>>> > create table hello(
>>> > a text,
>>> > b int,
>>> > c text,
>>> > d text,
>>> > primary key((a,b), c)
>>> > );
>>> >
>>> > Now I can do select * from hello where a='foo' allow filtering;// This
>>> works in 3.10 but I wonder if this query results in table scan and if so is
>>> there any way to limit such that I get max b?
>>> >
>>> > Thanks!
>>>
>>>
>> --
> -
> Alexander Dejanovski
> France
> @alexanderdeja
>
> Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>


Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Alexander Dejanovski
Hi Kant,

Unless you provide the full partition key, I see no way for Cassandra to
avoid doing a full table scan.
In order to know on which specific nodes to search (and in which sstables
,etc...) it needs to have a token. The token is a hash of the whole
partition key.
For a specific value of column "a" and different values of column "b" you
always end up with different tokens that have no guaranty to be stored on
the same node.
After that, bloom filters, partition indexes, etc... require the full token
too, so a full scan is further necessary on each node to get the data.

TL;DR : no way to avoid a full cluster scan unless you provide the full
partition key in your where clause.

Cheers,

On Tue, May 9, 2017 at 4:24 PM Jon Haddad  wrote:

> Nope, I didn’t comment on that query.   I specifically answered your
> question about "select * from hello where a='foo' allow filtering;”
>
> The query you’ve listed here looks like it would also do a full table scan
> (again, I don’t see how it would be avoided).
>
> I recommend firing up a 3 node cluster using CCM, creating a key space
> with RF=1, and seeing what it does.
>
> On May 9, 2017, at 9:12 AM, Kant Kodali  wrote:
>
> Hi,
>
> Are you saying The following query select max(b) from hello where a='a1'
> allow filtering; doesn't result in a table scan? I got the result for
> this query and yes I just tried tracing it and looks like it is indeed
> doing a table scan on ReadStage-2 although I am not sure if I am
> interpreting it right? Finally is there anyway to prevent table scan while
> providing the partial partition key and get the max b ?
>
> 
> ​
>
>
> On Tue, May 9, 2017 at 6:33 AM, Jon Haddad 
> wrote:
>
>> I don’t see any way it wouldn’t.  Have you tried tracing it?
>>
>> > On May 9, 2017, at 8:32 AM, Kant Kodali  wrote:
>> >
>> > Hi All,
>> >
>> > It looks like Cassandra 3.10 has partial partition key search but does
>> it result in a table scan? for example I can have the following
>> >
>> > create table hello(
>> > a text,
>> > b int,
>> > c text,
>> > d text,
>> > primary key((a,b), c)
>> > );
>> >
>> > Now I can do select * from hello where a='foo' allow filtering;// This
>> works in 3.10 but I wonder if this query results in table scan and if so is
>> there any way to limit such that I get max b?
>> >
>> > Thanks!
>>
>>
> --
-
Alexander Dejanovski
France
@alexanderdeja

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com


Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Jon Haddad
Output from both queries, demonstrating full cluster scans:

https://gist.github.com/rustyrazorblade/c4947fc37da85bca50e08aa1ef3c7a06 


Jon

> On May 9, 2017, at 9:24 AM, Jon Haddad  wrote:
> 
> Nope, I didn’t comment on that query.   I specifically answered your question 
> about "select * from hello where a='foo' allow filtering;”
> 
> The query you’ve listed here looks like it would also do a full table scan 
> (again, I don’t see how it would be avoided).
> 
> I recommend firing up a 3 node cluster using CCM, creating a key space with 
> RF=1, and seeing what it does.  
> 
>> On May 9, 2017, at 9:12 AM, Kant Kodali > > wrote:
>> 
>> Hi,
>> 
>> Are you saying The following query select max(b) from hello where a='a1' 
>> allow filtering; doesn't result in a table scan? I got the result for this 
>> query and yes I just tried tracing it and looks like it is indeed doing a 
>> table scan on ReadStage-2 although I am not sure if I am interpreting it 
>> right? Finally is there anyway to prevent table scan while providing the 
>> partial partition key and get the max b ?
>> 
>> 
>> ​
>> 
>> 
>> On Tue, May 9, 2017 at 6:33 AM, Jon Haddad > > wrote:
>> I don’t see any way it wouldn’t.  Have you tried tracing it?
>> 
>> > On May 9, 2017, at 8:32 AM, Kant Kodali > > > wrote:
>> >
>> > Hi All,
>> >
>> > It looks like Cassandra 3.10 has partial partition key search but does it 
>> > result in a table scan? for example I can have the following
>> >
>> > create table hello(
>> > a text,
>> > b int,
>> > c text,
>> > d text,
>> > primary key((a,b), c)
>> > );
>> >
>> > Now I can do select * from hello where a='foo' allow filtering;// This 
>> > works in 3.10 but I wonder if this query results in table scan and if so 
>> > is there any way to limit such that I get max b?
>> >
>> > Thanks!
>> 
>> 
> 



Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Jon Haddad
Nope, I didn’t comment on that query.   I specifically answered your question 
about "select * from hello where a='foo' allow filtering;”

The query you’ve listed here looks like it would also do a full table scan 
(again, I don’t see how it would be avoided).

I recommend firing up a 3 node cluster using CCM, creating a key space with 
RF=1, and seeing what it does.  

> On May 9, 2017, at 9:12 AM, Kant Kodali  wrote:
> 
> Hi,
> 
> Are you saying The following query select max(b) from hello where a='a1' 
> allow filtering; doesn't result in a table scan? I got the result for this 
> query and yes I just tried tracing it and looks like it is indeed doing a 
> table scan on ReadStage-2 although I am not sure if I am interpreting it 
> right? Finally is there anyway to prevent table scan while providing the 
> partial partition key and get the max b ?
> 
> 
> ​
> 
> 
> On Tue, May 9, 2017 at 6:33 AM, Jon Haddad  > wrote:
> I don’t see any way it wouldn’t.  Have you tried tracing it?
> 
> > On May 9, 2017, at 8:32 AM, Kant Kodali  > > wrote:
> >
> > Hi All,
> >
> > It looks like Cassandra 3.10 has partial partition key search but does it 
> > result in a table scan? for example I can have the following
> >
> > create table hello(
> > a text,
> > b int,
> > c text,
> > d text,
> > primary key((a,b), c)
> > );
> >
> > Now I can do select * from hello where a='foo' allow filtering;// This 
> > works in 3.10 but I wonder if this query results in table scan and if so is 
> > there any way to limit such that I get max b?
> >
> > Thanks!
> 
> 



Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Daniel Hölbling-Inzko
If you have to allow filtering for the query to work it usually always
results in a table scan.

greetings Daniel

On Tue, 9 May 2017 at 15:33 Jon Haddad  wrote:

> I don’t see any way it wouldn’t.  Have you tried tracing it?
>
> > On May 9, 2017, at 8:32 AM, Kant Kodali  wrote:
> >
> > Hi All,
> >
> > It looks like Cassandra 3.10 has partial partition key search but does
> it result in a table scan? for example I can have the following
> >
> > create table hello(
> > a text,
> > b int,
> > c text,
> > d text,
> > primary key((a,b), c)
> > );
> >
> > Now I can do select * from hello where a='foo' allow filtering;// This
> works in 3.10 but I wonder if this query results in table scan and if so is
> there any way to limit such that I get max b?
> >
> > Thanks!
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>


Re: Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Jon Haddad
I don’t see any way it wouldn’t.  Have you tried tracing it?

> On May 9, 2017, at 8:32 AM, Kant Kodali  wrote:
> 
> Hi All,
> 
> It looks like Cassandra 3.10 has partial partition key search but does it 
> result in a table scan? for example I can have the following
> 
> create table hello(
> a text,
> b int,
> c text,
> d text,
> primary key((a,b), c)
> );
> 
> Now I can do select * from hello where a='foo' allow filtering;// This works 
> in 3.10 but I wonder if this query results in table scan and if so is there 
> any way to limit such that I get max b?
> 
> Thanks!


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org



Cassandra 3.10 has partial partition key search but does it result in a table scan?

2017-05-09 Thread Kant Kodali
Hi All,

It looks like Cassandra 3.10 has partial partition key search but does it
result in a table scan? for example I can have the following

create table hello(
a text,
b int,
c text,
d text,
primary key((a,b), c)
);

Now I can do select * from hello where a='foo' allow filtering;// This
works in 3.10 but I wonder if this query results in table scan and if so is
there any way to limit such that I get max b?

Thanks!