Say, we have a Cassandra cluster of 2 nodes. Data with key range [A-D] is inserted into the cluster. Roughly, we can suppose that node 1 stores data with key range [A-B] and node 2 stores data with key range [C-D]. Some time later, we add 2 more nodes. For balancing, partitions should be re-assigned, right? We now expect that each node stores data for exactly 1 key. Does Cassandra re-assign then move existing data to the new node (e.g. existing data with key B from node 1 to node 3)? And how?
Cassandra uses vnodes or virtual nodes by default. Each node does not have one single range (ie [A-C]) but hundreds (256 by default, num_tokens in cassandra.yaml). Depending on your version these token ranges are assigned by random or in earlier versions distributed to maximize equal distribution. This way if one node falls down or if you add a node, all the nodes in the cluster will be next to one of that nodes ranges to share the burden.
Related
Setting up the context:
Cassandra currently implements vnodes. 256 by default which is tweakable in the cassandra.yaml file
Vnodes as I understand are token-ranges/hash-ranges. Eg. (x...y], where y is the token number of the vnode. Each physical node in Cassandra is assigned random 256 tokens, and each of those tokens are the boundary value of a hash/token range. The tokens assigned are within the range of 2^-63 to 2^63-1 (the range of hash numbers which murmur3 has partitioner may generate). So far so good.
Question:
1. Is it that a token range(vnode) is a fixed range. Once set, this token range will be copied to other Cassandra nodes to satisfy the replication factor like a token range(vnode) being a fundamental chunk of data(tokens) which goes around together. Only in case of bootstrap of a new node in the cluster, this token range(vnode) might break apart to be assigned to other node.
Riding on the last proposition, (say the last proposition is true).
Then a vnode must only contain tokens which belong a given keyspace.
Because each keyspace(container of column family/tables) has a defined replication strategy and replication factor. And it is highly likely that replication factor of keyspaces in a Cassandra cluster will vary.
Consider an example. "system_schema" keyspace has a RF of 1 whereas I created a keyspace "test_ks" with RF 3. If a row of system_schema keyspace has a token number 2(say) and a row of my test_ks has token number 5(say).
these 2 tokens can't be placed in the same token range(vnode). If a vnode is consistent chunk of token ranges, say token 2 and 5 belong to vnode with token number 10. so vnode 10 has to be placed on 3 different physical nodes to satisfy the RF =3 for test_ks, but we are unnecessary placing token 2 on 3 different nodes whose RF is supposed to be 1.
Is this proposition correct that, a vnode is only dedicated to a given keyspace?
which boils down to out of 256 tokens on a physical node... 20(say) vnodes currently belong to "system" keyspace, 80 vnodes(say) belong to test_ks.
Again riding on the above proposition, this means that each node should have the info of keyspace-wise vnodes currently available in the cluster.
That way when a new write comes in for a Keyspace the co-ordinator node would locate all vnodes in the cluster for that keyspace and assign the new row a token number which falls within the token range of those keyspaces. That being the case can I know how many vnodes currently belong to a keyspace in the entire cluster/ or on a given node.
Please do correct me if I'm wrong.
I have been following the below blogs and videos to get an understanding of this concept:
https://www.scribd.com/document/253239514/Virtual-Nodes-Strategies-for-Apache-Cassandra
https://www.youtube.com/watch?v=GddZ3pXiDys&t=11s
Thanks in advance
There is no fixed token-range, the tokens are just generated randomly. This is one of the reasons that vnodes were implemented - the idea being that if there are more tokens it is more likely that the resulting token-ranges will be more evenly distributed across nodes.
Token generation was recently improved in 3.0, allowing Cassandra to place new tokens a little more intelligently (see CASSANDRA-7032). You can also manually configure tokens (see initial_token), although it can become tricky to keep things balanced when it comes time to expand the cluster unless you plan on doubling the number of nodes.
The total number of tokens in a cluster is the number of nodes in the cluster multiplied by the number of vnodes per node.
In regards to placement of replicas, the first copy of a partition is placed in the node that owns that partition's token. The additional n copies are placed sequentially on the next n nodes in the ring that are in the same data centre. There is no relationship between tokens and keyspaces.
When a new write comes into a coordinator node, the coordinator node determines which node owns the partition by hashing the partition key. Note that for better performance this can actually be done by the driver instead if you use TokenAwarePolicy. The coordinator sends the write to the node that owns the partition, and if the data needs to be replicated the coordinator node also writes the replicas to the next two nodes sequentially in the token-space.
For example, suppose that we have 3 nodes which each have one token: node1: 10, node2: 20 & node3: 30. If we write a record whose partition key hashes to 22, to a keyspace with RF3, then the first copy goes to node2, the second goes to node3 and the third goes to node1. Note that each replica is equally valid - there is nothing special about the "first" replica other than that it happens to be stored on the "first" replica node.
Vnodes do not change this process, they just split up each node's token ranges by allowing each node to have more than one token. For example, if our cluster now has 2 vnodes for each node, it might instead look like this: node1: 10, 25, node2: 20, 3 & node3: 30, 21. Now our write that hashed to 22 goes to node3 (because it owns the range from 21-24), and the copies go to node1 and node2.
I have 2 nodes with replication factor = 1, it means will have 1 set of data copy in each node.
Based on above description when i use murmur3partitioner,
Will data shared among nodes ? like 50% of data in node1 and 50% of data in node 2?
when i read request to node 1 , will it internally connect with node 2 for consistency ?
And my intention is to make a replica and both nodes should server the request independently without inter communication.
First of all, please try to ask only one question at per post.
I have 2 nodes with replication factor = 1, it means will have 1 set of data copy in each node.
Incorrect. A RF=1 indicates that your entire cluster will have 1 copy of the data.
Will data shared among nodes ? like 50% of data in node1 and 50% of data in node 2?
That is what it will try to do. Do note that it probably won't be exact. It'll probably be something like 49/51-ish.
when i read request to node 1 , will it internally connect with node 2 for consistency ?
With a RF=1, no it will not. Based on the hashed token value of your partition key, it will be directed only to the node which contains the data.
As an example, with a RF=2 with 2 nodes, it would depend on the consistency level set for your operation. Reading at ONE will always read only one replica. Reading at QUORUM will always read from 2 replicas with 2 nodes (after all, QUORUM of 2 equals 2). Reading at ALL will require a response from all replicas, and initiate a read repair if they do not agree.
Important to note, but you cannot force your driver to connect to a specific Cassandra node. You may provide one endpoint, but it will find the other via gossip, and use it as it needs to.
We are using cassandra on a single node. I understand that in a cluster, a smart partition key would allow data to be distributed across cluster and will avoid all the keys getting stored on the same host. However in our case, theres just one host and I can use a constant (dummy) partition key but wanted to check if would miss out on something if I do that. For example, cassandra has a limit of having at most 2 billion cells per partition. Does cassandra honor that limit for a single host too? Can I have a table with more than 2 billion cells on a single node cassandra?
Can I have a table with more than 2 billion cells on a single node
cassandra?
Ans: Yes.
Instead of using a constant(dummy) partition key, I would recommend to choose a good partition key. By doing this you remain open for expansion such as in future you may want to use Cassandra in cluster mode. It doesn't matter if you are using Cassandra in single or cluster mode as rows limited to partition keys not entire node. So a single node can have more than 2 billion rows.
From the url: http://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2, they say:
"If instead we have randomized vnodes spread throughout the entire cluster, we still need to transfer the same amount of data, but now it’s in a greater number of much smaller ranges distributed on all machines in the cluster. This allows us to rebuild the node faster than our single token per node scheme."
Itseems that the above sentence convey, when we replace a dead node with a new node with same num_tokens (say num_tokens:4), then replaced node contain the same token value as the dead node had before releasing those token values.
But Vnodes generates random token values for every node, then how is it possible to replace a node with same Vnodes token value?
The URL seems confusing in explaining the concept of replacing a dead node with new node using the concept of VNODES. It would be nice if someone can clarify how a Vnode is used for replacing the dead node with exact token value ranges.
Thanks in advance.
First, the vnode parameter num_tokens should be set to a small number, the current recommendation from DataStax is eight (8). The original default was 256, which experience found to be too high.
With traditional token ranges, you only have as many ranges as nodes. But, using vnodes, the number of token ranges is virtualized and much larger. You can not mix vnodes and token ranges in the same data center (ring).
Node Failure With Token Ranges:
In this DataStax example above with token ranges, data for ranges C, D and E reside on just three nodes:
Range C is owned by node 3 and replicated on nodes 4 and 5
Range D is owned by node 4 and replicated on nodes 5 and 6
Range E is owned by node 5 and replicated on nodes 6 and 1
In this example, when node 5 fails, Ranges C, D, and E are reloaded and streamed from only three of the remaining five nodes: 1, 3 and 4. Nodes 2 doesn't have any of the node 5 data and node 6 has the same data being streamed by node 1. Thus nodes 2 and 5 are idle during the rebuilding.
Node Failure With Vnodes:
However, when using vnodes the token ranges are split up into smaller ranges and randomized across the entire cluster of 6 nodes. With smaller ranges, a portion of node 5's data is replicated to every one of the other nodes.
When rebuilding node 5, data can now be streamed from all 5 of the available nodes in the cluster.
The primary advantages of vnodes are:
rebalancing a cluster manualy is no longer required when adding or removing nodes
rebuilding can stream data from all available nodes
I'm a beginner in Cassandra. I want to understand how the data gets (re)distributed when a new node joins an existing cluster.
Let us suppose, there were 100 row keys in a cluster of 10 nodes. Also, let us assume for simplicity that using a hash function the rows were evenly distributed to 10 nodes, i.e. node N1 has row keys from 1 to 10, node N2 has row keys 11 to 20 and so on.
Now, if a new node N11 joins the cluster, how is it possible to continue the data distribution over 11 nodes maintaining the same hash function? The reason is that the range of hash function was earlier limited to 10 nodes. And after the new node addition, the range of hash function needs to be changed.
Considering above scenario, how would a lookup for older record (when only 10 nodes were present) succeed?
Prior to Cassandra 1.2, adding a node to the cluster meant splitting token ranges. For instance, with hash function producing values between 1 and 100:
Before: 1-10,11-20,21-30,31-40,41-50,51-60,61-70,71-80,81-90,91-100
After: 1-5,6-10,11-20,21-30,31-40,41-50,51-60,61-70,71-80,81-90,91-100
The first node gives a part of its token range to the new node (in bold).
Each node maintains a map of all nodes and knows which node handles which token ranges (including replicas). When a node is added/removed from the cluster, other nodes get informed of the change by gossiping with each other.
Since Cassandra 1.2, with the addition of virtual nodes, each node of the cluster gives a part of its token range to the new node. As a result each node keeps, more or less, the same token range width, and the same load.