zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: zookeeper design problem
Date Sun, 13 Sep 2015 05:06:50 GMT
Can't you just add a zNode under client_xxx for each of your 'event'
triplets, and then have the reaper go and remove that whole child node when
the 'event' node is beyond a certain age? Something like:


On Sun, Sep 13, 2015 at 7:59 AM, Check Peck <comptechgeeky@gmail.com> wrote:

> I am working on designing the zookeeper node hierarchy so looking for some
> suggestion. I have a clients node under which I will have multiple clients
> (for ex: client_100, client_101)
>     /root/clients/client_100
>     /root/clients/client_101
>     /root/clients/client_102
> Now inside each client, I need to store three things:
>    1. First is metric data which will be in JSON format (max 15 key-value
>    pairs).
>    2. Second is transaction data which will be plain simple string (this
>    data should be less than 1 MB).
>    3. Third is client logs data which will also be plain simple string
>    (this data should also be less than 1 MB).
> Also now most important thing, I can have multiple of above three things
> for each client. Meaning for client_100, I can have two metric data, two
> transaction data and two client logs. Here two is just a number it can be X
> but I will have my reaper process running that can clean the old "metric
> data, transaction data and client logs" for each client after certain
> period or some threshold.
> In short, for each client I have a list of above three things which I need
> to show on zookeeper. What is the right design for this so that I don't
> destroy zookeeper. I can have each znode for each of above three things but
> I am not sure how can I bucket this since it will be multiple for each
> clients.
> Also max number of clients I can have is 1000 that's all. But I will have
> another reaper process for this as well to keep deleting older clients
> which doesn't had any activity from a long time.

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