[HBASE-25510] Optimize TableName.valueOf from O(n) to O(1). We can get benefits when the number of tables in the cluster is greater than dozens

• Type: Improvement
• Status: Patch Available
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.2.12, 1.4.13, 2.4.1
• Fix Version/s: 3.0.0-beta-2
• Component/s: master, Replication
• External issue URL: https://github.com/apache/hbase/pull/2885
• Assignee: zhuobin zheng
• Reporter: zhuobin zheng
• Created: 15/Jan/21 03:17
• Updated: 16/Dec/23 12:03

Description

Now, TableName.valueOf will try to find TableName Object in cache linearly(code show as below). So it is too slow when we has  thousands of tables on cluster.

// code placeholder
for (TableName tn : tableCache) {
  if (Bytes.equals(tn.getQualifier(), qns) && Bytes.equals(tn.getNamespace(), bns)) {
    return tn;
  }
}

I try to store the object in the hash table, so it can look up more quickly. code like this

// code placeholder
TableName oldTable = tableCache.get(nameAsStr);

 

In our cluster which has tens thousands of tables. (Most of that is KYLIN table). 
We found that in the following two cases, the TableName.valueOf method will severely restrict our performance.
 
Common premise: tens of thousands table in cluster
cause: TableName.valueOf with low performance. (because we need to traverse all caches linearly)
 
Case1. Replication
premise1: one of table write with high qps, small value, Non-batch request. cause too much wal entry

premise2: deserialize WAL Entry includes calling the TableName.valueOf method.

Cause: Replicat Stuck. A lot of WAL files pile up.

 

Case2. Active Master Start up

NamespaceStateManager init should init all RegionInfo, and regioninfo init will call TableName.valueOf.  It will cost some time if TableName.valueOf is slow.
 

Issue Links

• links to: GitHub Pull Request #2885