Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        apurtell Andrew Purtell added a comment -

        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?

        Show
        apurtell Andrew Purtell added a comment - 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?
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Moving out of 0.94.

        Show
        lhofhansl Lars Hofhansl added a comment - Moving out of 0.94.
        Hide
        stack stack added a comment -

        Moving unassigned feature out of 0.95

        Show
        stack stack added a comment - Moving unassigned feature out of 0.95
        Hide
        stack stack added a comment -

        This is old. We have some prioritization going on now based off annotations, whether system table, type of request... (if superuser)....

        Show
        stack stack added a comment - This is old. We have some prioritization going on now based off annotations, whether system table, type of request... (if superuser)....

          People

          • Assignee:
            Unassigned
            Reporter:
            jdcryans Jean-Daniel Cryans
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development