RE: group by select queries

2018-02-01 Thread Modha, Digant
Jira created: CASSANDRA-14209.


From: kurt greaves [mailto:k...@instaclustr.com]
Sent: Thursday, February 01, 2018 12:38 AM
To: User
Subject: Re: group by select queries

Seems problematic. Would you be able to create a JIRA ticket with the above 
information/examples?

On 30 January 2018 at 22:41, Modha, Digant 
mailto:digant.mo...@tdsecurities.com>> wrote:
It was local quorum.  There’s no difference with CONSISTENCY ALL.

Consistency level set to LOCAL_QUORUM.
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1';

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   2 | 1239.2 |0 | 
1011 |   null | 2018-01-25 17:18:07.158000+
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(2 rows)
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1' group 
by security_id;

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(1 rows)
cassandra@cqlsh> select account_id,security_id, counter, 
avg_exec_price,quantity, update_time from wp.position  where account_id = 
'user_1' group by security_id ;

account_id | security_id | counter | avg_exec_price | quantity | update_time
+-+-++--+-
 user_1 |AMZN |   2 | 1239.2 | 1011 | 2018-01-25 
17:18:07.158000+

(1 rows)
cassandra@cqlsh>  consistency all;
Consistency level set to ALL.
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1' group 
by security_id;

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(1 rows)
cassandra@cqlsh> select account_id,security_id, counter, 
avg_exec_price,quantity, update_time from wp.position  where account_id = 
'user_1' group by security_id ;

account_id | security_id | counter | avg_exec_price | quantity | update_time
+-+-++--+-
 user_1 |AMZN |   2 | 1239.2 | 1011 | 2018-01-25 
17:18:07.158000+


From: kurt greaves [mailto:k...@instaclustr.com<mailto:k...@instaclustr.com>]
Sent: Monday, January 29, 2018 11:03 PM
To: User
Subject: Re: group by select queries

What consistency were you querying at? Can you retry with CONSISTENCY ALL?

​


TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisor

RE: group by select queries

2018-01-30 Thread Modha, Digant
It was local quorum.  There’s no difference with CONSISTENCY ALL.

Consistency level set to LOCAL_QUORUM.
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1';

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   2 | 1239.2 |0 | 
1011 |   null | 2018-01-25 17:18:07.158000+
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(2 rows)
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1' group 
by security_id;

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(1 rows)
cassandra@cqlsh> select account_id,security_id, counter, 
avg_exec_price,quantity, update_time from wp.position  where account_id = 
'user_1' group by security_id ;

account_id | security_id | counter | avg_exec_price | quantity | update_time
+-+-++--+-
 user_1 |AMZN |   2 | 1239.2 | 1011 | 2018-01-25 
17:18:07.158000+

(1 rows)
cassandra@cqlsh>  consistency all;
Consistency level set to ALL.
cassandra@cqlsh> select * from wp.position  where account_id = 'user_1' group 
by security_id;

account_id | security_id | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time
+-+-++--+--++-
 user_1 |AMZN |   1 | 1239.2 |0 | 
1010 |   null | 2018-01-25 17:18:07.158000+

(1 rows)
cassandra@cqlsh> select account_id,security_id, counter, 
avg_exec_price,quantity, update_time from wp.position  where account_id = 
'user_1' group by security_id ;

account_id | security_id | counter | avg_exec_price | quantity | update_time
+-+-++--+-
 user_1 |AMZN |   2 | 1239.2 | 1011 | 2018-01-25 
17:18:07.158000+


From: kurt greaves [mailto:k...@instaclustr.com]
Sent: Monday, January 29, 2018 11:03 PM
To: User
Subject: Re: group by select queries

What consistency were you querying at? Can you retry with CONSISTENCY ALL?

​

TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


group by select queries

2018-01-25 Thread Modha, Digant
HI,



I get two different out with these 2 queries.  The only difference between the 
2 queries is that one does 'select *' and other does 'select specific fields' 
without any aggregate functions. Does group by pick any record? It seems to 
pick either the first or the last record.  I expected the result #2 not #1 
because that's the way data is ordered.  I am using Apache Cassandra 3.10.





#1

cassandra@cqlsh> select * from wp.position  where account_id = 'user_1' group 
by security_id;



account_id | security_id   | counter | avg_exec_price | pending_quantity | 
quantity | transaction_id | update_time

+---+-++--+--++-

 user_1 |  MSFT |   0 | 91 |0 | 
