hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4441) Revisit QOS
Date Mon, 19 Sep 2011 19:10:11 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108066#comment-13108066
] 

Andrew Purtell commented on HBASE-4441:
---------------------------------------

bq. Do we want to support different priorities for different tables/users (when security's
enabled)/operations?

I've been thinking about this lately too. I think we do. For managing policy that maps pretty
well to security (users and groups), hierarchical token bucket could be a reasonable option.

Admission control across the whole cluster is a larger challenge. How does QoS at the HBase
layer translate to QoS at the HDFS layer (or not)? Should accesses from a MapReduce job have
a different priority than direct API access?

> Revisit QOS
> -----------
>
>                 Key: HBASE-4441
>                 URL: https://issues.apache.org/jira/browse/HBASE-4441
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.94.0
>
>
> Currently we have a simple QOS model where requests to user tables are using one set
of handlers and requests to catalog tables and other administrative functions are using another
set. I'm wondering if it's worth expending this model:
>  - Do we want to support different priorities for different tables/users (when security's
enabled)/operations?
>  - Do we want finer granularity?
> There's also issues like HBASE-4280 that exposes a case where RS communicate between
each other and can potentially deadlock if some slowness is going on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message