replica is synchronized or asynchronized?
hi guys, want to ask you guys a question, when we write a datarum to a cluster with N=3, does Riak write the 3 nodes synchronized and verify the result >= W? or just write to a single node then gossip the change to the other two nodes asynchronuously? I guess it's synchronized because i don't understand how we can verify write is successful (>=W) if it's async, right? -- Thanks & Regards, Daniel ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak Recap for Dec. 13 - 14
Hi guys, If we have 64 partitions with 4 nodes, each of the nodes has 16 partitions like this Node1: p1 ~ p16 Node2: p17 ~ p32 Node3: p33 ~ p48 Node4: p49 ~ p64 Now if I add a new node Node 5, each node should handle 12.8 partitions, so the partitions should look like this Node1: p1 ~ p13 Node2: p14 ~ p26 Node3: p27 ~ p39 Node4: p40 ~ p52 Node5: p53 ~ p64 So, I guess Riak would have to re-hash the whole partitions into all the 5 nodes, right? Is this done lazily when the node finds the requested data is missing? Or is there a way to handle this with consistent re-hashing so we can avoid moving data around when new nodes added? Thanks, Daniel ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak Recap for Dec. 13 - 14
Hi Mark, Thanks for your explanation, so in this case the partitions would be re-distributed *from* Node1: p1 ~ p16 Node2: p17 ~ p32 Node3: p33 ~ p48 Node4: p49 ~ p64 *to * Node1: p1 ~ p13 (remove 3 partitions) Node2: p17 ~ p29 (remove 3 partitions) Node3: p33 ~ p45 (remove 3 partitions) Node4: p49 ~ p61 (remove 3 partitions) Node5: p14, 15, 16, 30, 31, 32, 46, 47, 48, 62, 63, 64 (aprox 1/5 partitions will be transferred to this new node) Since there is no centralized node in Riak, how do we know the partition 32 is moved to node 5 from the client caller? Cassandra seems break half of the adjacent node's data into the new node, that will be easy for the client to search for the datum just around the node-circle clockwise, although it causes unbalanced data distribution and you have to move them by command lines. Riak seems to have this solved by moving partitions into new nodes equally, that's very interesting, how do you guys make it? If the client caller queries for partition 32 which was originally on node 2, how do the client know it's on a new node now? Thanks, Daniel On Fri, Dec 17, 2010 at 6:56 AM, Mark Phillips wrote: > Hey Daniel, > > [snip] > > > So, I guess Riak would have to re-hash the whole partitions into all the > 5 > > nodes, right? Is this done lazily when the node finds the requested data > is > > missing? > > Or is there a way to handle this with consistent re-hashing so we can > avoid > > moving data around when new nodes added? > > > > Riak won't rehash all the partitions in the ring when new nodes are > added. When you go from 4 -> 5 nodes, for example, approx. 1/5 of the > existing partitions are transferred to the new node. The other 4/5s of > the partitions will remain unchanged. As far as moving data around > when new nodes are added, this is impossible to avoid. Data needs to > be handed off to be spread around the ring. > > Hope that helps. > > Mark > -- Thanks & Regards, Daniel ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak Recap for Dec. 13 - 14
Hi Daniel, So, the hashing algorithm is still consistent, but partitions (vnodes) are re-distributed to nodes when new nodes are added, and the nodes gossip and share the knowledge of the partition distribution, right? So the client can query any of the nodes, if the node doesn't know where the partition located it will query or gossip with adjacent nodes, right? Thanks, Daniel On Fri, Dec 17, 2010 at 10:42 AM, Dan Reverri wrote: > Hi Daniel, > > Clients do not specify the partition when making a request. A client can > request any key from any node in the cluster and Riak will return the > associated value. > > Thanks, > Dan > > Daniel Reverri > Developer Advocate > Basho Technologies, Inc. > d...@basho.com > > > On Thu, Dec 16, 2010 at 6:01 PM, Daniel Woo wrote: > >> Hi Mark, >> >> Thanks for your explanation, so in this case the partitions would be >> re-distributed >> >> *from* >> >> Node1: p1 ~ p16 >> Node2: p17 ~ p32 >> Node3: p33 ~ p48 >> Node4: p49 ~ p64 >> >> *to * >> Node1: p1 ~ p13 (remove 3 partitions) >> Node2: p17 ~ p29 (remove 3 partitions) >> Node3: p33 ~ p45 (remove 3 partitions) >> Node4: p49 ~ p61 (remove 3 partitions) >> Node5: p14, 15, 16, 30, 31, 32, 46, 47, 48, 62, 63, 64 (aprox 1/5 >> partitions will be transferred to this new node) >> >> Since there is no centralized node in Riak, how do we know the partition >> 32 is moved to node 5 from the client caller? Cassandra seems break half of >> the adjacent node's data into the new node, that will be easy for the client >> to search for the datum just around the node-circle clockwise, although it >> causes unbalanced data distribution and you have to move them by command >> lines. Riak seems to have this solved by moving partitions into new nodes >> equally, that's very interesting, how do you guys make it? If the client >> caller queries for partition 32 which was originally on node 2, how do the >> client know it's on a new node now? >> >> Thanks, >> Daniel >> >> >> On Fri, Dec 17, 2010 at 6:56 AM, Mark Phillips wrote: >> >>> Hey Daniel, >>> >>> [snip] >>> >>> > So, I guess Riak would have to re-hash the whole partitions into all >>> the 5 >>> > nodes, right? Is this done lazily when the node finds the requested >>> data is >>> > missing? >>> > Or is there a way to handle this with consistent re-hashing so we can >>> avoid >>> > moving data around when new nodes added? >>> > >>> >>> Riak won't rehash all the partitions in the ring when new nodes are >>> added. When you go from 4 -> 5 nodes, for example, approx. 1/5 of the >>> existing partitions are transferred to the new node. The other 4/5s of >>> the partitions will remain unchanged. As far as moving data around >>> when new nodes are added, this is impossible to avoid. Data needs to >>> be handed off to be spread around the ring. >>> >>> Hope that helps. >>> >>> Mark >>> >> >> >> >> -- >> Thanks & Regards, >> Daniel >> >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> > -- Thanks & Regards, Daniel ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak Recap for Dec. 13 - 14
Thanks for your patience :-) So, when the client makes a call, it can just be round-robin since all nodes can gossip? But it should be better to guess where the partition is before making the call, right? Where can I find the documentation about how the partition distributions are shared between nodes and how client decides which node to ask? Regards, Daniel On Fri, Dec 17, 2010 at 12:24 PM, Dan Reverri wrote: > Yes. > > Daniel Reverri > Developer Advocate > Basho Technologies, Inc. > d...@basho.com > > > On Thu, Dec 16, 2010 at 7:56 PM, Daniel Woo wrote: > >> Hi Daniel, >> >> So, the hashing algorithm is still consistent, but partitions (vnodes) are >> re-distributed to nodes when new nodes are added, and the nodes gossip and >> share the knowledge of the partition distribution, right? So the client can >> query any of the nodes, if the node doesn't know where the partition located >> it will query or gossip with adjacent nodes, right? >> >> Thanks, >> Daniel >> >> >> >> On Fri, Dec 17, 2010 at 10:42 AM, Dan Reverri wrote: >> >>> Hi Daniel, >>> >>> Clients do not specify the partition when making a request. A client can >>> request any key from any node in the cluster and Riak will return the >>> associated value. >>> >>> Thanks, >>> Dan >>> >>> Daniel Reverri >>> Developer Advocate >>> Basho Technologies, Inc. >>> d...@basho.com >>> >>> >>> On Thu, Dec 16, 2010 at 6:01 PM, Daniel Woo wrote: >>> >>>> Hi Mark, >>>> >>>> Thanks for your explanation, so in this case the partitions would be >>>> re-distributed >>>> >>>> *from* >>>> >>>> Node1: p1 ~ p16 >>>> Node2: p17 ~ p32 >>>> Node3: p33 ~ p48 >>>> Node4: p49 ~ p64 >>>> >>>> *to * >>>> Node1: p1 ~ p13 (remove 3 partitions) >>>> Node2: p17 ~ p29 (remove 3 partitions) >>>> Node3: p33 ~ p45 (remove 3 partitions) >>>> Node4: p49 ~ p61 (remove 3 partitions) >>>> Node5: p14, 15, 16, 30, 31, 32, 46, 47, 48, 62, 63, 64 (aprox 1/5 >>>> partitions will be transferred to this new node) >>>> >>>> Since there is no centralized node in Riak, how do we know the partition >>>> 32 is moved to node 5 from the client caller? Cassandra seems break half of >>>> the adjacent node's data into the new node, that will be easy for the >>>> client >>>> to search for the datum just around the node-circle clockwise, although it >>>> causes unbalanced data distribution and you have to move them by command >>>> lines. Riak seems to have this solved by moving partitions into new nodes >>>> equally, that's very interesting, how do you guys make it? If the client >>>> caller queries for partition 32 which was originally on node 2, how do the >>>> client know it's on a new node now? >>>> >>>> Thanks, >>>> Daniel >>>> >>>> >>>> On Fri, Dec 17, 2010 at 6:56 AM, Mark Phillips wrote: >>>> >>>>> Hey Daniel, >>>>> >>>>> [snip] >>>>> >>>>> > So, I guess Riak would have to re-hash the whole partitions into all >>>>> the 5 >>>>> > nodes, right? Is this done lazily when the node finds the requested >>>>> data is >>>>> > missing? >>>>> > Or is there a way to handle this with consistent re-hashing so we can >>>>> avoid >>>>> > moving data around when new nodes added? >>>>> > >>>>> >>>>> Riak won't rehash all the partitions in the ring when new nodes are >>>>> added. When you go from 4 -> 5 nodes, for example, approx. 1/5 of the >>>>> existing partitions are transferred to the new node. The other 4/5s of >>>>> the partitions will remain unchanged. As far as moving data around >>>>> when new nodes are added, this is impossible to avoid. Data needs to >>>>> be handed off to be spread around the ring. >>>>> >>>>> Hope that helps. >>>>> >>>>> Mark >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Daniel >>>> >>>> ___ >>>> riak-users mailing list >>>> riak-users@lists.basho.com >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>> >>>> >>> >> >> >> -- >> Thanks & Regards, >> Daniel >> > > -- Thanks & Regards, Daniel ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
