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 <[email protected]>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" <[email protected]> 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. >> >>
