[
https://issues.apache.org/jira/browse/OAK-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174855#comment-15174855
]
Tobias Bocanegra commented on OAK-3933:
---------------------------------------
wouldn't it make sense to have a generic 'fast-hashset-multivalue-property'
that is backed by the persistence layer? since all the values are unique and a
UUID, that should be certainly optimized. Having support from the persistence
layer would be beneficial than having the application code come up with smart
datastructures.
> potential improvements to membership management
> -----------------------------------------------
>
> Key: OAK-3933
> URL: https://issues.apache.org/jira/browse/OAK-3933
> Project: Jackrabbit Oak
> Issue Type: Improvement
> 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)
