Stop writes to a cassandra node for maintenance purpose & enable them after some time

[Akshit Jain]

Hi,
I want to stop writes to a cassandra node for some time and then start
them.Is there any way to do that?
Regards

Re: No columns are defined for Materialized View other than primary key

[kurt greaves]

https://issues.apache.org/jira/browse/CASSANDRA-13857 for anyone
interested. Appreciate a sanity check on the logic if anyone gets the
chance.

On 8 September 2017 at 02:14, kurt greaves  wrote:

> Looks like there are a couple of oversights w.r.t what we allow in the
> view statement here. I'm creating a JIRA and will link it here shortly as
> soon as I've fleshed out all the details.​
>

Re: No columns are defined for Materialized View other than primary key

[kurt greaves]

Looks like there are a couple of oversights w.r.t what we allow in the view
statement here. I'm creating a JIRA and will link it here shortly as soon
as I've fleshed out all the details.​

Re: Cassandra 3.11 is compacting forever

[kurt greaves]

Might be worth turning on debug logging for that node and when the
compaction kicks off and CPU skyrockets send through the logs.​

Re: No columns are defined for Materialized View other than primary key

[kurt greaves]

He wants the same primary key, but just wants to filter on site_id = 1 at
view creation time. seems like a valid and reasonable use case to me, but I
would say this case was overlooked when setting the PK restrictions.

RE: Manual repair not showing in the log.

[Mark Furlong]

Yes, I have one validation task in my compactionstats.

Thanks
Mark
801-705-7115 office

From: Carlos Rolo [mailto:r...@pythian.com]
Sent: Thursday, September 7, 2017 2:06 PM
To: user@cassandra.apache.org
Subject: Re: Manual repair not showing in the log.

Can you check if you have any validation compaction running in nodetool 
compactionstats?

On 7 Sep 2017 7:56 pm, "Mark Furlong" 
> wrote:
I have started a repair and I received the message ‘Starting repair command #1, 
repairing 25301 ranges for keyspace x (parallelism=PARALLEL, full=true). When I 
look in the log for antientropy repairs I do not see anything for this 
keyspace. Expecting to see messages for the merkle trees on each column family 
in the keyspace… nothing.

The repair appears to not be doing anything, what is it stuck on?


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]






--

Re: Manual repair not showing in the log.

[Carlos Rolo]

Can you check if you have any validation compaction running in nodetool
compactionstats?

On 7 Sep 2017 7:56 pm, "Mark Furlong"  wrote:

I have started a repair and I received the message ‘Starting repair command
#1, repairing 25301 ranges for keyspace x (parallelism=PARALLEL,
full=true). When I look in the log for antientropy repairs I do not see
anything for this keyspace. Expecting to see messages for the merkle trees
on each column family in the keyspace… nothing.



The repair appears to not be doing anything, what is it stuck on?





*Mark Furlong*

Sr. Database Administrator

*mfurl...@ancestry.com *
M: 801-859-7427

O: 801-705-7115

1300 W Traverse Pkwy


Lehi, UT 84043






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

-- 


--

Manual repair not showing in the log.

[Mark Furlong]

I have started a repair and I received the message ‘Starting repair command #1, 
repairing 25301 ranges for keyspace x (parallelism=PARALLEL, full=true). When I 
look in the log for antientropy repairs I do not see anything for this 
keyspace. Expecting to see messages for the merkle trees on each column family 
in the keyspace… nothing.

The repair appears to not be doing anything, what is it stuck on?


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]

Re: Cassandra compatibility matrix

[Jon Haddad]

There aren’t any drivers maintained by the Cassandra project.  Compatibility is 
up to each driver.  Usually a section is included in the README.  For instance, 
in the DataStax Java Driver: 
https://github.com/datastax/java-driver#compatibility 


Jon

> On Sep 7, 2017, at 9:39 AM, Dmitry Buzolin  wrote:
> 
> Hello list!
> 
> Where can I find C* compatibility matrix for example server server version is 
> compatible with what client drivers? Thank you!
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
> 

Cassandra compatibility matrix

[Dmitry Buzolin]

Hello list!

Where can I find C* compatibility matrix for example server server version is 
compatible with what client drivers? Thank you!
-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Re: No columns are defined for Materialized View other than primary key

[Alex Kotelnikov]

