?????? [DISCUSS] Removing problematic terms from our project

[zheng wang]

I like the controller.


Coordinator is a bit long for me to write and speak.
Manager and Admin is used somewhere yet in HBase.




--  --
??: "Andrew Purtell"https://www.merriam-webster.com/dictionary/master
> > > > > > > > > > 
 >;
> > > for
> > > > > > > > > > examples. In particular, 
the progression of an artisan
> > was
> > > > > from
> > > > > > > > > > "apprentice" to 
"journeyman" to "master". A master
> > smith,
> > > > > > > carpenter,
> > > > > > > > > or
> > > > > > > > > > artist would run a shop 
managing lots of workers and
> > > > > apprentices
> > > > > > > who
> > > > > > > > > would
> > > > > > > > > > hope to become masters of 
their own someday. So
> "master"
> > > and
> > > > > > > > "worker"
> > > > > > > > > can
> > > > > > > > > > still go together.
> > > > > > > > > >
> > > > > > > > > > Since it's the least 
problematic term, and by far the
> > > > hardest
> > > > > > term
> > > > > > > > to
> > > > > > > > > > change (both within HBase 
and with effects on
> downstream
> > > > > > projects
> > > > > > > > > such as
> > > > > > > > > > Ambari), I'm -0 
(nonbinding) on changing "master".
> > > > > > > > > >
> > > > > > > > > > Geoffrey
> > > > > > > > > >
> > > > > > > > > > On Mon, Jun 22, 2020 at 
1:32 PM Rushabh Shah
> > > > > > > > > > 
https://issues.apache.org/jira/browse/HBASE-12677
> > > > > > > > > > > >:
> > > > > > > > > > > > 
>>     Update
> > > > replication
> > > > > > docs
> > > > > > > > to
> > > > > > > > > clarify terminology
> > > > > > > > > > > > 
>>     -
> > HBASE-13852 <
> > > > > > > > > > 
https://issues.apache.org/jira/browse/HBASE-13852
> > > > > > > > > > > >:
> > > > > > > > > > > > 
>>     Replace
> > > > > master-slave
> > > > > > > > > terminology in book, site, and 
javadoc
> > > > > > > > > > with a
> > > > > > > > > > > > more
> > > > > > > > > > > > 
>>     modern
> > > vocabulary
> > > > > > > > > > > > 
>>     -
> > HBASE-24576 <
> > > > > > > > > > 
https://issues.apache.org/jira/browse/HBASE-24576
> > > > > > > > > > > >:
> > > > > > > > > > > > 
>>     Changing
> > > > > "whitelist"
> > > > > > > and
> > > > > > > > > "blacklist" in our docs and project
> > > > > > > > > > > > 
>>
> > > > > > > > > > > > 
>> In response to this proposal, a
> > member
> > > of
> > > > > the
> > > > > > > PMC
> > > > > > > > > asked if the term
> > > > > > > > > > > > 
>> 'master' used by itself would be
> > fine,
> > > > > > because
> > > > > > > we
> > > > > > > > > only have use of
> > > > > > > > > > > > 'slave'
> > > > > > > > > > > > 
>> in replication documentation and
> that
> > > is
> > > > > > easily
> > > > > > > > > addressed. In
> > > > > > > > > > response
> > > > > > > > > > > > to
> > > > > > > > > > > > 
>> this question, others on the PMC
> > > > suggested
> > > > > > that
> > > > > > > > > even if only
> > > > > > > > > > 'master'
> > > > > > > > > > > is
> > > > > > > > > > > > 
>> used, in this context it is still a
> > > > > problem.
> > > > > > > > > > > > 
>>
> > > > > > > > > > > > 
>> For folks who are surprised or
> > lacking
> > > > > > context
> > > > > > > on
> > > > > > > > > the details of
> > > > > > > > > > this
> > > > > > > > > > > > 
>> discussion, one PMC member offered
> a
> > > link
> > > > > to
> > > > > > > this
> > > > > > > > > draft RFC as
> > > > > > > > > > > > 
background:
> > > > > > > > > > > > 
>>
> > > > > > > > > 
https://tools.ietf.org/id/draft-knodel-terminology-00.html
> > > > > > > > > > > > 
>>
> > > > > > > > > > > > 
>> There was general support for
> > removing
> > > > the
> > > > > > term
> > > > > > > > > "master" / "hmaster"
> > > > > > > > > > > > from
> > > > > > > > > > > > 
>> our code base and using the terms
> > > > > > "coordinator"
> > > > > > > > or
> > > > > > > > > "leader" instead.
> > > > > > > > > > > In
> > > > > > > > > > > > the
> > > > > > > > > > > > 
>> context of replication, "worker"
> > makes
> > > > less
> > > > > > > sense
> > > > > > > > > and perhaps
> > > > > > > > > > > > 
"destination"
> > > > > > > > > > > > 
>> or "follower" would be more
> > appropriate
> > > > > > terms.
> > > > > > > > > > > > 
>>
> > > > > > > > > > > > 
>> One PMC member's thoughts on
> language
> > > and
> > > > > > > > > non-native English
> > > > > > > > > > speakers
> >

