zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hanna <jeremy.hanna1...@gmail.com>
Subject Re: metadata versus child znodes
Date Wed, 15 Dec 2010 02:07:21 GMT
Thanks Mahadev and Ted.  That makes sense.  As we start to use ZK, just trying to get things
right for our design.  Thanks!

On Dec 14, 2010, at 7:20 PM, Ted Dunning wrote:

> Another thought to add to Mahadev's worthy comment is that your update
> pattern might make the directory with children pattern better than the
> single document pattern.  If you have lots of updates to different parts of
> your data, then the directory approach can do better at avoiding colliding
> updates.  If you need updates to be coordinated across multiple parts of the
> data, then a single document is much better.
> 
> On Tue, Dec 14, 2010 at 3:48 PM, Mahadev Konar <mahadev@yahoo-inc.com>wrote:
> 
>> Hi Jeremy,
>> The only concern would be the amount of data that you'd be pushing around.
>> If the data gets too big in a single znode you'd really want to avoid that.
>> A single znode should not be larger than 100 or so KB. The smaller the
>> better. We usually recommend data no larger than 10-50 KB on a single znode.
>> Large size znodes cause unwarranted latency spikes.
>> 
>> Thanks
>> mahadev
>> 
>> 
>> On 12/14/10 1:42 PM, "Jeremy Hanna" <jeremy.hanna1234@gmail.com> wrote:
>> 
>> Generally speaking are there any best practices around using child znodes
>> versus metadata on a znode?
>> 
>> I can see specific instances where a child znode would be better:
>> - need for something ephemeral
>> - watching something specific rather than all of the znode metadata
>> - need for children for that data
>> 
>> Data might be better when it's simply configuration data - key/value pairs
>> for example that is accessed infrequently, since it has to be deserialized
>> from the byte array.
>> 
>> Any other thoughts?  I couldn't find anything in the docs/wiki/user list.
>> 
>> 


Mime
View raw message