[
https://issues.apache.org/jira/browse/ACCUMULO-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573687#comment-13573687
]
Christopher Tubbs commented on ACCUMULO-164:
--------------------------------------------
{quote}
The feature in its simplest sense does conflict with the original idea behind
locality groups, but is that always "bad"? I'm not sure, but it's definitely
different.
{quote}
We've already extended the original idea behind locality groups, by allowing
users to specify more than one column family for a locality group. And, I think
that is definitely not "bad" ("good", even). This is just an easier way to
select multiple families to put in a locality group, based on a common
characteristic (like common prefix).
However, I question why something like "common prefix" should be a desirable
selection mechanism for multiple families in the first place. Not only are (in
the case of the common prefix) these data naturally grouped locally without any
use of locality groups, it's not clear to me that something like "common
prefix" is the most sensible way to group related families in the general case.
I'm not sure there *is* a general case, though. Perhaps len < 4 is more useful
than identifying a common prefix for some users? Further, the only application
for this, that I can think of, is when users introduce variability into the
family that allows the number of distinct families to grow continuously (which,
I think can be, and should be, done in the qualifier instead). So, I personally
see little benefit to it (at least, for the common prefix case; though full
regexes or suffixes would certainly have greater benefit).
Maybe the most useful, and general, thing we could do to provide users the most
utility to select families for a locality group, is to allow users to inject a
user-defined hash function (maybe in JEXL?) to bin families into discrete
localities by the arbitrary method of their choosing?
{quote}
Do you have any ideas on how to present such a feature that would avoid
steering the common user toward it? Is healthy warning/documentation sufficient?
{quote}
If implemented, I think documentation should be sufficient to address all of my
concerns. The main thing is just make it clear that the feature is used to
*select* multiple column families, so that it's not implied that families with
variability *are* the same "family". The API treats non-equal families as
distinct, and that's how we should discuss them.
> Add support for wildcards/regexes in locality group setting.
> ------------------------------------------------------------
>
> Key: ACCUMULO-164
> URL: https://issues.apache.org/jira/browse/ACCUMULO-164
> Project: Accumulo
> Issue Type: Improvement
> Components: client, master, tserver
> Reporter: John Vines
> Fix For: 1.6.0
>
>
> We should look into adding the ability to specify locality group columns as
> either wildcarding or regexes. I'm unsure of the feasibility of this, hence
> the lack of fix date.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
