Directory Services vs. Relationale Datenbanken

Directory Services vs. Relationale Datenbanken
LDAP und das relationale Datenbankmodell
LDAP im Schnelldurchlauf
•
•
•
•
Wald von Bäumen aus Knoten
Jeder Knoten hat mindestens die Attribute dn, objectClass
Attribute sind ein- oder mehrwertig, haben Syntax (Typ)
Besonderes mehrwertiges Attribut objectClass bestimmt, welche
Attribute vorhanden sind MÜSSEN und DÜRFEN
• Einwertiges Attribut dn enthält den Pfad durch den Baum und ist
Schlüssel (PK)
LDAP-Baum
dn: o=company, c=de
objectClass: top
dn: ou=personen, o=company, c=de
objectClass: top, organisationalUnit
Container für Personen-Objekte
dn: pk=4711, ou=personen, o=company, c=de
objectClass: top, person, inetOrgPerson, posixAccount
pk: 4711
cn: Vorname Nachname
Copyright ©2002 by NetUSE AG
dn: ou=Ressources, o=company, c=de
objectClass: top, organizationalUnit
Container für Ressourcen
dn: pk=0815, ou=personen, o=company, c=de
objectClass: top, person, inetOrgPerson, posixAccount
pk: 0815
sn: Vorname2 Nachname2
2
SQL im Schnelldurchlauf
• Datenbank als Kollektion von
Tabellen, Tabellen als
Kollektion von Spalten,
Spalten haben Typen
• Spalten sind NULL, NOT
NULL. Spalten sind
einwertig.
• Eine Spalte oder Gruppe von
Spalten ist der PK.
Copyright ©2002 by NetUSE AG
3
SQL Operationen
• SQL erlaubt komplexe
Operationen auf Tabellen:
– Selektion (WHEREClause) wählt Zeilen
– Projektion (Spaltenliste)
wählt Spalten
– Aggregation (GROUP
BY-Clause) erlaubt
Zählungen
– Join erlaubt
Tabellenverknüpfungen
– Rename erlaubt SelfJoins und damit rekursive
Strukturen (Bäume etc)
Copyright ©2002 by NetUSE AG
4
LDAP Anwendungen
• Authentisierung
– am OS (PAM)
– an der Anwendung
(mod_auth_ldap etc.)
• Konfigurationsdaten
– Netscape Roaming
– sendmail Aliases etc.
• Verzeichnis (Recherche)
– Adreßverzeichnisse
Copyright ©2002 by NetUSE AG
• Characteristika:
– kurze Verbindungen
• connect, query,
disconnect
• connect, disconnect
(authentication only)
– triviale Queries
• Existenzanfragen
• Attributanfragen
(dn, attribut) -> (werte)
• Objektauslesung
(dn) -> (attribute, werte)
5
SQL Anwendungen
• Datenspeicher für
Anwendungsdaten
– Persistente Daten
– Normalisierte Daten
• Business Rules
– Integritätsbedingungen
– Accessfunktionen
• Lockingmechanismen
– Zugriff durch mehrere
Instanzen derselben
Anwendung
– Zugriff durch
verschiedene
Anwendungen
Copyright ©2002 by NetUSE AG
• Characteristika:
– lange Connects mit
vielen Queries
– langlaufende Queries
• Joins
• Sortierungen
• berechnete Werte
– viele Schreiboperationen
• konkurrente
Schreiboperationen ->
Locking
• zusammengesetzte
Schreiboperationen ->
Transaktionen
6
Relationenmodell in Verzeichnisdiensten
• Woher kommen die Daten im Verzeichnis?
– Welches ist das führende System?
• Wie strukturiere ich den Verzeichnisbaum?
– Nebenbedingungen:
• Replikation
• Naming Attributes
• Wie strukturiere ich meine objectClasses?
– Welche Art von Anfragen wird erwartet?
• Sollte ich nicht doch lieber ein RDBMs nehmen?
Copyright ©2002 by NetUSE AG
7
Häufige Designprobleme in LDAP
• LDAP wird als führende
Datenbank eingesetzt
• LDAP wird stark beschrieben
• LDAP wird konkurrent
beschrieben
• LDAP dynamisch
beschrieben
• Es bestehen abzufragende
Beziehungen zwischen
LDAP-Objekten
• LDAP wird zur
Reportgenerierung
verwendet
Copyright ©2002 by NetUSE AG
• Der LDAP-Bestand wird
hierarchisch strukturiert
• Der LDAP-Bestand muß
hierarchisch strukturiert
werden
8
LDAP wird als führende Datenbank eingesetzt
• LDAP-Attribute haben eine
Syntax (einen Typ)
– Typen sind zahlreich und
im Standard vordefiniert
– Typen sind schwer
erweiterbar
– Integritätsbedingungen
können nicht definiert
werden.
• iPlanet erlaubt Plugins,
die Integrität checken
können.
Copyright ©2002 by NetUSE AG
• Beziehungen zwischen
Objekten sind in LDAP nur
schwer darstellbar und
instabil.
– PK ist immer der dn
– dn's sind jedoch unter
Umständen instabil
– Aliases sind ein
optionales Feature von
LDAP
• Nur Blattknoten können
Aliases sein.
9
LDAP wird stark beschrieben
• LDAP ist als Protokoll für
Leseoperationen optimiert.
• Es existiert noch kein
standardisiertes Bulk-Update
Protokoll.
– In OpenLDAP und
iPlanet ist der LDAPDatenspeicher ein
Sleepycat DB/3.
– In einigen LDAP-Servern
sind Schreiboperationen
ungeschickt
implementiert.
• Flush nach jedem Write.
Copyright ©2002 by NetUSE AG
• Replikation zwischen
Servern skaliert sich nicht
gut bei starken
Schreiboperationen.
– Nicht standarisiert.
– Oft als reguläre
Schreiboperation eines
privilegierten Benutzers
implementiert ("triviale
Implementierung")
• iPlanet kann immerhin
out-of-sync Replica
automatisch neu
aufbauen.
10
LDAP wird konkurrent beschrieben
• LDAP definiert einzelne add
oder modify-Operationen als
atomar.
• LDAP kennt keine Locks und
keine Transaktionen
– Synchronisation und
Konsistenz sind damit
Sache der Anwendung.
Copyright ©2002 by NetUSE AG
11
LDAP wird dynamisch beschrieben
• Viele LDAP-Server
speichern die
Schemadefinition out-ofband
– Externe Dateien, die per
include in die
Serverkonfiguration mit
eingebunden werden.
• Damit ist eine Änderung des
Schema im Betrieb und
durch LDAP unmöglich.
– Dies fördert sehr
entspannte objectClassDefinitionen ("MAY"Inflation)
Copyright ©2002 by NetUSE AG
• Out-of-band
Schemadefinition macht
Introspektion schwierig
– Welche objectClasses
kennt der Server?
Welche Attribute
erlauben und definieren
sie?
12
Beziehungen zwischen LDAP-Objekten
• Der PK in LDAP ist immer
der dn.
– Der dn ist nicht opaque,
sondern hat Struktur:
Pfadinformation.
– Konsequenz: dn's sind
instabil.
• Verschiebt man ein
Objekt im Baum, ändert
sich der dn.
• Damit sind alle
Referenzen auf das
Objekt ungültig.
• LDAP kennt keine JOINOperation
– Prejoined Structures über
Aliases oder andere
Referenzen
• keine dynamisch
zusammengesetzten
Strukturen.
• Aliases sind nicht
generisch (Leaf-Nodes
only).
– iPlanet dn Plugin
Copyright ©2002 by NetUSE AG
13
LDAP wird zur Reportgenerierung verwendet
• LDAP kennt keine
Aggregation
– Reports können nur
durch Durchlesen des
Bestandes erstellt
werden.
• LDAP kennt keine
serverseitigen Funktionen
– Funktionswerte können
nur durch Durchlesen
des Bestandes erstellt
werden.
Copyright ©2002 by NetUSE AG
• LDAP kennt keinen JOIN
– Reports machen oft
Gebrauch von ad-hoc
Beziehungen zwischen
Teilmengen
• ohne Join können diese
nicht effizient generiert
werden.
14
Hierarchische Struktur im LDAP I
• Der PK in LDAP ist immer
der dn.
• Der dn enthält
Strukturinformation.
 Ändert sich die Position
eines Objektes in der
Struktur, ändert sich der PK
dieses Objektes
• Klassischer Fall von nicht
normalisierter Struktur:
• Daten und Struktur nicht
getrennt
Copyright ©2002 by NetUSE AG
• Ein Objekt ist oft Mitglied in
verschiedenen Hierarchien
– Mitarbeiter ist einsortiert
• organisatorisch
("Abteilung 1.3.2")
• räumlich ("Deutschland,
SH, Kiel, Hauptstelle")
• projektbezogen ("IT
Infrastruktur, Netzwerke,
UMTS-Pilot")
– Redundante
Datenhaltung durch nicht
normalisiertes
Datenmodell
15
Hierarchische Struktur im LDAP II
• LDAP erlaubt die
Partitionierung des
Bestandes nur nach
Teilbäumen
– Erzwingt die Bildung von
Hierarchien im Bestand
– Erzwingt damit instabile
dn's
Copyright ©2002 by NetUSE AG
16
Fazit I
• LDAP ist der Teil von X.500,
der "brauchbar" war.
• LDAP verwirft elementare
Erkenntnisse des
relationalen Datenmodells.
• Damit ist auch der
brauchbare Teil von LDAP
aus der Sicht des
Datenbankdesigners
unbrauchbar und gefährlich.
Copyright ©2002 by NetUSE AG
• Der Einsatz von LDAP als
führende Datenbank ist zu
vermeiden.
• LDAP-Bestände sind
möglichst als flache Tabellen
zu strukturieren.
• Nichttriviale Dinge sind mit
LDAP nicht zu realisieren.
• Triviale Dinge sind mit LDAP
schwierig oder gefährlich.
17
Warum dann keine relationalen Systeme?
• Deutschland, 9.00 Uhr:
– 150.000 MA loggen sich
ein.
– Jedes Login ist ein
Connect, gefolgt von
einem Disconnect.
– Jeder Connect erzeugt in
Oracle einen fork, einen
exec und einen 5 MB
schweren Subprozeß
– der dann sofort
weggeworfen wird.
Copyright ©2002 by NetUSE AG
• LDAP als wire-protocol ist
genormt.
• LDAP als query-language ist
unbrauchbar, aber sehr
rigide genormt.
• LDAP ist auf
connect/disconnect
optimiert.
18
Warum dann keine relationalen Systeme?
• MySQL?
– Connect/disconnect
problemlos
– read-mostly
– Replikation
– Hat volle SQL-Syntax
•
•
•
•
•
Selektion
Projektion
Aggregation
Join
Rename
• Als wire protocol nicht
genormt
– aber: Source liegt offen,
GPL bzw. LGPL
• In kommerziellen Clients
nicht unterstützt.
– aber mod_auth_mysql,
PAM usw
• Trivial zu implementieren.
• Kein IETF-Prozeß.
– Speichereffizienter als
iPlanet oder OpenLDAP
Copyright ©2002 by NetUSE AG
19
Und XML?
• LDAP und XML haben strukturell viel gemeinsam
– Rückkehr zu hierarchischen (Datenbank-) Systemen.
– Liste der Nachteile dieser Systeme in Datenbanken
101 nachlesbar.
• Keine führende Datenhaltung in hierarchischen
Systemen!
– Wir haben in den Betrieben für viel Geld diesen Unsinn
gerade ausgerottet und nun kommt er mit wieder. Mit
Macht!
Copyright ©2002 by NetUSE AG
20