[
https://issues.apache.org/jira/browse/HBASE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877281#action_12877281
]
HBase Review Board commented on HBASE-2468:
-------------------------------------------
Message from: "Todd Lipcon" <t...@cloudera.com>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/98/#review165
-----------------------------------------------------------
Looking good! Just a few notes.
src/main/java/org/apache/hadoop/hbase/client/HConnection.java
<http://review.hbase.org/r/98/#comment813>
I thought we were collapsing these two calls into
setRegionCachePrefetchEnabled(tableName, enabled)?
src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
<http://review.hbase.org/r/98/#comment816>
I don't entirely understand why we key these hashes by integer, but it
seems like you're following the status quo, so doesn't need to be addressed in
this patch.
src/main/java/org/apache/hadoop/hbase/client/HTable.java
<http://review.hbase.org/r/98/#comment822>
I still don't quite understand the logic about why these should be static.
Previously you pointed to the enable/disable calls, but those are more like
admin calls, not calls that affect client behavior. Anyone else have an opinion?
src/main/java/org/apache/hadoop/hbase/client/MetaScanner.java
<http://review.hbase.org/r/98/#comment823>
I think this should be Math.max(rowLimit, configuration.getInt(...)) - if
we only want to scan 5 rows, we don't want the scanner to prefetch 100 for us.
- Todd
> Improvements to prewarm META cache on clients
> ---------------------------------------------
>
> Key: HBASE-2468
> URL: https://issues.apache.org/jira/browse/HBASE-2468
> Project: HBase
> Issue Type: Improvement
> Components: client
> Reporter: Todd Lipcon
> Assignee: Mingjie Lai
> Fix For: 0.21.0
>
> Attachments: HBASE-2468-trunk.patch
>
>
> A couple different use cases cause storms of reads to META during startup.
> For example, a large MR job will cause each map task to hit meta since it
> starts with an empty cache.
> A couple possible improvements have been proposed:
> - MR jobs could ship a copy of META for the table in the DistributedCache
> - Clients could prewarm cache by doing a large scan of all the meta for the
> table instead of random reads for each miss
> - Each miss could fetch ahead some number of rows in META
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
