[Date Prev][Date Next]
Re: Large user bases cause huge number of roleOccupant in role organizationalRole
Good Morning from Switzerland. Thanks for your quick reply!
I am agree with you, the schema design is wrong from the beginning. I
would like to change it from organizationalRole (static group) to
"groupOfURLs + Dynamic Lists overlay" (dynamic group).
What are your opinions or suggestions for such a migration?
On 24/03/17 20:25, Howard Chu wrote:
Huang Hongfu wrote:
In a general design, we have a role, which is an object of
Within this role, let us say it will have more than 10 million users.
user has a roleOccupant in the role object.
You can imagine how huge this role object can be! This will cause a big
performance problem. Especially with LMDB as backend, the "add new
become very slow at some point; and the replication will be very
even we setup a delta (with accesslog and session log) replication.
From my point of view, organizationalRole is not designed for large
Or someone has a better idea?
The same logic as used in indexing applies here - it is stupid to
define a case for something that matches the majority of your
population. I.e., it's stupid to define a presence index on an
attribute if that attribute occurs in the majority of your entries. It
is stupid to define a group or role if the majority of entries will be
a member of it. A presence index is only useful if the attribute
occurs rarely. A group/role is only useful if the members are a
minority of the total population.
In this case you should define a group/role for all users who *aren't*
part of the majority.
Meanwhile, for people with stupid data models, performance with large
attributes in back-mdb is greatly improved in OpenLDAP 2.5.
Hongfu Huang, Senior System Engineer
MSc in Computer Science
We're the tech in Fintech: www.adnovum.ch/fintech
AdNovum Informatik AG
Wengistrase 7, 8005 Zurich, Switzerland
phone +41 44 272 6111, Direct: +41 44 270 5266
Locations: Zurich (HQ), Bern, Budapest, Ho Chi Minh City, Singapore