[
https://issues.apache.org/jira/browse/ZOOKEEPER-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161303#comment-13161303
]
Daniel Lord commented on ZOOKEEPER-1312:
----------------------------------------
OK Ted, I still don't see a benefit to sharding with an info file vs sharding
on a set of PERSISTENT znodes and depending on ephemerals to track the data.
If I can avoid having to have a janitor/reaper process I would be very happy.
In any case sharding is certainly a possible solution that has its up sides and
its down sides. I'll certainly keep that in mind and it's something that has
been kicked around a bit. I'd prefer a more conceptually pure, or ideal,
solution that doesn't require arbitrary sharding but if this is the best
approach given the constraints so be it.
That being said can any one quantify the relatively performance characteristics
of the following proposals for how to implement a "getChildrenWithStat"
operation (whether it is implemented directly via zk or if I simply implement
it myself with multiple reads)?
1. Implement a new zk method getChildrenWithStat that simply sits on top of the
current DataTree and has to do some iteration over the children nodes to build
the stats.
2. Restructure the DataTree/DataNodes so that they keep track of the DataNodes
for the children instead of relative paths.
-- Note I'm not sure what the implementation concerns around this would be.
It's possible that this was done to conserve memory or other concerns? Would
this even help the server to answer this complex request more quickly/cleanly?
3. Use a multi-op read to read all of the Stats "in one shot".
4. Fire off a bunch of async reads and wait for them all to come back.
I'm not concerned about the increase to the response size that will come back
because of having a ton of Stats come in all at once. It will give me
considerably more flexibility and will actually let me shrink the amount of
data that I need to read to do this process considerably.
If none of these truly work out then I think sharding is what I'll have to do.
If I can avoid that I would love it though.
> Add a "getChildrenWithStat" operation
> -------------------------------------
>
> Key: ZOOKEEPER-1312
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1312
> Project: ZooKeeper
> Issue Type: New Feature
> Reporter: Daniel Lord
> Labels: newbie
>
> It would be extremely useful to be able to have a "getChildrenWithStat"
> method. This method would behave exactly the same as getChildren but in
> addition to returning the list of all child znode names it would also return
> a Stat for each child. I'm sure there are quite a few use cases for this but
> it could save a lot of extra reads for my application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