Re: [DISCUSS] Removing problematic terms from our project

[Andrew Purtell]

> - AdminServer (as you already have AdminClient to talk to it).

Oh... I like AdminServer. AdminServer (serving admin functions) and
RegionServer (serving region data).

On Thu, Jun 25, 2020 at 4:46 PM Andrey Elenskiy
 wrote:

> > Is there a word that's not "master" and not "coordinator" that is clear
> and
> suitable for (diverse, polyglot) community?
>
> There are also:
> - captain (sounds pretty close to "master" without the negative side and it
> should be relatable around the world)
> - conductor (as in orchestra)
> - controller (in kafka controller assigns partitions)
> - RegionDriver (more relevant to what it's actually doing in hbase and
> borrowed from PlacementDrive of TiKV)
> - AdminServer (as you already have AdminClient to talk to it).
>
> On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey  wrote:
>
> > How about "manager"?
> >
> > (It would help me if folks could explain what is lacking in
> "coordinator".)
> >
> > On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  wrote:
> >
> > > On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
> > > wrote:
> > >
> > > > -0/+1/+1/+1
> > > >
> > > > I’m the one who asked whether ‘master’ is safe to use without ‘slave’
> > in
> > > > the private list.
> > > >
> > > > I’m still not convinced that it is really necessary and I do not
> think
> > > > other words like ‘coordinator’ can fully describe the role of HMaster
> > in
> > > > HBase. HBase is more than 10 years old. In the context of HBase, the
> > word
> > > > ‘HMaster’ has its own meaning. Changing the name will hurt our users
> > and
> > > > make them confusing, especially for us non native English speakers...
> > > >
> > >
> > > Is there a word that's not "master" and not "coordinator" that is clear
> > and
> > > suitable for (diverse, polyglot) community?
> > >
> > > Stack 于2020年6月25日 周四06:34写道：
> > > >
> > > > > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows
> > hbase3
> > > > > soon after sounds good to me. I'm up for working on this.
> > > > > S
> > > > >
> > > > > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> > > > >
> > > > > > Strongly agree with what Nick said here:
> > > > > >
> > > > > >  " From my perspective, we gain nothing as a project or as a
> > > community
> > > > be
> > > > > > willfully retaining use of language that is well understood to be
> > > > > > problematic or hurtful, On the contrary, we have much to gain
> > by
> > > > > > encouraging
> > > > > > contributions from as many people as possible."
> > > > > >
> > > > > > +1 to Andrew's proposal.
> > > > > >
> > > > > > It might be good to have a source of truth web page or README
> file
> > > for
> > > > > > developers and users to refer to regarding all naming
> transitions.
> > > It's
> > > > > > going to help both developers changing the code and users looking
> > for
> > > > > some
> > > > > > answers online that use old namings.
> > > > > >
> > > > > > Xu
> > > > > >
> > > > > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk <
> ndimi...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey 
> > > wrote:
> > > > > > >
> > > > > > > > I would like to make sure I am emphatically clear that
> "master"
> > > by
> > > > > > itself
> > > > > > > > is not okay if the context is the same as what would normally
> > be
> > > a
> > > > > > > > master/slave context. Furthermore our use of master is
> clearly
> > > > such a
> > > > > > > > context.
> > > > > > >
> > > > > > >
> > > > > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > > > > master/slave
> > > > > > > baggage. As an alternative, I prefer the term “coordinator”
> over
> > > > > > “leader”.
> > > > > > > Thus we would have daemons called “coordinator” and “region
> > > server”.
> > > > > > >
> > > > > > > To me, “master” as in “master branch” does not carry the same
> > > > baggage,
> > > > > > but
> > > > > > > I’m also in favor changing the name of our default branch to a
> > word
> > > > > that
> > > > > > is
> > > > > > > less conflicted. I see nothing that we gain as a community by
> > > > > continuing
> > > > > > to
> > > > > > > use this word.
> > > > > > >
> > > > > > > It seems to me we have, broadly speaking, consensus around
> making
> > > > > *some*
> > > > > > > > changes. I haven't seen a strong push for "break everything
> in
> > > the
> > > > > name
> > > > > > > of
> > > > > > > > expediency" (I would personally be fine with this). So
> barring
> > > > > > additional
> > > > > > > > discussion that favors breaking changes, current approaches
> > > should
> > > > > > > comport
> > > > > > > > with our existing project compatibility goals.
> > > > > > > >
> > > > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > > > practical
> > > > > > > > examples? If anyone is currently up for doing the work of a
> PR
> > we
> > > > can
> > > > > > > look
> > > > > > > > at for one of these?
> > > > > > > >
> > > > > > > > If folks would prefer we e.g. just say "we should 

