Bonne remarque sur les annuaires LDAP. Eux ont la vie plus facile que les SGBD dans la mesure ou leur ratio lecture/écriture est censé être bien plus important (normalement) ; délayer un brin la vitesse d'écriture pour gagner en redondance est censé être un compromis généralement acceptable, dans le cas d'un annuaire.
D'autant que si les écritures sont vraiment nombreuses, il y a d'autres solutions que le multimaster horizontal/non hiérarchisé : le protocole supporte le fait de rediriger les écritures (et aussi les lectures, en fait) sur des parties de l'arbre vers divers serveurs dédiés. En gros, le "sharding" est prévu d'emblée, c'est mignon tout plein.
> D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend
> de stockage des données ([...]). Dans le cas le plus courant, il s'agit de bases Berkeley, et
> la réplication est faite au niveau ldap [...]
(sans rapport immédiat avec le commentaire parent, car effectivement dans le cas d'utilisation décrit, la réplication applicative native est bien plus judicieuse).
[^] # Re: et les annuaires ?
Posté par herodiade . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 2.
D'autant que si les écritures sont vraiment nombreuses, il y a d'autres solutions que le multimaster horizontal/non hiérarchisé : le protocole supporte le fait de rediriger les écritures (et aussi les lectures, en fait) sur des parties de l'arbre vers divers serveurs dédiés. En gros, le "sharding" est prévu d'emblée, c'est mignon tout plein.
> D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend
> de stockage des données ([...]). Dans le cas le plus courant, il s'agit de bases Berkeley, et
> la réplication est faite au niveau ldap [...]
J'en profite pour signaler, parce que c'est un fait souvent peu connu, que BDB dispose de fonctionnalités de réplication :
http://www.oracle.com/technology/documentation/berkeley-db/d(...)
(sans rapport immédiat avec le commentaire parent, car effectivement dans le cas d'utilisation décrit, la réplication applicative native est bien plus judicieuse).