Clearly, since MV is smaller it can explain, why scanning through it is
faster.

By full scan I mean issuing series of requests like this

SELECT token(site_id,user_id), user_id, data FROM :table WHERE
token(site_id, user_id) >= :start AND token(site_id, user_id) <= :stop

where (start,stop) pairs span [-2^63, 2:63-1[

When preforming it on table I add " AND site_id = :site_id"

On 7 September 2017 at 18:46, DuyHai Doan  wrote:

> "As I described, non-filtered full scans on MV are more efficient than
> filtered full scans on a table"
>
> --> But if your MV has the same primary key as your view, how can it be
> possible ?
>
> Can you elaborate on what you mean by "non filtered full scan on MV" ?
> Please give us some sample SELECT queries
>
> On Thu, Sep 7, 2017 at 5:11 PM, Alex Kotelnikov <
> alex.kotelni...@diginetica.com> wrote:
>
>> In this example all tables and materialized views share all columns. What
>> is the question?
>>
>> On 7 September 2017 at 17:26, sha p  wrote:
>>
>>> There is one more column "data" here in MView?
>>>
>>> On 7 Sep 2017 7:49 p.m., "DuyHai Doan"  wrote:
>>>
 The answer of your question is in the error message. For once it's very
 clear. The primary key of your materialized view is EXACTLY the same as for
 your base table.

 So the question is what's the point creating this materialized view ...



 On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
 alex.kotelni...@diginetica.com> wrote:

> Hey. I have a problem creating a materialized view.
>
> My case is quite similar to
> https://issues.apache.org/jira/browse/CASSANDRA-13564
> but discussion in comments there faded, let me describe by case.
>
> I have a table like
> CREATE TABLE users (
>   site_id int,
>   user_id text,
>   n int,
>   data set,
>   PRIMARY KEY ((site_id, user_id), n));
>
> user data is updated and read by PK and sometimes I have to fetch all
> user for some specific site_id. It appeared that full scan by
> token(site_id,user_id) filtered by WHERE site_id =  works much
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
>
> yes, you have to do so for each site_id, but it makes such bulk
> fetches much faster. (When I do so, I am always puzzled, why I have to put
> NOT NULL for a part of a primary key).
> And just in case, I tried secondary indices on site_id. For such use
> they improve nothing.
>
>
> But things are changing and we realized that we want to get rid of
> clustering key, n.
>
> DROP MATERIALIZED VIEW users_1;
> DROP TABLE users;
>
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
>
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL
> PRIMARY KEY ((site_id, user_id));
>
> And here I get the error I listed in the subject.
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="No columns are defined for Materialized View other than primary
> key"
>
> But why? I still expect scans to be faster with MV. It appears to be
> possible to create a dummy column and using as a clustering key. That's
> ugly.
> --
>
> Best Regards,
>
>
> *Alexander Kotelnikov*
>
> *Team Lead*
>
> DIGINETICA
> Retail Technology Company
>
> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>
> *www.diginetica.com *
>


>>
>>
>> --
>>
>> Best Regards,
>>
>>
>> *Alexander Kotelnikov*
>>
>> *Team Lead*
>>
>> DIGINETICA
>> Retail Technology Company
>>
>> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>>
>> *www.diginetica.com *
>>
>
>


-- 

Best Regards,


*Alexander Kotelnikov*

*Team Lead*

DIGINETICA
Retail Technology Company

m: +7.921.915.06.28

*www.diginetica.com *

Re: No columns are defined for Materialized View other than primary key

[DuyHai Doan]

"As I described, non-filtered full scans on MV are more efficient than
filtered full scans on a table"

--> But if your MV has the same primary key as your view, how can it be
possible ?

Can you elaborate on what you mean by "non filtered full scan on MV" ?
Please give us some sample SELECT queries

On Thu, Sep 7, 2017 at 5:11 PM, Alex Kotelnikov <
alex.kotelni...@diginetica.com> wrote:

> In this example all tables and materialized views share all columns. What
> is the question?
>
> On 7 September 2017 at 17:26, sha p  wrote:
>
>> There is one more column "data" here in MView?
>>
>> On 7 Sep 2017 7:49 p.m., "DuyHai Doan"  wrote:
>>
>>> The answer of your question is in the error message. For once it's very
>>> clear. The primary key of your materialized view is EXACTLY the same as for
>>> your base table.
>>>
>>> So the question is what's the point creating this materialized view ...
>>>
>>>
>>>
>>> On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
>>> alex.kotelni...@diginetica.com> wrote:
>>>
 Hey. I have a problem creating a materialized view.

 My case is quite similar to
 https://issues.apache.org/jira/browse/CASSANDRA-13564
 but discussion in comments there faded, let me describe by case.

 I have a table like
 CREATE TABLE users (
   site_id int,
   user_id text,
   n int,
   data set,
   PRIMARY KEY ((site_id, user_id), n));

 user data is updated and read by PK and sometimes I have to fetch all
 user for some specific site_id. It appeared that full scan by
 token(site_id,user_id) filtered by WHERE site_id =  works much
 slower than unfiltered full scan on
 CREATE MATERIALIZED VIEW users_1 AS
 SELECT site_id, user_id, n, data
 FROM users
 WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
 PRIMARY KEY ((site_id, user_id), n);

 yes, you have to do so for each site_id, but it makes such bulk fetches
 much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
 for a part of a primary key).
 And just in case, I tried secondary indices on site_id. For such use
 they improve nothing.


 But things are changing and we realized that we want to get rid of
 clustering key, n.

 DROP MATERIALIZED VIEW users_1;
 DROP TABLE users;

 CREATE TABLE users (
 site_id int,
 user_id text,
 data set,
 PRIMARY KEY ((site_id, user_id)));

 CREATE MATERIALIZED VIEW users_1 AS
 SELECT site_id, user_id, data
 FROM users
 WHERE site_id = 1 AND user_id IS NOT NULL
 PRIMARY KEY ((site_id, user_id));

 And here I get the error I listed in the subject.
 InvalidRequest: Error from server: code=2200 [Invalid query]
 message="No columns are defined for Materialized View other than primary
 key"

 But why? I still expect scans to be faster with MV. It appears to be
 possible to create a dummy column and using as a clustering key. That's
 ugly.
 --

 Best Regards,


 *Alexander Kotelnikov*

 *Team Lead*

 DIGINETICA
 Retail Technology Company

 m: +7.921.915.06.28 <+7%20921%20915-06-28>

 *www.diginetica.com *

>>>
>>>
>
>
> --
>
> Best Regards,
>
>
> *Alexander Kotelnikov*
>
> *Team Lead*
>
> DIGINETICA
> Retail Technology Company
>
> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>
> *www.diginetica.com *
>

Re: No columns are defined for Materialized View other than primary key

[Alex Kotelnikov]

In this example all tables and materialized views share all columns. What
is the question?

On 7 September 2017 at 17:26, sha p  wrote:

> There is one more column "data" here in MView?
>
> On 7 Sep 2017 7:49 p.m., "DuyHai Doan"  wrote:
>
>> The answer of your question is in the error message. For once it's very
>> clear. The primary key of your materialized view is EXACTLY the same as for
>> your base table.
>>
>> So the question is what's the point creating this materialized view ...
>>
>>
>>
>> On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
>> alex.kotelni...@diginetica.com> wrote:
>>
>>> Hey. I have a problem creating a materialized view.
>>>
>>> My case is quite similar to
>>> https://issues.apache.org/jira/browse/CASSANDRA-13564
>>> but discussion in comments there faded, let me describe by case.
>>>
>>> I have a table like
>>> CREATE TABLE users (
>>>   site_id int,
>>>   user_id text,
>>>   n int,
>>>   data set,
>>>   PRIMARY KEY ((site_id, user_id), n));
>>>
>>> user data is updated and read by PK and sometimes I have to fetch all
>>> user for some specific site_id. It appeared that full scan by
>>> token(site_id,user_id) filtered by WHERE site_id =  works much
>>> slower than unfiltered full scan on
>>> CREATE MATERIALIZED VIEW users_1 AS
>>> SELECT site_id, user_id, n, data
>>> FROM users
>>> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
>>> PRIMARY KEY ((site_id, user_id), n);
>>>
>>> yes, you have to do so for each site_id, but it makes such bulk fetches
>>> much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
>>> for a part of a primary key).
>>> And just in case, I tried secondary indices on site_id. For such use
>>> they improve nothing.
>>>
>>>
>>> But things are changing and we realized that we want to get rid of
>>> clustering key, n.
>>>
>>> DROP MATERIALIZED VIEW users_1;
>>> DROP TABLE users;
>>>
>>> CREATE TABLE users (
>>> site_id int,
>>> user_id text,
>>> data set,
>>> PRIMARY KEY ((site_id, user_id)));
>>>
>>> CREATE MATERIALIZED VIEW users_1 AS
>>> SELECT site_id, user_id, data
>>> FROM users
>>> WHERE site_id = 1 AND user_id IS NOT NULL
>>> PRIMARY KEY ((site_id, user_id));
>>>
>>> And here I get the error I listed in the subject.
>>> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
>>> columns are defined for Materialized View other than primary key"
>>>
>>> But why? I still expect scans to be faster with MV. It appears to be
>>> possible to create a dummy column and using as a clustering key. That's
>>> ugly.
>>> --
>>>
>>> Best Regards,
>>>
>>>
>>> *Alexander Kotelnikov*
>>>
>>> *Team Lead*
>>>
>>> DIGINETICA
>>> Retail Technology Company
>>>
>>> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>>>
>>> *www.diginetica.com *
>>>
>>
>>


