What if i use sstabledump? 

Because i'm going to read all data from a table that has no more 
insert/compaction(fixed list of sstables).

 For each sstable:

1. Using sstabledump -e, fetch all partition keys stored on sstable (ordered 
list)

2. Using sstabledump -k partitionKey, fetch all rows for the partitionKey on 
the sstable, by nodetool getsstables,  check if there is any other part of data 
on other sstables



This way maybe i could get 100% disk read performance (fast possible sequential 
read of all data on a table)

I will put the outcome of this experiment here






Sent using https://www.zoho.com/mail/







============ Forwarded message ============
From: onmstester onmstester <onmstes...@zoho.com.INVALID>
To: "user"<user@cassandra.apache.org>
Date: Sat, 14 Nov 2020 08:24:14 +0330
Subject: Re: local read from coordinator
============ Forwarded message ============



Thank you Jeff,

I disabled dynamic_snitch (after reading some Docs about how its not working 
good enough in production) and using GossipingFileProperty snitch, Is it make 
any difference to choosing the replica?



Sent using https://www.zoho.com/mail/








---- On Wed, 11 Nov 2020 17:53:42 +0330 Jeff Jirsa <mailto:jji...@gmail.com> 
wrote ----





This isn’t necessarily true and cassandra has no coordinator-only consistency 
level to force this behavior 



(The snitch is going to pick the best option for local_one reads and any 
compactions or latency deviations from load will make it likely that another 
replica is chosen in practice)



On Nov 11, 2020, at 3:46 AM, Alex Ott <mailto:alex...@gmail.com> wrote:





if you force routing key, then the replica that owns the data will be selected 
as coordinator



On Wed, Nov 11, 2020 at 12:35 PM onmstester onmstester 
<mailto:onmstes...@zoho.com.invalid> wrote:



Thanx,



But i'm OK with coordinator part, actually i was looking for kind of read CL to 
force to read from the coordinator only with no other connections to other 
nodes!



Sent using https://www.zoho.com/mail/








============ Forwarded message ============
From: Alex Ott <mailto:alex...@gmail.com>
To: "user"<mailto:user@cassandra.apache.org>
Date: Wed, 11 Nov 2020 11:28:56 +0330
Subject: Re: local read from coordinator
============ Forwarded message ============



token-aware policy doesn't work for token range queries (at least in the Java 
driver 3.x).  You need to force the driver to do the reading using a specific 
token as a routing key.  Here is Java implementation of the token range 
scanning algorithm that Spark uses: 
https://github.com/alexott/cassandra-dse-playground/blob/master/driver-1.x/src/main/java/com/datastax/alexott/demos/TokenRangesScan.java



I'm not aware if Python driver is able to set routing key explicitly, but 
whitelist policy should help








On Wed, Nov 11, 2020 at 7:03 AM Erick Ramirez 
<mailto:erick.rami...@datastax.com> wrote:

Yes, use a token-aware policy so the driver will pick a coordinator where the 
token (partition) exists. Cheers!








-- 

With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)


















-- 

With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Reply via email to