[
https://issues.apache.org/jira/browse/HBASE-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894420#action_12894420
]
Jonathan Gray commented on HBASE-2893:
--------------------------------------
I would be for trying to get this and stuff like it into a coprocessor-style
implementation where we have a constant overhead moving forward to check for
the existence of these things, but then any overhead introduced by these new
features does not impact non-users.
I'm sure DAC is something people will use, just like it's something people use
in mysql, but I imagine it will be used less-so than it is in that context
(given how many applications are not multi-tenant or user-facing). And then
with those users that do take advantage, I doubt they will have 1M users or
will need this granularity of security. So while I definitely see lots of
value in DAC I don't necessarily see this specific feature as a requirement for
most of that value to most users. Having said that, I think this is cool and
worth exploring, just seems significantly more disruptive to implement DAC via
metacolumns than just through family meta data.
Would the plan be to do the DAC/ACL stuff without this and then add it? Or
would this be a required piece of any implementation?
> 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.