-- 

Best Regards,


*Alexander Kotelnikov*

*Team Lead*

DIGINETICA
Retail Technology Company

m: +7.921.915.06.28

*www.diginetica.com *

Re: No columns are defined for Materialized View other than primary key

[Alex Kotelnikov]

As I described, non-filtered full scans on MV are more efficient than
filtered full scans on a table.

On 7 September 2017 at 17:19, DuyHai Doan  wrote:

> The answer of your question is in the error message. For once it's very
> clear. The primary key of your materialized view is EXACTLY the same as for
> your base table.
>
> So the question is what's the point creating this materialized view ...
>
>
>
> On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
> alex.kotelni...@diginetica.com> wrote:
>
>> Hey. I have a problem creating a materialized view.
>>
>> My case is quite similar to
>> https://issues.apache.org/jira/browse/CASSANDRA-13564
>> but discussion in comments there faded, let me describe by case.
>>
>> I have a table like
>> CREATE TABLE users (
>>   site_id int,
>>   user_id text,
>>   n int,
>>   data set,
>>   PRIMARY KEY ((site_id, user_id), n));
>>
>> user data is updated and read by PK and sometimes I have to fetch all
>> user for some specific site_id. It appeared that full scan by
>> token(site_id,user_id) filtered by WHERE site_id =  works much
>> slower than unfiltered full scan on
>> CREATE MATERIALIZED VIEW users_1 AS
>> SELECT site_id, user_id, n, data
>> FROM users
>> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
>> PRIMARY KEY ((site_id, user_id), n);
>>
>> yes, you have to do so for each site_id, but it makes such bulk fetches
>> much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
>> for a part of a primary key).
>> And just in case, I tried secondary indices on site_id. For such use they
>> improve nothing.
>>
>>
>> But things are changing and we realized that we want to get rid of
>> clustering key, n.
>>
>> DROP MATERIALIZED VIEW users_1;
>> DROP TABLE users;
>>
>> CREATE TABLE users (
>> site_id int,
>> user_id text,
>> data set,
>> PRIMARY KEY ((site_id, user_id)));
>>
>> CREATE MATERIALIZED VIEW users_1 AS
>> SELECT site_id, user_id, data
>> FROM users
>> WHERE site_id = 1 AND user_id IS NOT NULL
>> PRIMARY KEY ((site_id, user_id));
>>
>> And here I get the error I listed in the subject.
>> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
>> columns are defined for Materialized View other than primary key"
>>
>> But why? I still expect scans to be faster with MV. It appears to be
>> possible to create a dummy column and using as a clustering key. That's
>> ugly.
>> --
>>
>> Best Regards,
>>
>>
>> *Alexander Kotelnikov*
>>
>> *Team Lead*
>>
>> DIGINETICA
>> Retail Technology Company
>>
>> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>>
>> *www.diginetica.com *
>>
>
>


