zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: metadata versus child znodes
Date Wed, 15 Dec 2010 01:20:31 GMT
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message