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/