-- 

Best Regards,


*Alexander Kotelnikov*

*Team Lead*

DIGINETICA
Retail Technology Company

m: +7.921.915.06.28

*www.diginetica.com *

Re: No columns are defined for Materialized View other than primary key

[sha p]

There is one more column "data" here in MView?

On 7 Sep 2017 7:49 p.m., "DuyHai Doan"  wrote:

> The answer of your question is in the error message. For once it's very
> clear. The primary key of your materialized view is EXACTLY the same as for
> your base table.
>
> So the question is what's the point creating this materialized view ...
>
>
>
> On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
> alex.kotelni...@diginetica.com> wrote:
>
>> Hey. I have a problem creating a materialized view.
>>
>> My case is quite similar to
>> https://issues.apache.org/jira/browse/CASSANDRA-13564
>> but discussion in comments there faded, let me describe by case.
>>
>> I have a table like
>> CREATE TABLE users (
>>   site_id int,
>>   user_id text,
>>   n int,
>>   data set,
>>   PRIMARY KEY ((site_id, user_id), n));
>>
>> user data is updated and read by PK and sometimes I have to fetch all
>> user for some specific site_id. It appeared that full scan by
>> token(site_id,user_id) filtered by WHERE site_id =  works much
>> slower than unfiltered full scan on
>> CREATE MATERIALIZED VIEW users_1 AS
>> SELECT site_id, user_id, n, data
>> FROM users
>> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
>> PRIMARY KEY ((site_id, user_id), n);
>>
>> yes, you have to do so for each site_id, but it makes such bulk fetches
>> much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
>> for a part of a primary key).
>> And just in case, I tried secondary indices on site_id. For such use they
>> improve nothing.
>>
>>
>> But things are changing and we realized that we want to get rid of
>> clustering key, n.
>>
>> DROP MATERIALIZED VIEW users_1;
>> DROP TABLE users;
>>
>> CREATE TABLE users (
>> site_id int,
>> user_id text,
>> data set,
>> PRIMARY KEY ((site_id, user_id)));
>>
>> CREATE MATERIALIZED VIEW users_1 AS
>> SELECT site_id, user_id, data
>> FROM users
>> WHERE site_id = 1 AND user_id IS NOT NULL
>> PRIMARY KEY ((site_id, user_id));
>>
>> And here I get the error I listed in the subject.
>> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
>> columns are defined for Materialized View other than primary key"
>>
>> But why? I still expect scans to be faster with MV. It appears to be
>> possible to create a dummy column and using as a clustering key. That's
>> ugly.
>> --
>>
>> Best Regards,
>>
>>
>> *Alexander Kotelnikov*
>>
>> *Team Lead*
>>
>> DIGINETICA
>> Retail Technology Company
>>
>> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>>
>> *www.diginetica.com *
>>
>
>