Re: [DISCUSS] Removing problematic terms from our project

[Andrey Elenskiy]

> Is there a word that's not "master" and not "coordinator" that is clear
and
suitable for (diverse, polyglot) community?

There are also:
- captain (sounds pretty close to "master" without the negative side and it
should be relatable around the world)
- conductor (as in orchestra)
- controller (in kafka controller assigns partitions)
- RegionDriver (more relevant to what it's actually doing in hbase and
borrowed from PlacementDrive of TiKV)
- AdminServer (as you already have AdminClient to talk to it).

On Thu, Jun 25, 2020 at 3:49 PM Sean Busbey  wrote:

> How about "manager"?
>
> (It would help me if folks could explain what is lacking in "coordinator".)
>
> On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  wrote:
>
> > On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
> > wrote:
> >
> > > -0/+1/+1/+1
> > >
> > > I’m the one who asked whether ‘master’ is safe to use without ‘slave’
> in
> > > the private list.
> > >
> > > I’m still not convinced that it is really necessary and I do not think
> > > other words like ‘coordinator’ can fully describe the role of HMaster
> in
> > > HBase. HBase is more than 10 years old. In the context of HBase, the
> word
> > > ‘HMaster’ has its own meaning. Changing the name will hurt our users
> and
> > > make them confusing, especially for us non native English speakers...
> > >
> >
> > Is there a word that's not "master" and not "coordinator" that is clear
> and
> > suitable for (diverse, polyglot) community?
> >
> > Stack 于2020年6月25日 周四06:34写道：
> > >
> > > > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows
> hbase3
> > > > soon after sounds good to me. I'm up for working on this.
> > > > S
> > > >
> > > > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> > > >
> > > > > Strongly agree with what Nick said here:
> > > > >
> > > > >  " From my perspective, we gain nothing as a project or as a
> > community
> > > be
> > > > > willfully retaining use of language that is well understood to be
> > > > > problematic or hurtful, On the contrary, we have much to gain
> by
> > > > > encouraging
> > > > > contributions from as many people as possible."
> > > > >
> > > > > +1 to Andrew's proposal.
> > > > >
> > > > > It might be good to have a source of truth web page or README file
> > for
> > > > > developers and users to refer to regarding all naming transitions.
> > It's
> > > > > going to help both developers changing the code and users looking
> for
> > > > some
> > > > > answers online that use old namings.
> > > > >
> > > > > Xu
> > > > >
> > > > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > > > wrote:
> > > > >
> > > > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey 
> > wrote:
> > > > > >
> > > > > > > I would like to make sure I am emphatically clear that "master"
> > by
> > > > > itself
> > > > > > > is not okay if the context is the same as what would normally
> be
> > a
> > > > > > > master/slave context. Furthermore our use of master is clearly
> > > such a
> > > > > > > context.
> > > > > >
> > > > > >
> > > > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > > > master/slave
> > > > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > > > “leader”.
> > > > > > Thus we would have daemons called “coordinator” and “region
> > server”.
> > > > > >
> > > > > > To me, “master” as in “master branch” does not carry the same
> > > baggage,
> > > > > but
> > > > > > I’m also in favor changing the name of our default branch to a
> word
> > > > that
> > > > > is
> > > > > > less conflicted. I see nothing that we gain as a community by
> > > > continuing
> > > > > to
> > > > > > use this word.
> > > > > >
> > > > > > It seems to me we have, broadly speaking, consensus around making
> > > > *some*
> > > > > > > changes. I haven't seen a strong push for "break everything in
> > the
> > > > name
> > > > > > of
> > > > > > > expediency" (I would personally be fine with this). So barring
> > > > > additional
> > > > > > > discussion that favors breaking changes, current approaches
> > should
> > > > > > comport
> > > > > > > with our existing project compatibility goals.
> > > > > > >
> > > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > > practical
> > > > > > > examples? If anyone is currently up for doing the work of a PR
> we
> > > can
> > > > > > look
> > > > > > > at for one of these?
> > > > > > >
> > > > > > > If folks would prefer we e.g. just say "we should break
> whatever
> > we
> > > > > need
> > > > > > to
> > > > > > > in 3.0.0 to make this happen" then it would be good to speak
> up.
> > > > > > Otherwise
> > > > > > > likely we would be done with needed changes circa hbase 4,
> > probably
> > > > > late
> > > > > > > 2021 or 2022.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jun 23, 2020, 03:03 zheng wang <18031...@qq.com>
> wrote:
> > > > > > >
> > > > > > > > IMO, master is ok if not used with slave together.
> > > > > > > >
> > > > > > > >
> > > > > > > > -1/+1/+1/+1
> > > > > 

