HBase
  1. HBase
  2. HBASE-4612

Allow ColumnPrefixFilter to support multiple prefixes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 0.90.4
    • Fix Version/s: 0.94.0
    • Component/s: Filters
    • Labels:
      None

      Description

      When having a lot of columns grouped by name I've found that it would be very useful to be able to scan them using multiple prefixes, allowing to fetch specific groups in one scan, without fetching the entire row. This is impossible to achieve using a FilterList, so I've added such support to the existing ColmnPrefixFilter while keeping backward compatibility.
      The attached patch is based on 0.90.4, I noticed that the 0.92 branch has a new method to support instantiating filters using Thrift. I'm not sure how the serialization works there so I didn't implement that, but the rest of my code should work in 0.92 as well.

      1. HBASE-4612-0.90.patch
        7 kB
        Eran Kutner
      2. HBASE-4612.patch
        7 kB
        Eran Kutner

        Activity

        Hide
        Jonathan Gray added a comment -

        Hey Eran. Thanks for the contribution! A few comments..

        • There's no explanation of the behavior anywhere. In the constructors and addPrefix() methods, you should document that this creates an OR condition across all of the prefixes, correct?
        • No need to instantiate a new comparator all the time (use Bytes.BYTES_COMPARATOR)
        • Something seems odd when you keep adding to the end of a List and then sort. How about a TreeSet? You can easily ignore dupes that way.
        • There's no input verification so, for example, you could pass a null to the constructor or an empty byte[][] and have some strange behavior. Like it will instantiate okay but then you'll get server-side NPEs or IOOB.
        • this.prefixes.size() == 0 -> this.prefixes.isEmpty()
        • your comment at the top of filterColumn, i wouldn't exactly call it a workaround, but it's a good comment. looking at the logic, it seems like correct behavior would be that it can be called with current == size() but it would be a bug if current > size(), right? should you add an assert or throw an exception?
        Show
        Jonathan Gray added a comment - Hey Eran. Thanks for the contribution! A few comments.. There's no explanation of the behavior anywhere. In the constructors and addPrefix() methods, you should document that this creates an OR condition across all of the prefixes, correct? No need to instantiate a new comparator all the time (use Bytes.BYTES_COMPARATOR) Something seems odd when you keep adding to the end of a List and then sort. How about a TreeSet? You can easily ignore dupes that way. There's no input verification so, for example, you could pass a null to the constructor or an empty byte[][] and have some strange behavior. Like it will instantiate okay but then you'll get server-side NPEs or IOOB. this.prefixes.size() == 0 -> this.prefixes.isEmpty() your comment at the top of filterColumn, i wouldn't exactly call it a workaround, but it's a good comment. looking at the logic, it seems like correct behavior would be that it can be called with current == size() but it would be a bug if current > size(), right? should you add an assert or throw an exception?
        Hide
        Ted Yu added a comment -

        Improvements go to TRUNK.
        @Eran:
        Please prepare patch for TRUNK and run test suite.

        Nice work.

        Show
        Ted Yu added a comment - Improvements go to TRUNK. @Eran: Please prepare patch for TRUNK and run test suite. Nice work.
        Hide
        Eran Kutner added a comment -

        Hi Jonathan, thanks for the feedback! See answers inline:

        There's no explanation of the behavior anywhere. In the constructors and addPrefix() methods, you should document that this creates an OR condition across all of the prefixes, correct?

        - good point, added some more explanations.

        No need to instantiate a new comparator all the time (use Bytes.BYTES_COMPARATOR)

        - Didn't know it existed. Changed.

        Something seems odd when you keep adding to the end of a List and then sort. How about a TreeSet? You can easily ignore dupes that way.

        - This is intentional. Sorting is done only during initialization but accessing a ArrayList, which is actually based on an array, is much more efficient than accessing a tree, so I sacrifice the aesthetics of the code for better runtime performance.

        There's no input verification so, for example, you could pass a null to the constructor or an empty byte[][] and have some strange behavior. Like it will instantiate okay but then you'll get server-side NPEs or IOOB.

        - it's a good point but I've looked and no other filter is validating its input either. I can throw a InvalidArgumentException but don't know if it's a good idea considering it's not the norm.

        this.prefixes.size() == 0 -> this.prefixes.isEmpty()

        - ok, changed.

        your comment at the top of filterColumn, i wouldn't exactly call it a workaround, but it's a good comment. looking at the logic, it seems like correct behavior would be that it can be called with current == size() but it would be a bug if current > size(), right? should you add an assert or throw an exception?

        - well it is kind of a workaround, because as an individual filter I expect not be called again after returning NEXT_ROW, however, when used with FilterList the filter does get called again which puts it in an ilegal state, so it has to explicitly handle that case. That is also why it can't throw an exception in that scenario, because it seems to be happening normally when used with FilterList. as for "current" it has to be smaller than size() or it would be outside the bounds of the array.

        Show
        Eran Kutner added a comment - Hi Jonathan, thanks for the feedback! See answers inline: There's no explanation of the behavior anywhere. In the constructors and addPrefix() methods, you should document that this creates an OR condition across all of the prefixes, correct? - good point, added some more explanations. No need to instantiate a new comparator all the time (use Bytes.BYTES_COMPARATOR) - Didn't know it existed. Changed. Something seems odd when you keep adding to the end of a List and then sort. How about a TreeSet? You can easily ignore dupes that way. - This is intentional. Sorting is done only during initialization but accessing a ArrayList, which is actually based on an array, is much more efficient than accessing a tree, so I sacrifice the aesthetics of the code for better runtime performance. There's no input verification so, for example, you could pass a null to the constructor or an empty byte[][] and have some strange behavior. Like it will instantiate okay but then you'll get server-side NPEs or IOOB. - it's a good point but I've looked and no other filter is validating its input either. I can throw a InvalidArgumentException but don't know if it's a good idea considering it's not the norm. this.prefixes.size() == 0 -> this.prefixes.isEmpty() - ok, changed. your comment at the top of filterColumn, i wouldn't exactly call it a workaround, but it's a good comment. looking at the logic, it seems like correct behavior would be that it can be called with current == size() but it would be a bug if current > size(), right? should you add an assert or throw an exception? - well it is kind of a workaround, because as an individual filter I expect not be called again after returning NEXT_ROW, however, when used with FilterList the filter does get called again which puts it in an ilegal state, so it has to explicitly handle that case. That is also why it can't throw an exception in that scenario, because it seems to be happening normally when used with FilterList. as for "current" it has to be smaller than size() or it would be outside the bounds of the array.
        Hide
        Eran Kutner added a comment -

        @Ted:

        Improvements go to TRUNK.

        I know but see my initial comment regarding the new Thrift initialization method, I'm just not sure how it's supposed to work or what am I supposed to do there.

        Show
        Eran Kutner added a comment - @Ted: Improvements go to TRUNK. I know but see my initial comment regarding the new Thrift initialization method, I'm just not sure how it's supposed to work or what am I supposed to do there.
        Hide
        Ted Yu added a comment -

        As far as HBASE-4176 is concerned, take a look at this in TRUNK:

          public static Filter createFilterFromArguments(ArrayList<byte []> filterArguments) {
            Preconditions.checkArgument(filterArguments.size() == 1,
                                        "Expected 1 but got: %s", filterArguments.size());
            byte [] columnPrefix = ParseFilter.removeQuotesFromByteArray(filterArguments.get(0));
            return new ColumnPrefixFilter(columnPrefix);
          }
        

        You can relax the check above and call filterArguments.toArray() so that the new ctor can be used.

        Show
        Ted Yu added a comment - As far as HBASE-4176 is concerned, take a look at this in TRUNK: public static Filter createFilterFromArguments(ArrayList< byte []> filterArguments) { Preconditions.checkArgument(filterArguments.size() == 1, "Expected 1 but got: %s" , filterArguments.size()); byte [] columnPrefix = ParseFilter.removeQuotesFromByteArray(filterArguments.get(0)); return new ColumnPrefixFilter(columnPrefix); } You can relax the check above and call filterArguments.toArray() so that the new ctor can be used.
        Hide
        Eran Kutner added a comment -

        OK, I uploaded a patch for trunk, hopefully what I've done with the createFilterFromArguments method makes sense.

        Show
        Eran Kutner added a comment - OK, I uploaded a patch for trunk, hopefully what I've done with the createFilterFromArguments method makes sense.
        Hide
        Ted Yu added a comment -

        +1 on HBASE-4612.patch, assuming test suite passes.

        Nice work Eran.

        Show
        Ted Yu added a comment - +1 on HBASE-4612 .patch, assuming test suite passes. Nice work Eran.
        Hide
        Lars Hofhansl added a comment -

        We have MultipleColumnPrefixFilter (in trunk at least), which does exactly what is described here.
        Is this different?

        Show
        Lars Hofhansl added a comment - We have MultipleColumnPrefixFilter (in trunk at least), which does exactly what is described here. Is this different?
        Hide
        Lars Hofhansl added a comment -

        I am closing this, because we already have MultipleColumnPrefixFilter.
        Please reopen if I misunderstood.

        Show
        Lars Hofhansl added a comment - I am closing this, because we already have MultipleColumnPrefixFilter. Please reopen if I misunderstood.

          People

          • Assignee:
            Eran Kutner
            Reporter:
            Eran Kutner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development