1000 |   null | 2018-01-25 17:17:47.158000+

 user_1 | T |   0 |   39.3 |0 | 
1000 |   null | 2018-01-25 17:17:47.158000+

 user_1 | cash_position |   0 |   1234 |0 | 
1234 |   null | 2018-01-25 16:45:51.18+



(3 rows)

#2

cassandra@cqlsh> select account_id,security_id, counter, 
avg_exec_price,quantity, update_time from wp.position  where account_id = 
'user_1' group by security_id;



account_id | security_id   | counter | avg_exec_price | quantity | update_time

+---+-++--+-

 user_1 |  MSFT |   0 | 91 | 1000 | 2018-01-25 
17:17:47.158000+

 user_1 | T |   1 |   39.2 | 1010 | 2018-01-25 
17:18:07.158000+

 user_1 | cash_position |  70 |  1 |1 | 2018-01-25 
17:17:47.158000+



(3 rows)






Table Description:

CREATE TABLE wp.position (

account_id text,

security_id text,

counter bigint,

avg_exec_price double,

pending_quantity double,

quantity double,

transaction_id uuid,

update_time timestamp,

PRIMARY KEY (account_id, security_id, counter)

) WITH CLUSTERING ORDER BY (security_id ASC, counter DESC)



--Digant

TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


RE: reiserfs - DirectoryNotEmptyException

2015-10-15 Thread Modha, Digant
It is deployed on an existing cluster but will be migrated soon to a different 
file system & Linux distribution.

-Original Message-
From: Michael Shuler [mailto:mshu...@pbandjelly.org] On Behalf Of Michael Shuler
Sent: Wednesday, October 14, 2015 6:02 PM
To: user@cassandra.apache.org
Subject: Re: reiserfs - DirectoryNotEmptyException

On 10/13/2015 01:58 PM, Modha, Digant wrote:
> I am running Cassandra 2.1.10 and noticed intermittent 
> DirectoryNotEmptyExceptions during repair.  My cassandra data drive is 
> reiserfs.

Why? I'm genuinely interested in this filesystem selection, since it is 
unmaintained, has been dropped from some mainstream linux distributions, and 
some may call it "dead". ;)

> I noticed that on reiserfs wiki site
> https://en.m.wikipedia.org/wiki/ReiserFS#Criticism, it states that 
> unlink operation is not synchronous. Is that the reason for the 
> exception below:
>
> ERROR [ValidationExecutor:137] 2015-10-13 00:46:30,759
> CassandraDaemon.java:227 - Exception in thread 
> Thread[ValidationExecutor:137,1,main]
>
> org.apache.cassandra.io.FSWriteError:
> java.nio.file.DirectoryNotEmptyException:
>
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.jav
> a:135)
>
>~[apache-cassandra-2.1.10.jar:2.1.10]
<...>

This seems like a reasonable explanation. Using a modern filesystem like
ext4 or xfs would certainly be helpful in getting you within the realm of a 
"common" hardware setup.

https://wiki.apache.org/cassandra/CassandraHardware
https://www.safaribooksonline.com/library/view/cassandra-high-performance/9781849515122/ch04s06.html

I think Al Tobey had a slide deck on filesystem tuning for C*, but I didn't 
find it quickly.

--
Kind regards,
Michael


TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


reiserfs - DirectoryNotEmptyException

2015-10-13 Thread Modha, Digant
Hi,

I am running Cassandra 2.1.10 and noticed intermittent 
DirectoryNotEmptyExceptions during repair.  My cassandra data drive is 
reiserfs.  I noticed that on reiserfs wiki site 
https://en.m.wikipedia.org/wiki/ReiserFS#Criticism, it states that unlink 
operation is not synchronous. Is that the reason for the exception below:


ERROR [ValidationExecutor:137] 2015-10-13 00:46:30,759 CassandraDaemon.java:227 
- Exception in thread Thread[ValidationExecutor:137,1,main]
org.apache.cassandra.io.FSWriteError: java.nio.file.DirectoryNotEmptyException:
at 
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135) 
~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:381) 
~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.db.Directories.clearSnapshot(Directories.java:647) 
~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.db.ColumnFamilyStore.clearSnapshot(ColumnFamilyStore.java:2451)
 ~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1018)
 ~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:94)
 ~[apache-cassandra-2.1.10.jar:2.1.10]
at 
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:622)
 ~[apache-cassandra-2.1.10.jar:2.1.10]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_60]

Thanks,

Digant

TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


RE: cassandra repair error

