So, each rack is a different "service" in the Curator-Discovery sense? If so, that will work very well. You should avoid situations where a getChildren() call will approach 1MB of data.
-JZ On Jan 28, 2013, at 1:15 PM, Yasin <[email protected]> wrote: > We will build this service for location discovery. The service we want to > build will act like a DNS server. The service will provide a node IP based > on some given information. I assume that a data center may have 10K or even > more nodes in it. So any client who wants to store or retrieve a file should > find a node in the data center. At most, we can classify nodes into clusters > or racks. > > Suppose, we have 500 racks and each has 32 nodes, that makes 16K nodes. > Zookeeper will store 500 Znoodes and each znode will store 32 znodes. For > example the znodes structure will look like root/rack1/node1, > root/rack1/node2..., root/rack2/node1.., and so on. I do not know if this a > good approach for such a service. Or do you think I shouldn't use zookeeper > and curator for this service at all and look for some other solutions? > > Thanks > Yasin > > > > > > -- > View this message in context: > http://zookeeper-user.578899.n2.nabble.com/curator-service-discovery-search-to-Select-a-service-intance-tp7578447p7578452.html > Sent from the zookeeper-user mailing list archive at Nabble.com.
