Spark connector doesn't do the "select * from table;" - it does reads by
token ranges, reading the data
(see
https://github.com/datastax/spark-cassandra-connector/blob/master/spark-cassandra-connector/src/main/scala/com/datastax/spark/connector/rdd/partitioner/CassandraPartition.scala#L14)
Jac
I am a newbie in cassandra. I have asked this question on various platforms but
never got a satisfying answer.
Hence thought of bringing up the topic here. Sorry for this might be a simple
question.
1. I studied the paper on consistent hashing (which is being implemented in
Cassandra)
2. Cassan
> On Aug 17, 2019, at 10:53 AM, Inquistive allen wrote:
>
> I am a newbie in cassandra. I have asked this question on various platforms
> but never got a satisfying answer.
> Hence thought of bringing up the topic here. Sorry for this might be a simple
> question.
>
> 1. I studied the paper
Hello Jeff,
Thanks for the response.
I just got it right. One Last thing, when a read request comes in to the
coordinator node, the partition key is hashed and a node is located where
corresponding data is previously stored. How does the coordinator node
locate the replica nodes for this row.
The
The has results in a token
The replicas are typically the RF instances with tokens numerically larger than
the hash
So if a row hashes to token 1, and the instances are -100,0,100,200,300,400,500
the replica instances are 100,200,300, and cassandra considers them to be
identical for nearly all
Hi Asad,
Seems to me that your development team will need to remodel the tables
sooner than later. This problem can't be left unattended for long once it
starts hitting severely.
The way Cassandra is, you may want to have them replicate the same table
with different PK / structure to suitably embed