Re: No columns are defined for Materialized View other than primary key

[DuyHai Doan]

The answer of your question is in the error message. For once it's very
clear. The primary key of your materialized view is EXACTLY the same as for
your base table.

So the question is what's the point creating this materialized view ...



On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <
alex.kotelni...@diginetica.com> wrote:

> Hey. I have a problem creating a materialized view.
>
> My case is quite similar to
> https://issues.apache.org/jira/browse/CASSANDRA-13564
> but discussion in comments there faded, let me describe by case.
>
> I have a table like
> CREATE TABLE users (
>   site_id int,
>   user_id text,
>   n int,
>   data set,
>   PRIMARY KEY ((site_id, user_id), n));
>
> user data is updated and read by PK and sometimes I have to fetch all user
> for some specific site_id. It appeared that full scan by
> token(site_id,user_id) filtered by WHERE site_id =  works much
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
>
> yes, you have to do so for each site_id, but it makes such bulk fetches
> much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
> for a part of a primary key).
> And just in case, I tried secondary indices on site_id. For such use they
> improve nothing.
>
>
> But things are changing and we realized that we want to get rid of
> clustering key, n.
>
> DROP MATERIALIZED VIEW users_1;
> DROP TABLE users;
>
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
>
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL
> PRIMARY KEY ((site_id, user_id));
>
> And here I get the error I listed in the subject.
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
> columns are defined for Materialized View other than primary key"
>
> But why? I still expect scans to be faster with MV. It appears to be
> possible to create a dummy column and using as a clustering key. That's
> ugly.
> --
>
> Best Regards,
>
>
> *Alexander Kotelnikov*
>
> *Team Lead*
>
> DIGINETICA
> Retail Technology Company
>
> m: +7.921.915.06.28 <+7%20921%20915-06-28>
>
> *www.diginetica.com *
>

No columns are defined for Materialized View other than primary key

