Huang Hongfu wrote:
Hello,
In a general design, we have a role, which is an object of organizationalRole. Within this role, let us say it will have more than 10 million users. Each 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 user" will become very slow at some point; and the replication will be very difficult even we setup a delta (with accesslog and session log) replication.
From my point of view, organizationalRole is not designed for large user bases.
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.
Dear Howard,
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?
Best regards
Hongfu
On 24/03/17 20:25, Howard Chu wrote:
Huang Hongfu wrote:
Hello,
In a general design, we have a role, which is an object of organizationalRole. Within this role, let us say it will have more than 10 million users. Each 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 user" will become very slow at some point; and the replication will be very difficult even we setup a delta (with accesslog and session log) replication.
From my point of view, organizationalRole is not designed for large user bases.
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.
openldap-technical@openldap.org
-
Howard Chu -
Huang Hongfu