Re: [DISCUSS] Removing problematic terms from our project

[Sean Busbey]

How about "manager"?

(It would help me if folks could explain what is lacking in "coordinator".)

On Thu, Jun 25, 2020, 13:32 Nick Dimiduk  wrote:

> On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
> wrote:
>
> > -0/+1/+1/+1
> >
> > I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
> > the private list.
> >
> > I’m still not convinced that it is really necessary and I do not think
> > other words like ‘coordinator’ can fully describe the role of HMaster in
> > HBase. HBase is more than 10 years old. In the context of HBase, the word
> > ‘HMaster’ has its own meaning. Changing the name will hurt our users and
> > make them confusing, especially for us non native English speakers...
> >
>
> Is there a word that's not "master" and not "coordinator" that is clear and
> suitable for (diverse, polyglot) community?
>
> Stack 于2020年6月25日 周四06:34写道：
> >
> > > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> > > soon after sounds good to me. I'm up for working on this.
> > > S
> > >
> > > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> > >
> > > > Strongly agree with what Nick said here:
> > > >
> > > >  " From my perspective, we gain nothing as a project or as a
> community
> > be
> > > > willfully retaining use of language that is well understood to be
> > > > problematic or hurtful, On the contrary, we have much to gain by
> > > > encouraging
> > > > contributions from as many people as possible."
> > > >
> > > > +1 to Andrew's proposal.
> > > >
> > > > It might be good to have a source of truth web page or README file
> for
> > > > developers and users to refer to regarding all naming transitions.
> It's
> > > > going to help both developers changing the code and users looking for
> > > some
> > > > answers online that use old namings.
> > > >
> > > > Xu
> > > >
> > > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > > wrote:
> > > >
> > > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey 
> wrote:
> > > > >
> > > > > > I would like to make sure I am emphatically clear that "master"
> by
> > > > itself
> > > > > > is not okay if the context is the same as what would normally be
> a
> > > > > > master/slave context. Furthermore our use of master is clearly
> > such a
> > > > > > context.
> > > > >
> > > > >
> > > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > > master/slave
> > > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > > “leader”.
> > > > > Thus we would have daemons called “coordinator” and “region
> server”.
> > > > >
> > > > > To me, “master” as in “master branch” does not carry the same
> > baggage,
> > > > but
> > > > > I’m also in favor changing the name of our default branch to a word
> > > that
> > > > is
> > > > > less conflicted. I see nothing that we gain as a community by
> > > continuing
> > > > to
> > > > > use this word.
> > > > >
> > > > > It seems to me we have, broadly speaking, consensus around making
> > > *some*
> > > > > > changes. I haven't seen a strong push for "break everything in
> the
> > > name
> > > > > of
> > > > > > expediency" (I would personally be fine with this). So barring
> > > > additional
> > > > > > discussion that favors breaking changes, current approaches
> should
> > > > > comport
> > > > > > with our existing project compatibility goals.
> > > > > >
> > > > > > Maybe we could stop talking about what-ifs and look at actual
> > > practical
> > > > > > examples? If anyone is currently up for doing the work of a PR we
> > can
> > > > > look
> > > > > > at for one of these?
> > > > > >
> > > > > > If folks would prefer we e.g. just say "we should break whatever
> we
> > > > need
> > > > > to
> > > > > > in 3.0.0 to make this happen" then it would be good to speak up.
> > > > > Otherwise
> > > > > > likely we would be done with needed changes circa hbase 4,
> probably
> > > > late
> > > > > > 2021 or 2022.
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 23, 2020, 03:03 zheng wang <18031...@qq.com> wrote:
> > > > > >
> > > > > > > IMO, master is ok if not used with slave together.
> > > > > > >
> > > > > > >
> > > > > > > -1/+1/+1/+1
> > > > > > >
> > > > > > >
> > > > > > > -- 原始邮件 --
> > > > > > > 发件人: "Andrew Purtell" > > > > > > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > > > > > > 收件人: "Hbase-User" > > > > > > 抄送: "dev" > > > > > > 主题: Re: [DISCUSS] Removing problematic terms from our
> > project
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > In observing something like voting happening on this thread to
> > > > express
> > > > > > > alignment or not, it might be helpful to first, come up with a
> > list
> > > > of
> > > > > > > terms to change (if any), and then propose replacements,
> > > > individually.
> > > > > So
> > > > > > > far we might break this apart into four proposals:
> > > > > > >
> > > > > > > 1. Replace "master"/"hmaster" with ??? ("coordinator" is one
> > > option),
> > > > > > this
> > > > > > > one has by far the

