Re: [ANNOUNCE] New HBase committer Zheng Hu

2017-10-22 Thread libis
Congratulations!!! 2017-10-23 14:21 GMT+08:00 ramkrishna vasudevan < ramkrishna.s.vasude...@gmail.com>: > Welcome Zheng and congratulations !!! > > On Mon, Oct 23, 2017 at 11:48 AM, Duo Zhang wrote: > > > On behalf of the Apache HBase PMC, I am pleased to announce that Zheng Hu > > has accepted

Re: should we split the scan range into serveral segments when the scan range only located in a single region?

2017-09-05 Thread libis
OK, I have watched the jira. 2017-09-05 15:22 GMT+08:00 Chia-Ping Tsai : > Yeah, 16894 is also a similar one. Maybe Yi Liang still work on this. Move > this discussion to the jira. > > On 2017-09-05 09:53, libis wrote: > > Thanks for Mikhail. I am pleasure to pick HBASE

Re: should we split the scan range into serveral segments when the scan range only located in a single region?

2017-09-04 Thread libis
the information. Mikhail. It seems to me the issue is popular. > libis, Could you take HBASE-18090 over? I can assign the issue to you if i > get ur jira account. > > On 2017-09-04 20:26, Mikhail Antonov wrote: > > I've filed https://issues.apache.org/jira/browse/HBASE-180

Re: should we split the scan range into serveral segments when the scan range only located in a single region?

2017-09-04 Thread libis
; On 2017-09-04 15:06, libis wrote: > > Hi > > > > When TableInputFormat is used to source an HBase table in a MapReduce > job, > > its splitter will make a map task for each region of the table. However, > in > > some cases, the user’s scan range may locate i

should we split the scan range into serveral segments when the scan range only located in a single region?

2017-09-04 Thread libis
Hi When TableInputFormat is used to source an HBase table in a MapReduce job, its splitter will make a map task for each region of the table. However, in some cases, the user’s scan range may locate in a single region, resulting in there is a only mapper. For example, the rowkey of the table is ‘

Re: A new Mutilple-Type Queue idea to handle multiple workloads

2017-04-16 Thread libis
client-3 would occupy all handlers. > > The pictures didn't go through. > > Since you have code for this improvement, consider opening JIRA where you > can publish your patch and pictures so that we get better idea of your > enhancement. > > Thanks > > On Sun, Apr 16,

Re: A new Mutilple-Type Queue idea to handle multiple workloads

2017-04-16 Thread libis
I am runing expriment at the following scenario : both client-1 and client-2 send update requests, the client-1 write the large objects(100KB record) into table-1, and client-2 write the small objects (1KB record) into table-2. The charts below shows the effect of the Mutilple-Type queue feature: