Are Voldemort Partitions logical or not?

[Nidhin]

Hi,

I am relatively new to Voldemort database. I would like to clarify if the Voldemort Partitions are logical or not?

I mean if there are 5 partitions in a Node, does data gets stored in 5 different partitions? I could see that for a given Node, Voldemort is storing the data in a single storageEngine for a given store. 

Thanks,

-Nidhin 

[Arunachalam]

Voldemort partitions are logical, It is all stored in a single stroage. 

Thanks,

Arun.

--
You received this message because you are subscribed to the Google Groups "project-voldemort" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-voldem...@googlegroups.com.
Visit this group at http://groups.google.com/group/project-voldemort.
For more options, visit https://groups.google.com/d/optout.

[Nidhin]

Hi Arun,

Thanks for the update. 

As per below link, it is mentioned that "the number of data partitions cannot be changed".

http://www.project-voldemort.com/voldemort/configuration.html

If the number of partitions are logical and all data within a node are stored in single storage, I would like to know why we could not increase the number of partitions.

If we are able to maintain the partition ring as shown in the attachment "Partitions.pdf", should n't we be able to increase the number of partitions (On multiples of existing number of partition and maintaining the order of Nodes in the partition ring).

It would be great if you can share the thoughts on the same.

Thanks,

-Nidhin

[Felix GV]

I believe you would not be able to create new empty partitions, since the consistent hashing would never assign any keys to those new partitions. Theoretically, I imagine you could *split* existing partitions in two halves each and alter the consistent hashing strategy accordingly, but it would likely be fairly complex to do right. That is not something Voldemort currently supports.

The recommended strategy for future-proof elastic scaling is to over-provision the number of partitions so that they can be re-balanced without needing to split them nor create new ones. For example, nowadays at LinkedIn, we run many of our production clusters with one to two thousand partitions.

If you really care about re-partitioning, you should explain your use case so we can understand better, and perhaps suggest alternatives.

Thanks.

--
 
Felix GV
Data Infrastructure Engineer
Distributed Data Systems
LinkedIn
 
f...@linkedin.com
linkedin.com/in/felixgv

---

From: project-...@googlegroups.com [project-...@googlegroups.com] on behalf of Nidhin [nidhing...@gmail.com]
Sent: Tuesday, January 20, 2015 10:47 PM
To: project-...@googlegroups.com
Subject: Re: [project-voldemort] Are Voldemort Partitions logical or not?

[Nidhin]

Hi Felix,

I did not understand why consistent hashing would never assign any keys to those new partitions. If we modify the cluster ring, system would allow to insert the keys into new partitions. As I understand, partitions are logical only. At the end, we are saving the keys in the same node.

As I have shown in my earlier attachment, I did a round of testing by changing or modifying the cluster. 

Keys are getting inserted into new partitions. I did try to fetch the keys associated with the new partition using Admin tool. It fetches the keys also from new partition.

Use case scenario is as follows: (It is just an example)

Consider I have a ten node cluster with each cluster having one partition only.

After a certain point, I would like to increase the number of nodes. How will we do that?

Looking at the code and based on the routing strategies, it seems like if we maintain the order of Nodes in the Consistent hashing ring , it is actually possible to increase the number of partitions. 

I am trying to clarify if my understanding is correct or not regarding the implementation of the database.

Thanks,

-Nidhin  

[Felix GV]

Well......

Maybe I'm missing something, but if keys you *put* after increasing the number of partitions are getting assigned to your new partitions, then how are you expecting to *get* the keys that you've put in before increasing the number of partitions?

While it is true that many logical partitions are lumped in the same physical storage engine on each node, I fail to see how you would have any guarantee that the new key-partition assignments make keys end up on the same physical nodes as the old key-partition assignments...

It seems to me like you have a conundrum where either:

1. Your keys get mapped to all of your partitions, including your new ones, but you can't find keys that were stored in your old partitions, pre-increase. OR
2. Your keys never get mapped to your new partitions, and the consistency of the hashing is preserved, thus allowing you to retrieve keys that were stored pre-increase.

The use case you describe is not well supported as of today in Voldemort. If you painted yourself into a corner with a number of partition which is too tight given your number of physical nodes, you would probably need to rebuild a copy of the cluster with more partitions (using costly admin operations) and somehow shadow and then fail over the traffic to your new cluster (and/or withstand downtime). Voldemort has been designed for over-partitioned clusters.

--
 
Felix GV
Data Infrastructure Engineer
Distributed Data Systems
LinkedIn
 
f...@linkedin.com
linkedin.com/in/felixgv

From: project-...@googlegroups.com [project-...@googlegroups.com] on behalf of Nidhin [nidhing...@gmail.com]

Sent: Wednesday, January 21, 2015 10:59 AM

[Nidhin]

Assume this is the existing ring formed from the cluster.

I am inserting a key say 'A' whose hash value is 10. (Just example)

Now, it would fall under partition 2, which is on Node0 based on the logic 10 % 4.

Data gets saved in Node0.

Now let us modify the cluster as follows:

Try to fetch the key say 'A' whose hash value is 10.

Partition id to check as per routing strategy is 4 based on the logic 10 % 6. 

We would still get the value for key 'A' since partition 4 is pointing to Node0.

Insert another key say 'B' whose hash value is 13. (Just example)

Now, it would fall under partition 1, which is on Node1 based on the logic 13 % 6.

Data gets saved in Node1.

Now let us modify the cluster as follows:

Try to fetch the key say 'A' whose hash value is 10.

Partition id to check as per routing strategy is 2 based on the logic 10 % 8. 

We would still get the value for key 'A' since partition 2 is pointing to Node0.

Try to fetch the key say 'B' whose hash value is 13.

Partition id to check as per routing strategy is 5 based on the logic 13 % 8. 

We would still get the value for key 'B' since partition 5 is pointing to Node1.

My point here is, if we maintain the node order in the cluster by increasing the number of partitions, then we should ideally be able to increase the partition count. 

In this case, we have to increase the partitions on multiples of 2 like N0 has to be followed by N1 and N1 has to be followed by N0 in the partition ring.

Am I missing something here due to which this logic would not work? Is there any other dependency due to Partitioning.

Please suggest.

Thanks,

-Nidhin

[Nidhin]

I think in the previous post, the pictures did not come through fine.

Please find attached the cluster structures which I wanted to show in each stage.

Thanks,

-Nidhin

[Arunachalam]

This is a long reply, which I haven't completely read through. So correct me if that is already discussed.

Nidhin, can you increase the number of partitions theoretically and support it in the code ? Yes, but getting the online writes to work and others in production is a nightmare when you have the simpler solution of over provisioning. So why increase the partition when it has too many limtiations.

Thanks,

Arun.

[Nidhin]

Thanks, I got the point. 

I just wanted to clear myself that there is no restriction for increasing the number of partition.

Now, I am good.

Regards,

-Nidhin