Re: HBase 2 slower than HBase 1?

[Andrew Purtell]

I repeated this test with pe --filterAll and the results were revealing, at
least for this case. I also patched in thread local hash map for atomic
counters that I could update from code paths in SQM, StoreScanner,
HFileReader*, and HFileBlock. Because a RPC is processed by a single
handler thread I could update counters and accumulate micro-timings via
System#nanoTime() per RPC and dump them out of CallRunner in some new trace
logging. I spent a couple of days making sure the instrumentation was
placed equivalently in both 1.6 and 2.2 code bases and was producing
consistent results. I can provide these patches upon request.

Again, test tables with one family and 1, 5, 10, 20, 50, and 100 distinct
column-qualifiers per row. After loading the table I made a snapshot and
cloned the snapshot for testing, for both 1.6 and 2.2, so both versions
were tested using the exact same data files on HDFS. I also used the 1.6
version of PE for both, so the only change is on the server (1.6 vs 2.2
masters and regionservers).

It appears a refactor to ScanQueryMatcher and friends has disabled the
ability of filters to provide SKIP hints, which prevents us from bypassing
version checking (so some extra cost in SQM), and appears to disable an
optimization that avoids reseeking, leading to a serious and proportional
regression in reseek activity and time spent in that code path. So for
queries that use filters, there can be a substantial regression.

Other test cases that did not use filters did not show a regression.

A test case where I used ROW_INDEX_V1 encoding showed an expected modest
proportional regression in seeking time, due to the fact it is optimized
for point queries and not optimized for the full table scan case.

I will come back here when I understand this better.

Here are the results for the pe --filterAll case:


1.6.0 c1 2.2.5 c1
1.6.0 c5 2.2.5 c5
1.6.0 c10 2.2.5 c10
1.6.0 c20 2.2.5 c20
1.6.0 c50 2.2.5 c50
1.6.0 c100 2.2.5 c100
Counts






















(better heartbeating)
(better heartbeating)
(better heartbeating)
(better heartbeating)
(better heartbeating)
rpcs 1 2 200% 2 6 300% 2 10 500% 3 17 567% 4 37 925% 8 72 900%
block_reads 11507 11508 100% 57255 57257 100% 114471 114474 100% 230372
230377 100% 578292 578298 100% 1157955 1157963 100%
block_unpacks 11507 11508 100% 57255 57257 100% 114471 114474 100% 230372
230377 100% 578292 578298 100% 1157955 1157963 100%
seeker_next 1000 1000 100% 5000 5000 100% 1
1 100% 2 2 100% 5 5 100% 10
10 100%
store_next 1000 9988268 100% 5000 49940082 100% 1 99879401
100% 2 199766539 100% 5 499414653 100% 10 998836518
100%
store_reseek 1 11733 > ! 2 59924 > ! 8 120607 > ! 6 233467 > ! 10 585357 > !
8 1163490 > !



















