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-2893) Table metacolumns
Date Sun, 01 Aug 2010 19:30:16 GMT

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

Andrew Purtell commented on HBASE-2893:
---------------------------------------

bq.  I'm a little concerned that this would be rather disruptive to the code but used by a
very small portion of users.

We anticipate that access control will be a widely used feature if available. 

Impetus for this issue started with considerations for implementing access control. 

However, the adjustable TTL case comes for free if metacolumns are implemented in a more general
manner, and is something that would make life easier for some dev groups I am working with.

One way to address concerns regarding disruption would be to build this -- therefore perhaps
much of security (HBASE-1697 and subtasks) -- on top of coprocessor-style server side extensions
(HBASE-2000 and subtasks). I have been considering this approach. It is compelling to consider
pulling up all of the functional and performance impact to an extension which can be dynamically
loaded per table. The core code is only touched by coprocessor framework changes and the user
has full choice in the matter when taking on anything else. On the other hand, support is
more challenging, perhaps a lot more. First question: "What extensions do you have loaded,
in what combination?" So on balance I recommend _if we agree_ that HBASE-1697 is a core concern,
then it and related changes such as this issue should be in core, not an extension. 

bq. this would break with the pattern of each family able to be processed in isolation

Ack.

bq. So, if reading from a 5 family table (+1 for meta), you'd end up reading the metacolumn
5 times, once for each user family?

No, only one time, anything in the metacolumn for the row retrieved in one read.

bq. Things like the bloom filter check would have to happen during the read, so at a different
level than it's currently done.

At the Region level, yes, for the metacolumn case. So an access to a row in the Region would
trigger a read of the metacolumn and then caching of the result to be passed around. Exactly
how this would be passed around is unsettled. One option is thread locals. 

This is part of a larger issue related to the security work, that of creating a context (for
access control) and then referencing it wherever an authoritative decision must be made. We
have been debating if to use JAAS or instead sprinkle around access checks by hand. The issue
of building context and passing it around must be dealt with to implement security. If we
have it, then passing around KVs read from metacolumns is straightforward. 

bq. Or if you have these very specific and fine-grained settings like variable TTL you would
implement them in your application.

... and then lose a feature -- automatic TTL based expiration and garbage collection with
single-table scale out properties -- that makes use of HBase compelling as opposed to something
else. (Not sure what, if anything, that something else would be.)

bq. I guess it's less clear why you couldn't break stuff up into separate tables for varied
TTLs or multi-tenancy.

Yes, that's the problem. Single table multitenancy has better scale out properties than per-user
tables, and in the HBase case, 1M+ tables for 1M+ users is not tenable. 

For the variable TTL case, consider an event logging application designed to archive data
for long periods of time, but the different event types have different lifetimes, and lifetimes
may be adjusted over time (updated system design). If a bunch of tables, this requires a join,
which HBase does not support. So what you would do is set up column families to each serve
as a TTL bucket ("join" over column families). Events could only have the TTL of one of the
buckets. Application would store into appropriate column family according to TTL. But this
then results in a wide schema, with resulting unnecessary reduction in I/O locality in access
patterns, more store files than otherwise, and so on. Design changes require adding or modifying
column families, taking the table offline, at least for now. Not necessarily a fatal problem
if we can avoid taking the table offline _ever_ after the master rewrite, but if we already
have per-row overrides for ACLs then this straightforwardly extends to the TTL case (at least)
and that's enough I think to make this problem go away. 

bq. Would Put be extended with per-row setTTL, setACL methods now?

I would recommend that, yes. The metacolumn is a column family like any other; to set stuff,
put values as KVs into the Put to be stored directly. Convenience functions on Put are desirable
so the user doesn't have to learn about the value formatting for various overrides. 

So add to this:

bq. It would be accessible like any other column family, but we expect a default ACL that
only allows access by the system and operator principals

and any principal the table creator adds to the ACL. 

bq. Out of curiosity, which BT-like systems support per-value ACLs?

It's a rumor. I'll try to find out more. 


> Table metacolumns
> -----------------
>
>                 Key: HBASE-2893
>                 URL: https://issues.apache.org/jira/browse/HBASE-2893
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Andrew Purtell
>
> Some features like TTLs or access control lists have use cases that call for per-value
configurability. 
> Currently in HBase TTLs are set per column family. This leads to potentially awkward
"bucketing" of values into column families set up to accommodate the common desired TTLs for
all values within -- an unnecessarily wide schema, with resulting unnecessary reduction in
I/O locality in access patterns, more store files than otherwise, and so on.
> Over in HBASE-1697 we're considering setting ACLs on column families. However, we are
aware of other BT-like systems which support per-value ACLs. This allows for multitenancy
in a single table as opposed to really requiring tables for each customer (or, at least column
families). The scale out properties for a single table are better than alternatives. I think
supporting per-row ACLs would be generally sufficient: customer ID could be part of the row
key. We can still plan to maintain column-family level ACLs. We would therefore not have to
bloat the store with per-row ACLs for the normal case -- but it would be highly useful to
support overrides for particular rows. So how to do that?
> I propose to introduce _metacolumns_. 
> A _metacolumn_ would be a column family intrinsic to every table, created by the system
at table create time.  It would be accessible like any other column family, but we expect
a default ACL that only allows access by the system and operator principals, and would function
like any other, except administrative actions such as renaming or deletion would not be allowed.
 Into the metacolumn would be stored per-row overrides for such things as ACLs and TTLs. The
metacolumn therefore would be as sparse as possible; no storage would required for any overrides
if a value is committed with defaults. A reasonably sparse metacolumn for a region may fit
entirely within blockcache. It may be possible for all metacolumns on a RS to fit within blockcache
without undue pressure on other users. We can aim design effort at this target. 
> The scope of changes required to support this is:
> - Introduce metacolumn concept in the code and into the security model (default ACL):
A flag in HCD, a default ACL, and a few additional checks for rejecting disallowed administrative
actions.
> - Automatically create metacolumns at table create time.
> - Consult metacolumn as part of processing reads or mutations, perhaps using a bloom
filter to shortcut lookups for rows with no metaentries, and apply configuration or security
policy overrides if found.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message