[Alex Kotelnikov]

Hey. I have a problem creating a materialized view.

My case is quite similar to
https://issues.apache.org/jira/browse/CASSANDRA-13564
but discussion in comments there faded, let me describe by case.

I have a table like
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user
for some specific site_id. It appeared that full scan by
token(site_id,user_id) filtered by WHERE site_id =  works much
slower than unfiltered full scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);

yes, you have to do so for each site_id, but it makes such bulk fetches
much faster. (When I do so, I am always puzzled, why I have to put NOT NULL
for a part of a primary key).
And just in case, I tried secondary indices on site_id. For such use they
improve nothing.


But things are changing and we realized that we want to get rid of
clustering key, n.

DROP MATERIALIZED VIEW users_1;
DROP TABLE users;

CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL
PRIMARY KEY ((site_id, user_id));

And here I get the error I listed in the subject.
InvalidRequest: Error from server: code=2200 [Invalid query] message="No
columns are defined for Materialized View other than primary key"

But why? I still expect scans to be faster with MV. It appears to be
possible to create a dummy column and using as a clustering key. That's
ugly.
-- 

Best Regards,


*Alexander Kotelnikov*

*Team Lead*

DIGINETICA
Retail Technology Company

m: +7.921.915.06.28

*www.diginetica.com *

Re: truncate table in C* 3.11.0

[Cogumelos Maravilha]

Now it's working but nothing changed!

In the first attempt (I've tried more that 6 times) that I've reported
all the nodes were up, snapshot is disable, and I didn't check the
sstables files.

All the nodes are up and working hard, another table with 15M
inserts/hour and 12k/h queries plus the normal maintenances tasks.

Thanks

On 07-09-2017 11:16, Carlos Rolo wrote:
> If you waited less than 60s, no warning/error was issued. Do the
> following:
>
> * Check if all nodes are up (truncate fails if not)
> * Check if you got a snapshot generated (unless you have auto_snapshot
> disabled)
> * Check if you have still the sstables in the directories (you shouldn't)
>
> If it didn't happen, open a ticket.
>
> Tested right now on a 3 nodes 3.11.0 cluster and it worked fine. So if
> you can trace the query to provide additional detail, it would help.
>
>
>
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>  
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
> _linkedin.com/in/carlosjuzarterolo
> _
> Mobile: +351 918 918 100
> www.pythian.com 
>
> On Thu, Sep 7, 2017 at 10:07 AM, Cogumelos Maravilha
> > wrote:
>
> Hi list,
>
> Using cqlsh:
>
> consistency all;
>
> select count(*) table1;
>
> 219871
>
> truncate table1;
>
> select count(*) table1;
>
> 219947
>
>
> There is a consumer reading data from kafka and inserting in C*
> but the
> rate is around 50 inserts/minute.
>
>
> Cheers
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> 
> For additional commands, e-mail: user-h...@cassandra.apache.org
> 
>
>
>
> --
>
>
>

Re: truncate table in C* 3.11.0

[Carlos Rolo]

If you waited less than 60s, no warning/error was issued. Do the following:

* Check if all nodes are up (truncate fails if not)
* Check if you got a snapshot generated (unless you have auto_snapshot
disabled)
* Check if you have still the sstables in the directories (you shouldn't)

If it didn't happen, open a ticket.

Tested right now on a 3 nodes 3.11.0 cluster and it worked fine. So if you
can trace the query to provide additional detail, it would help.




Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
*linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 918 918 100
www.pythian.com

On Thu, Sep 7, 2017 at 10:07 AM, Cogumelos Maravilha <
cogumelosmaravi...@sapo.pt> wrote:

> Hi list,
>
> Using cqlsh:
>
> consistency all;
>
> select count(*) table1;
>
> 219871
>
> truncate table1;
>
> select count(*) table1;
>
> 219947
>
>
> There is a consumer reading data from kafka and inserting in C* but the
> rate is around 50 inserts/minute.
>
>
> Cheers
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>

-- 


--

truncate table in C* 3.11.0

[Cogumelos Maravilha]

Hi list,

Using cqlsh:

consistency all;

select count(*) table1;

219871

truncate table1;

select count(*) table1;

219947


There is a consumer reading data from kafka and inserting in C* but the
rate is around 50 inserts/minute.


Cheers



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