cells_matched 2000 2000 100% 6000 6000 100% 11000
11000 100% 21000 21000 100% 51000 51000 100% 101000
101000 100%
column_hint_include 1000 1000 100% 5000 5000 100% 1
1 100% 2 2 100% 5 5 100% 10
10 100%
filter_hint_skip 1000 1000 100% 5000 5000 100% 1
1 100% 2 2 100% 5 5 100% 10
10 100%
sqm_hint_done 999 999 100% 998 998 100% 998 998 100%
997 997 100% 996 996 100% 992 992 100%
sqm_hint_seek_next_col 1 0 0% 2 4002 > ! 2 9002 > ! 3 19003 > !
4 49004 > ! 8 99008 > !
sqm_hint_seek_next_row 0 1000 > ! 2 1000 > ! 0 1000 > ! 0
1000 > ! 0 1000 > ! 0 1000 > !
sqm_hint_skip 1000 0 0% 5000 0 0% 1 0 0% 2 0 0%
5 0 0% 10 0 0%
versions_hint_include_and_seek_next_col 0 0 0% 0 4000 > ! 0 9000 > !
0 19000 > ! 0 49000 > ! 0 99000 > !
versions_hint_include_and_seek_next_row 0 0 0% 0 1000 > ! 0 1000 > !
0 1000 > ! 0 1000 > ! 0 1000 > !



















Times




































block_read_ms 174.12 215.96 124% 683.78 883.02 129% 1724.66 1937.87 112%
3199.93 3470.92 108% 7582.96 7941.45 105% 14701.52 16022.57 109%
block_unpack_ms 0.63 0.62 99% 2.35 2.35 100% 4.36 4.56 105% 9.10 8.30 91%
21.59 22.01 102% 40.97 40.93 100%
seeker_next_ms 1073.45 1053.51 98% 4452.52 4728.96 106% 9359.61 9706.06 104%
18879.28 18330.93 97% 47664.95 46404.26 97% 96511.83 92121.30 95%
store_next_ms 2651.11 2423.27 91% 12048.64 11398.63 95% 24833.68 23586.20
95% 48493.26 46574.38 96% 120786.00 115603.00 96% 240627.00 227945.00 95%
store_reseek_ms 2.71 62.17 2297% 10.93 233.67 2139% 10.88 401.88 3693% 13.98
783.18 5601% 22.26 1939.28 8714% 24.32 4065.25 16714%






































Rows=1000

















ValueSize=20

















BlockEncoding=FAST_DIFF

















Compress=NONE
Filter=ALL

Re: [DISCUSS] Removing problematic terms from our project

[Zach York]

+1 for all proposed modifications. Happy to help with the effort as well.

On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
wrote:

