[
https://issues.apache.org/jira/browse/HBASE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878116#action_12878116
]
HBase Review Board commented on HBASE-2468:
-------------------------------------------
Message from: "Mingjie Lai" <[email protected]>
bq. On 2010-06-10 08:53:41, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/client/HConnection.java, line 235
bq. > <http://review.hbase.org/r/98/diff/5/?file=941#file941line235>
bq. >
bq. > +1 on collapsing with a boolean. setRegionCachePrefetch(table,
enable)? Seems self descriptive and with a couple lines of javadoc should be
clear.
yes sir. will modify to use set...() and get...().
bq. On 2010-06-10 08:53:41, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/client/HTable.java, line 1079
bq. > <http://review.hbase.org/r/98/diff/5/?file=943#file943line1079>
bq. >
bq. > I guess these are static because of how HTables all share a single
HCM per conf. The setting of prefetching is set at the HCM level not the
HTable level, however clients are usually not exposed to HCM and only deal with
HTable.
bq. >
bq. > We should probably make it clear in the javadoc for these methods
that they apply to all HTable instances, though that may be clear from being
static.
bq. >
bq. > Maybe since these are more advanced calls, they shouldn't be in
HTable? If we provide proper documentation, it should be easy enough for a
user to grab the HCM and apply the config at that level?
bq. I guess these are static because of how HTables all share a single HCM per
conf...
Yes.
bq. Maybe since these are more advanced calls, they shouldn't be in HTable?
Two alternatives:
1) HCM: as jgray said, ``however clients are usually not exposed to HCM and
only deal with HTable.''
2) HBaseAdmin: it is a more reasonable design choice since these operation are
at HCM level.
3) or, make it a configuration. It would be one global configuration applied to
all tables, and cannot be changed dynamically.
I like 2) better, but not really sure whether we want to expose it there or
not.
What do you think?
- Mingjie
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/98/#review176
-----------------------------------------------------------
> 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.
