There are bigger issues with the current client than that. We buffer 12MB
of writes in N number of configured YCSB threads then send all N*12MB of
writes at the cluster more or less at the same time. While "writing" to the
buffer we report that as what YCSB expects to be round trip time.

I made a stab at rewriting the HBase client to use a single executor pool
and flyweight HTables:
https://github.com/apurtell/YCSB2/commits/new_hbase_client . I've tested
this up to commit https://github.com/apurtell/YCSB2/commit/595a8bc. The
next will size the executor pool proportinally to the size of the target
cluster and the number of YCSB "DB threads" configured for the test:
https://github.com/apurtell/YCSB2/commit/69bd11f

I don't think these changes are quite ready for a PR to YCSB. Would
appreciate feedback on them though, if you have some spare time.
Interesting? Useful? Broken?


On Tue, May 26, 2015 at 9:54 AM, ramkrishna vasudevan <
[email protected]> wrote:

> +1.  Reg the way YCSB works, I would say the first thing that we may need
> is that the load should be evenly distributed after presplitting the
> regions.  Most of the time it does not happen that way and only one among
> the RS is heavily used.
>
> Regards
> Ram
>
> On Tue, May 26, 2015 at 9:58 PM, Sean Busbey <[email protected]> wrote:
>
> > Hi Folks!
> >
> > I've recently become a maintainer on YCSB. We're looking to get a release
> > out in June (our first in several years). We'll probably begin release
> > candidates in a couple of weeks.
> >
> > I'd really like to improve the experience of folks using HBase; the
> current
> > state of the datastore binding leaves much to be desired. Right now,
> people
> > can't even reliably run against multiple versions of HBase. I *think*
> only
> > using 1.0+ client jars works, regardless of old/new API usage. I'll find
> > out for sure in RC testing.
> >
> > Unfortunately, my time on the project is quickly absorbed handling
> reviews
> > and community management efforts. I know a few folks in the HBase
> community
> > have made their own changes over the last few years. If folks could find
> > some time to rebase their forks for the current state of the master
> branch
> > and submit pull requests I'd be super grateful.
> >
> > --
> > Sean
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Reply via email to