Hey Mudit,
Renaming is not possible.
Secondly, do you mean all these entries are at same level, under /map_current
znode?
I'd prefer multiple levels instead of having too many direct children of a
single znode. ZOOKEEPER-1162 is one such example case study of too many
children.
/map_current/entry1
/map_current/entry2
...
/map_current/entryn
I think, JZ is suggesting the following way:
Step1) Get all the children of /map_current // first, get all the
children(number of op depends on the levels)
Step2) Prepare list of transactions and submit to the server //second op
- create /map_frozen/entry1....create /map_frozen/entryn. Ops should be
ordered like, create parent to child.
- delete /map_current/entry1...delete /map_current/entryn. Delete in
reverse way from child to parent.
Multi send these ops as a single request, but if we have millions of ops in a
single req it can make the request too heavy. I haven't tested though.
----------------------------------------------------------------------------------------------------------------------------------------------------
I'm thinking an alternate approach to avoid the bulk delete and creation. Does
this work for you?
/writer/my_current1 -> Clients will always look here and get the 'current
writer' node. Now he can create entries as follows.
/my_current1/my_entry1..../my_current1/my_entryn
Now I wanted to frozen /my_current1. Just delete my_current1 from
/writer/my_current1 and create new writer znode /writer/my_current2.
Now clients will see /writer/my_current2 and write entries to this.
Regards,
Rakesh
-----Original Message-----
From: Mudit Verma [mailto:[email protected]]
Sent: 16 June 2014 19:40
To: Jordan Zimmerman
Cc: Camille Fournier; [email protected]
Subject: Re: renaming a znode
I just realised that we can not even delete a parent node, if it has children.
:(
On 16 Jun 2014, at 03:43 pm, Mudit Verma <[email protected]> wrote:
> problem is, it is going to be a very very costly operation (using multi
> transactions). A map may contain millions of entries. I first need to get the
> data of all these entries, delete them and create them again under different
> parent name.
>
> If we have a rename option, all I need to do is just rename the parent znode.
>
> Thanks
> Mudit
> On 16 Jun 2014, at 03:42 pm, Jordan Zimmerman <[email protected]>
> wrote:
>
>> Yeah
>>
>>
>> From: Camille Fournier [email protected]
>> Reply: [email protected] [email protected]
>> Date: June 16, 2014 at 8:42:19 AM
>> To: [email protected] [email protected]
>> Cc: Mudit Verma [email protected]
>> Subject: Re: renaming a znode
>>
>>> Just to clarify you mean the multi API?
>>> C
>>> On Jun 16, 2014 9:40 AM, "Jordan Zimmerman"
>>> <[email protected]>
>>> wrote:
>>>
>>> > You could use the transaction api to create a new node and delete
>>> > the old node.
>>> >
>>> > -JZ
>>> >
>>> >
>>> > From: Mudit Verma [email protected]
>>> > Reply: [email protected] [email protected]
>>> > Date: June 16, 2014 at 8:38:11 AM
>>> > To: [email protected] [email protected]
>>> > Subject: renaming a znode
>>> >
>>> > Hello People,
>>> >
>>> > Sorry for asking many questions these days. :)
>>> >
>>> > I am wondering if it is possible to rename a znode? I am building
>>> > a distributed map on top of zookeeper for special needs. From time
>>> > to time, I need to freeze the map without restricting write access to the
>>> > map.
>>> >
>>> > I plan to do it by maintaining two maps:
>>> >
>>> > map_current
>>> > map_frozen
>>> >
>>> > all the map entries are maintained as separate children znodes
>>> > where key is the name of the child node and value is the value
>>> > stored on the child node ..
>>> > for example /map_current/entry1(kv)
>>> > /map_current/entry2(kv)
>>> >
>>> >
>>> > Now at some point of time, I need to iterate the map while still
>>> > allowing write access by other clients. While I iterate, I don't
>>> > want other clients to see these entries. Once I process map_frozen
>>> > entries I will delete them (I don't need them anymore) by just deleting
>>> > the parent node.
>>> >
>>> > I plan to rename existing map from map_current to map_frozen and
>>> > create new map as map_current with empty data for further writes.
>>> > Other clients will continue to write new entries in map_current .. so on
>>> > so forth ..
>>> >
>>> > Any suggestions on how can I do it efficiently.
>>> >
>>> > Thanks
>>> > Mudit
>