> -0/+1/+1/+1
>
> I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
> the private list.
>
> I’m still not convinced that it is really necessary and I do not think
> other words like ‘coordinator’ can fully describe the role of HMaster in
> HBase. HBase is more than 10 years old. In the context of HBase, the word
> ‘HMaster’ has its own meaning. Changing the name will hurt our users and
> make them confusing, especially for us non native English speakers...
>
> Thanks.
>
> Stack 于2020年6月25日 周四06:34写道：
>
> > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> > soon after sounds good to me. I'm up for working on this.
> > S
> >
> > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> >
> > > Strongly agree with what Nick said here:
> > >
> > >  " From my perspective, we gain nothing as a project or as a community
> be
> > > willfully retaining use of language that is well understood to be
> > > problematic or hurtful, On the contrary, we have much to gain by
> > > encouraging
> > > contributions from as many people as possible."
> > >
> > > +1 to Andrew's proposal.
> > >
> > > It might be good to have a source of truth web page or README file for
> > > developers and users to refer to regarding all naming transitions. It's
> > > going to help both developers changing the code and users looking for
> > some
> > > answers online that use old namings.
> > >
> > > Xu
> > >
> > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > wrote:
> > >
> > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
> > > >
> > > > > I would like to make sure I am emphatically clear that "master" by
> > > itself
> > > > > is not okay if the context is the same as what would normally be a
> > > > > master/slave context. Furthermore our use of master is clearly
> such a
> > > > > context.
> > > >
> > > >
> > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > master/slave
> > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > “leader”.
> > > > Thus we would have daemons called “coordinator” and “region server”.
> > > >
> > > > To me, “master” as in “master branch” does not carry the same
> baggage,
> > > but
> > > > I’m also in favor changing the name of our default branch to a word
> > that
> > > is
> > > > less conflicted. I see nothing that we gain as a community by
> > continuing
> > > to
> > > > use this word.
> > > >
> > > > It seems to me we have, broadly speaking, consensus around making
> > *some*
> > > > > changes. I haven't seen a strong push for "break everything in the
> > name
> > > > of
> > > > > expediency" (I would personally be fine with this). So barring
> > > additional
> > > > > discussion that favors breaking changes, current approaches should
> > > > comport
> > > > > with our existing project compatibility goals.
> > > > >
> > > > > Maybe we could stop talking about what-ifs and look at actual
> > practical
> > > > > examples? If anyone is currently up for doing the work of a PR we
> can
> > > > look
> > > > > at for one of these?
> > > > >
> > > > > If folks would prefer we e.g. just say "we should break whatever we
> > > need
> > > > to
> > > > > in 3.0.0 to make this happen" then it would be good to speak up.
> > > > Otherwise
> > > > > likely we would be done with needed changes circa hbase 4, probably
> > > late
> > > > > 2021 or 2022.
> > > > >
> > > > >
> > > > > On Tue, Jun 23, 2020, 03:03 zheng wang <18031...@qq.com> wrote:
> > > > >
> > > > > > IMO, master is ok if not used with slave together.
> > > > > >
> > > > > >
> > > > > > -1/+1/+1/+1
> > > > > >
> > > > > >
> > > > > > -- 原始邮件 --
> > > > > > 发件人: "Andrew Purtell" > > > > > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > > > > > 收件人: "Hbase-User" > > > > > 抄送: "dev" > > > > > 主题: Re: [DISCUSS] Removing problematic terms from our
> project
> > > > > >
> > > > > >
> > > > > >
> > > > > > In observing something like voting happening on this thread to
> > > express
> > > > > > alignment or not, it might be helpful to first, come up with a
> list
> > > of
> > > > > > terms to change (if any), and then propose replacements,
> > > individually.
> > > > So
> > > > > > far we might break this apart into four proposals:
> > > > > >
> > > > > > 1. Replace "master"/"hmaster" with ??? ("coordinator" is one
> > option),
> > > > > this
> > > > > > one has by far the most significant impact and both opinion and
> > > > > > interpretation on this one is mixed.
> > > > > >
> > > > > > 2. Replace "slave" with "follower", seems to impact the cross
> > cluster
> > > > > > replication subsystem only.
> > > > > >
> > > > > > 3. Replace "black list" with "deny list".
> > > > > >
> > > > > > 4. Replace "white list" with "accept list".
> > > > > >
> > > > > > Perhaps if you are inclined to respond with a +1/-1/+0/-0, it
> would
> > > be
>

Re: [DISCUSS] Removing problematic terms from our project

[Nick Dimiduk]

On Wed, Jun 24, 2020 at 10:14 PM 张铎(Duo Zhang) 
wrote:

> -0/+1/+1/+1
>
> I’m the one who asked whether ‘master’ is safe to use without ‘slave’ in
> the private list.
>
> I’m still not convinced that it is really necessary and I do not think
> other words like ‘coordinator’ can fully describe the role of HMaster in
> HBase. HBase is more than 10 years old. In the context of HBase, the word
> ‘HMaster’ has its own meaning. Changing the name will hurt our users and
> make them confusing, especially for us non native English speakers...
>

Is there a word that's not "master" and not "coordinator" that is clear and
suitable for (diverse, polyglot) community?

