[
https://issues.apache.org/jira/browse/OAK-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175376#comment-15175376
]
angela commented on OAK-3933:
-----------------------------
btw: supported for huge mv-properties was an explicit non-goal for oak... since
i mentioned the usage in membership this also applies for membership i'd say...
non-goal of oak and thus really just an improvement
http://markmail.org/message/ak7g3mq37kj6hxyw
> potential improvements to membership management
> -----------------------------------------------
>
> Key: OAK-3933
> URL: https://issues.apache.org/jira/browse/OAK-3933
> Project: Jackrabbit Oak
> Issue Type: Epic
> Components: core
> Reporter: Julian Reschke
> Assignee: angela
>
> Membership information of a group currently is stored as an unsorted set of
> IDs, spread over multiple child nodes, using multivalued properties (of 1000
> each).
> This content structure makes certain operations relatively slow:
> 1) Checking for declared membership
> When the authorizable to be checked is not a member, all child nodes need to
> be read and examined (in the other case, checking stops when a match is
> found).
> 2) Checking for inherited membership
> The membership IDs do not reveal the type of authorizable. In order to check
> inherited membership as well, the authorizable with the given ID needs to be
> read from storage in order to check the type.
> Below are a few ideas how this might be improved (however, the change of
> structure would require a mgiration step).
> 1) Avoid having to read all child nodes to check declared membership
> Assuming an alphanumeric ID structure, this could be achieved my modifying
> the structure like that:
> - as before, start with a single node
> - when a new member needs to be inserted and the candidate node is already
> full (has 1000 entries), create a new child node named after the first
> character of the authorizable ID
> - when this "level 1" member is full, start using "level 2" members and so on
> (assuming the ID structure is suitable for that, otherwise a different hash
> could be used)
> To check for membership, we wouldn't need to read *all* child nodes, but only
> those where the node name is a prefix match of the ID.
> 2) Avoid having to instantiate authorizables for declared membership checks
> - put limited type information into the stored IDs, such as "u" and "g"
> prefixes; that way the code could identify authorizables that are users and
> avoid having to instantiate them
> (this assumes that an ID that refers to a user will never refer to a group in
> the future)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
