Its probably not practical to do this for every put. Instead each client can get a chunk of ids, and use it for every put. Each chunk of ids will be mutually exclusive and monotonically increases. You need to know that there can be holes in ids and ids will not be according to timestamp within a small interval
If I remember correctly, tweet ids are generated like this. Take a look at snowflake https://github.com/twitter/snowflake thanks, Kishore G On Sun, Apr 21, 2013 at 8:10 AM, PG <pengyunm...@gmail.com> wrote: > Hi, ted and JM, Thanks for the nice introduction. I have read the Omid > paper, which looks use a centralized party to do the coordination and > achieves 72K transactions per sec. And It does much more work than just > assigning timestamps, and I think it implicitly justifies the usage of a > global timestamp oracle in practice.... Appreciate the suggestion. > Regards, > Yun > > Sent from my iPad > > On Apr 16, 2013, at 9:31 AM, Jean-Marc Spaggiari <jean-m...@spaggiari.org> > wrote: > > > Hi Yun, > > > > Attachements are not working on the mailing list. However, everyone > > using HBase should have the book on its desk, so I have ;) > > > > On the figure 8-11, you can see that client wil contact ZK to know > > where the root region is. Then the root region to find the meta, and > > so on. > > > > BUT.... This will be done only once per client! If you do 10 gets from > > your client, once you know where the root region is, you don't need to > > query ZK anymore. It will be cached locally. > > > > For your usecase, you might want to take a look at what Ted send. > > https://github.com/yahoo/omid/wiki I looked a it quickly and seems to > > be a good fit for you. > > > > JM > > > > 2013/4/16 yun peng <pengyunm...@gmail.com>: > >> Hi, Jean and Jieshan, > >> Are you saying client can directly contact region servers? Maybe I > >> overlooked, but I think the client may need lookup regions by first > >> contacting Zk as in figure 8-11 from definitive book(as attached)... > >> > >> Nevertheless, if it is the case, to assign a global timestamp, what is > the > >> practical solutions in real production today? since it still needs some > >> centralised facility.. Please enlighten me. thanks. > >> Regards > >> Yun > >> > >> > >> > >> > >> On Tue, Apr 16, 2013 at 8:19 AM, Jean-Marc Spaggiari > >> <jean-m...@spaggiari.org> wrote: > >>> > >>> Hi Yun, > >>> > >>> If I understand you correctly, that mean that each time our are going > to > >>> do > >>> a put or a get you will need to call ZK first? > >>> > >>> Since ZK has only one master active, that mean that this ZK master > will be > >>> called for each HBase get/put? > >>> > >>> You are going to create a bottle neck there. I don't know how many RS > you > >>> have, but you will certainly hotspot you ZK server. I'm not sure it's a > >>> good idea. > >>> > >>> JM > >>> > >>> 2013/4/16 yun peng <pengyunm...@gmail.com> > >>> > >>>> Hi, All, > >>>> I'd like to add a global timestamp oracle on Zookeep to assign > globally > >>>> unique timestamp for each Put/Get issued from HBase cluster. The > reason > >>>> I > >>>> put it on Zookeeper is that each Put/Get needs to go through it and > >>>> unique > >>>> timestamp needs some global centralised facility to do it. But I am > >>>> asking > >>>> how practical is this scheme, like anyone used in practice? > >>>> > >>>> Also, how difficulty is it to extend Zookeeper, or to inject code to > the > >>>> code path of HBase inside Zookeeper. I know HBase has Coprocessor on > >>>> region > >>>> server to let programmer to extend without recompiling HBase itself. > >>>> Does > >>>> Zk allow such extensibility? Thanks. > >>>> > >>>> Regards > >>>> Yun > >>>> > >> > >> >