Stack 于2020年6月25日 周四06:34写道：
>
> > +1/+1/+1/+1 where hbase3 adds the deprecation and hbase4 follows hbase3
> > soon after sounds good to me. I'm up for working on this.
> > S
> >
> > On Wed, Jun 24, 2020 at 2:26 PM Xu Cang  wrote:
> >
> > > Strongly agree with what Nick said here:
> > >
> > >  " From my perspective, we gain nothing as a project or as a community
> be
> > > willfully retaining use of language that is well understood to be
> > > problematic or hurtful, On the contrary, we have much to gain by
> > > encouraging
> > > contributions from as many people as possible."
> > >
> > > +1 to Andrew's proposal.
> > >
> > > It might be good to have a source of truth web page or README file for
> > > developers and users to refer to regarding all naming transitions. It's
> > > going to help both developers changing the code and users looking for
> > some
> > > answers online that use old namings.
> > >
> > > Xu
> > >
> > > On Wed, Jun 24, 2020 at 2:21 PM Nick Dimiduk 
> > wrote:
> > >
> > > > On Tue, Jun 23, 2020 at 13:11 Sean Busbey  wrote:
> > > >
> > > > > I would like to make sure I am emphatically clear that "master" by
> > > itself
> > > > > is not okay if the context is the same as what would normally be a
> > > > > master/slave context. Furthermore our use of master is clearly
> such a
> > > > > context.
> > > >
> > > >
> > > > I agree: to me “Master”, as in “HMaster” caries with it the
> > master/slave
> > > > baggage. As an alternative, I prefer the term “coordinator” over
> > > “leader”.
> > > > Thus we would have daemons called “coordinator” and “region server”.
> > > >
> > > > To me, “master” as in “master branch” does not carry the same
> baggage,
> > > but
> > > > I’m also in favor changing the name of our default branch to a word
> > that
> > > is
> > > > less conflicted. I see nothing that we gain as a community by
> > continuing
> > > to
> > > > use this word.
> > > >
> > > > It seems to me we have, broadly speaking, consensus around making
> > *some*
> > > > > changes. I haven't seen a strong push for "break everything in the
> > name
> > > > of
> > > > > expediency" (I would personally be fine with this). So barring
> > > additional
> > > > > discussion that favors breaking changes, current approaches should
> > > > comport
> > > > > with our existing project compatibility goals.
> > > > >
> > > > > Maybe we could stop talking about what-ifs and look at actual
> > practical
> > > > > examples? If anyone is currently up for doing the work of a PR we
> can
> > > > look
> > > > > at for one of these?
> > > > >
> > > > > If folks would prefer we e.g. just say "we should break whatever we
> > > need
> > > > to
> > > > > in 3.0.0 to make this happen" then it would be good to speak up.
> > > > Otherwise
> > > > > likely we would be done with needed changes circa hbase 4, probably
> > > late
> > > > > 2021 or 2022.
> > > > >
> > > > >
> > > > > On Tue, Jun 23, 2020, 03:03 zheng wang <18031...@qq.com> wrote:
> > > > >
> > > > > > IMO, master is ok if not used with slave together.
> > > > > >
> > > > > >
> > > > > > -1/+1/+1/+1
> > > > > >
> > > > > >
> > > > > > -- 原始邮件 --
> > > > > > 发件人: "Andrew Purtell" > > > > > 发送时间: 2020年6月23日(星期二) 凌晨5:24
> > > > > > 收件人: "Hbase-User" > > > > > 抄送: "dev" > > > > > 主题: Re: [DISCUSS] Removing problematic terms from our
> project
> > > > > >
> > > > > >
> > > > > >
> > > > > > In observing something like voting happening on this thread to
> > > express
> > > > > > alignment or not, it might be helpful to first, come up with a
> list
> > > of
> > > > > > terms to change (if any), and then propose replacements,
> > > individually.
> > > > So
> > > > > > far we might break this apart into four proposals:
> > > > > >
> > > > > > 1. Replace "master"/"hmaster" with ??? ("coordinator" is one
> > option),
> > > > > this
> > > > > > one has by far the most significant impact and both opinion and
> > > > > > interpretation on this one is mixed.
> > > > > >
> > > > > > 2. Replace "slave" with "follower", seems to impact the cross
> > cluster
> > > > > > replication subsystem only.
> > > > > >
> > > > > > 3. Replace "black list" with "deny list".
> > > > > >
> > > > > > 4. Replace "white list" with "accept list".
> > > > > >
> > > > > > Perhaps if you are inclined to respond with a +