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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
