#2597 Add index for 'objectSIDString' and maybe to other cache attributes
Closed: Fixed None Opened 4 years ago by sbose.

Groups a looked up by 'objectSIDString' e.g. during a tokenGroups lookup which is used in the AD provider and in IPA server with trust to AD. Indexing this value would speed up cache lookup, especially for users with many groups and save processing time.

Maybe other attributes would benefit from an index as well?


Fields changed

description: Groups a looked up by 'objectSIDString' e.g. during a tokenGroups lookup which is used in the AD provider and in IPA server with trust to AD. Indexing this value would speed up cache lookup, especially for users with many groups and save processing time.

Maybe other attributes would benefit from an indes as well? => Groups a looked up by 'objectSIDString' e.g. during a tokenGroups lookup which is used in the AD provider and in IPA server with trust to AD. Indexing this value would speed up cache lookup, especially for users with many groups and save processing time.

Maybe other attributes would benefit from an index as well?

We should also index the principal attributes, NSS responder uses those to search as well.

Michal, your FQDN refactoring patches need a sysdb upgrade, right? Then maybe we should do the indexing in the same sysdb upgrade to avoid running two upgrade routines..

cc: => mzidek@redhat.com

Yes, that makes sense. I will assign the ticket to me.

owner: somebody => mzidek

Lot of indexes can cause problem with insert, delete.
It would be good to measure result of this change with
"almost" real deployment.

when you say "problems", do you mean delays or issues like broken indexes and missing entries in the index?

I meant that updating many indexes can decrease performance of insert/delete ldb entry. So adding index for 'objectSIDString' might help but adding many attributes can be problematic.

We will need to test performance of this change many AD groups and users.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 alpha

internal only change, no cloning

rhbz: => 0

I think this should be moved to the same milestone as this ticket
#2011 sysdb API is not consistent about the RDN of subdomain users
because it will require sysdb upgrade.

sensitive: => 0

We were wondering with Sumit if it would be possible to not do an upgrade if only the index is added. On upgrade (which is rare) we could fall back to unindexed searches.

I am not sure what will happen if the indexation for an attribute is set after some entries with that attribute are already present in the database... I do not think that LDB will automatically add missing indexes for the entries (which is why I thought the update is needed here), but that is just my guess, I will have to try it and see.

Should not block Alpha

milestone: SSSD 1.13 alpha => SSSD 1.13 beta

Should not block Beta either.

milestone: SSSD 1.13 beta => SSSD 1.13

I had to write the indexing patch because one user was not satisfied with adding the index manually:

https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/commit/?h=sid_index&id=2302b7f53869db17fe6f733f52cce94d9714eeb4

Feel free to use the patch.

Fields changed

milestone: SSSD 1.13.2 => SSSD 1.13.1
owner: mzidek => jhrozek
priority: major => critical
status: new => assigned

Fields changed

patch: 0 => 1

resolution: => fixed
status: assigned => closed

Metadata Update from @sbose:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.13.1

2 years ago

Login to comment on this ticket.

Metadata