2015-07-16 Thread Modha, Digant
The hard drives have plenty of space left and working properly as far as I 
know.  We’ve been running Cassandra for almost a year now. It’s the first time 
we’re seeing this problem.  I see a JIRA for v2.1 but that is with NFS..  We’re 
not using NFS.

From: Carlos Rolo [mailto:r...@pythian.com]
Sent: Thursday, July 16, 2015 8:59 AM
To: user@cassandra.apache.org
Subject: Re: cassandra repair error

Hello,
It seems that is a problem with Cassandra trying to delete a directory that is 
not empty. First time seeing this error.
Are your harddrives with enough space and working correctly?

Regards,

Carlos Juzarte Rolo
Cassandra Consultant

Pythian - Love your data

rolo@pythian | Twitter: cjrolo | Linkedin: 
linkedin.com/in/carlosjuzarterolo<http://linkedin.com/in/carlosjuzarterolo>
Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649
www.pythian.com<http://www.pythian.com/>

On Thu, Jul 16, 2015 at 2:45 PM, Modha, Digant 
mailto:digant.mo...@tdsecurities.com>> wrote:
Hi,

We’re using Cassandra 2.0.10 ( 2 DC, 3 Nodes each RF=3 for each DC).  During 
one of the weekly repairs, we received the following error:

ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,992 Validator.java (line 
242) Failed creating a merkle tree for [repair 
#d2178ba0-2902-11e5-bd95-f14c61d86b85 on dmds/curve_dates, 
(-1942303675502999131,-1890400428284965630]], /  (see log for details)
ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,992 CassandraDaemon.java 
(line 199) Exception in thread Thread[ValidationExecutor:1280,1,main]
FSWriteError in 
/apps/data/cassandra/dmds/data/dmds/curve_dates/snapshots/d2178ba0-2902-11e5-bd95-f14c61d86b85
  at 
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:122)
  at 
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:384)
  at 
org.apache.cassandra.db.Directories.clearSnapshot(Directories.java:488)
  at 
org.apache.cassandra.db.ColumnFamilyStore.clearSnapshot(ColumnFamilyStore.java:1877)
  at 
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:811)
  at 
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:63)
  at 
org.apache.cassandra.db.compaction.CompactionManager$8.call(CompactionManager.java:398)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.DirectoryNotEmptyException: 
/apps/data/cassandra/dmds/data/dmds/curve_dates/snapshots/d2178ba0-2902-11e5-bd95-f14c61d86b85
  at 
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
  at 
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
  at java.nio.file.Files.delete(Files.java:1126)
  at 
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:118)
  ... 10 more
ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,993 StorageService.java 
(line 364) Stopping gossiper
WARN [ValidationExecutor:1280] 2015-07-12 22:18:10,993 StorageService.java 
(line 278) Stopping gossip by operator request
INFO [ValidationExecutor:1280] 2015-07-12 22:18:10,993 Gossiper.java (line 
1279) Announcing shutdown
Has anybody seen this error?  The drives are local. Once this happened, the 
other node performing  repair maxed out the CPU and cluster became unresponsive.


Thanks,
dm



TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.



--



TD Securities disclaims any liability or losses either direct or consequential 
caused 

cassandra repair error

2015-07-16 Thread Modha, Digant
Hi,

We're using Cassandra 2.0.10 ( 2 DC, 3 Nodes each RF=3 for each DC).  During 
one of the weekly repairs, we received the following error:

ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,992 Validator.java (line 
242) Failed creating a merkle tree for [repair 
#d2178ba0-2902-11e5-bd95-f14c61d86b85 on dmds/curve_dates, 
(-1942303675502999131,-1890400428284965630]], /  (see log for details)
ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,992 CassandraDaemon.java 
(line 199) Exception in thread Thread[ValidationExecutor:1280,1,main]
FSWriteError in 
/apps/data/cassandra/dmds/data/dmds/curve_dates/snapshots/d2178ba0-2902-11e5-bd95-f14c61d86b85
  at 
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:122)
  at 
org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:384)
  at 
org.apache.cassandra.db.Directories.clearSnapshot(Directories.java:488)
  at 
org.apache.cassandra.db.ColumnFamilyStore.clearSnapshot(ColumnFamilyStore.java:1877)
  at 
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:811)
  at 
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:63)
  at 
