On Wed, Sep 7, 2011 at 3:09 PM, Uday Subbarayan <[email protected]>wrote:
> Mahadev, > There are couple of reasons: > a) We want to use our Web GUI to create/update/delete the data. (which is > basically our own internal configuration information) This helps our > operation team don't have to use any external tool for handling ZK data. > This is trivial to do. Probably the easiest way would be to use a java web framework of some kind to build a simple access interface. JSP would work fine for this. The Python binding would also allow you to use Django. > b)We have to run separate file servers for this particular usage. If it's > in database, it's easy to extend our web gui and then use the existing > mechanism for the data backup. > If the data is in a database, it isn't really Zookeeper. You will have abysmal performance since Zookeeper assumes that it can scan things quickly (as for the snapshot or resync operations). It might be possible to re-engineer the data table underneath Zookeeper to be stored in a database instead of in memory, but that is really fairly perverse. Backing up Zookeeper is trivial. All you have to do is grab the snapshot and logs.