org.apache.cassandra.db.compaction.CompactionManager$8.call(CompactionManager.java:398)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.DirectoryNotEmptyException: 
/apps/data/cassandra/dmds/data/dmds/curve_dates/snapshots/d2178ba0-2902-11e5-bd95-f14c61d86b85
  at 
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
  at 
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
  at java.nio.file.Files.delete(Files.java:1126)
  at 
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:118)
  ... 10 more
ERROR [ValidationExecutor:1280] 2015-07-12 22:18:10,993 StorageService.java 
(line 364) Stopping gossiper
WARN [ValidationExecutor:1280] 2015-07-12 22:18:10,993 StorageService.java 
(line 278) Stopping gossip by operator request
INFO [ValidationExecutor:1280] 2015-07-12 22:18:10,993 Gossiper.java (line 
1279) Announcing shutdown
Has anybody seen this error?  The drives are local. Once this happened, the 
other node performing  repair maxed out the CPU and cluster became unresponsive.


Thanks,
dm


TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


RE: Delete By Partition Key Implementation

2014-08-21 Thread Modha, Digant
If you delete entire row, do the records in the row still get counted towards 
computing TombstoneOverwhelmingException?  It seems like they still do.

From: DuyHai Doan [mailto:doanduy...@gmail.com]
Sent: Saturday, August 09, 2014 3:21 AM
To: user@cassandra.apache.org
Subject: Re: Delete By Partition Key Implementation


Thanks graham for the hints.

I've digged into the source code and found out those 2 classes:

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionInfo.java

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/RangeTombstoneList.java

 They are quite self-explanatory.
A deletion of an entire row is a single row tombstone, and yes there are range 
tombstones for marking deletion of a range of columns also

On Aug 8, 2014, at 2:17 PM, Kevin Burton 
mailto:bur...@spinn3r.com>> wrote:


This is a good question.. I'd love to find out the answer.  Seems like a 
tombstone with prefixes for the keys would work well.

Also, can't any key prefixes work in theory?

On Thu, Aug 7, 2014 at 8:33 AM, DuyHai Doan 
mailto:doanduy...@gmail.com>> wrote:
Hello all

 Usually, when using DELETE in CQL3 on some fields, C* creates tombstone 
columns for those fields.

 Now if I delete a whole PARTITION (delete from MyTable where 
partitionKey=...), what will C* do ? Will it create as many tombstones as there 
are physical columns on this partition or will it just mark this partition as 
"deleted" (Row Key deletion marker) ?

 On a side note, if I insert a bunch of physical columns in one partition with 
the SAME ttl value, after a while they will appear as expired, would C* need to 
scan the whole partition on disk to see which columns to expire or could it see 
that the whole partition is indeed expired thanks to meta data/ Partition key 
cache kept in memory ?  I was thinking about the estimate histograms for TTL 
but I don't know in detail how it work

 Regards

 Duy Hai  DOAN




--

Founder/CEO Spinn3r.com
Location: San Francisco, CA
blog: http://burtonator.wordpress.com
… or check out my Google+ 
profile
[cid:~WRD001.jpg]



TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.


Delete row, TombstoneOverwhelmingException and multiple datacenters

2014-08-20 Thread Modha, Digant
Hi All,

We have two data centers running Cassandra 2.0.9.  Using local quorum 
consistency,  I deleted an entire row that had 52,509 records by doing delete 
using only the partition key.When I count number of records for that row, I 
get  0  in the local datacenter from where the row was deleted, but get 
TombstoneOverwhelmingException in the remote datacenter where the data is 
replicated.  Does anybody know the reason the for the discrepancy?
FYI: This exception disappeared few minutes after  trying select count(*) for 
that row and count was 0.  No major compaction was done.

Regards,

dm

TD Securities disclaims any liability or losses either direct or consequential 
caused by the use of this information. This communication is for informational 
purposes only and is not intended as an offer or solicitation for the purchase 
or sale of any financial instrument or as an official confirmation of any 
transaction. TD Securities is neither making any investment recommendation nor 
providing any professional or advisory services relating to the activities 
described herein. All market prices, data and other information are not 
warranted as to completeness or accuracy and are subject to change without 
notice Any products described herein are (i) not insured by the FDIC, (ii) not 
a deposit or other obligation of, or guaranteed by, an insured depository 
institution and (iii) subject to investment risks, including possible loss of 
the principal amount invested. The information shall not be further distributed 
or duplicated in whole or in part by any means without the prior written 
consent of TD Securities. TD Securities is a trademark of The Toronto-Dominion 
Bank and represents TD Securities (USA) LLC and certain investment banking 
activities of The Toronto-Dominion Bank and its subsidiaries.