Erste Seite Zurück Weiter Letzte Seite Übersicht Grafik
Clustered Indizes
Notizen:
Als weitere wichtige Möglichkeit sei noch der so genannte Clustered Index (gruppierter Index) erwähnt. Vorweg genommen sei: Wenn Ihr DBMS clustered Indizes unterstützt, so sollte jede Tabelle einen bekommen. Üblicherweise ist das derjenige, auf dem die meisten Anfragen (Joins berücksichtigen!) zu erwarten sind. Der Grund ist offensichtlich: Dadurch, dass sich das DBMS darauf verlassen kann, dass die Tabelle sortiert ist, kann der Index wesentlich weniger Seiten enthalten (siehe Folie). Etwas salopp formuliert kann man sich das so vorstellen, dass die vorletzte Ebene des Indexbaums direkt die Datenseiten referenziert (ein Bild, das allerdings nur ungefähr stimmt). Natürlich kann es pro Tabelle nur einen clustered Index geben, denn der clustered Index bestimmt ja die Sortierreihenfolge. Und die Datensätze einer Tabelle können nun einmal nur in einer Reihenfolge sortiert sein. Viele DBMS – so auch der MS SQL Server – vergeben einfach für den Primary Key einen clustered Index. In vielen Situationen ist das auch gar nicht schlecht, aber im Grunde sollte der Administrator denjenigen Index gruppieren, auf dem er wie gesagt die meisten Anfragen erwartet. Das muss nicht zwingend der Imdex des Primary Key sein!
Clustered Indizes können unter Umständen auch eine bestimmte Art von Performanceproblem lösen: den so genannten Traffic Jam. So ein Traffic Jam (oder Hot Spot) kann in folgender Situation auftreten: Stellen Sie sich eine unsortierte Tabelle vor, die neue Datensätze einfach ihrem Tabellenende anfügt. Sollten in einem intensiven Parallelbetrieb viele Datensätze eingefügt werden, so müssen alle Datensätze ans Tabellenende gebracht werden. Dadurch können natürlich Wartezeiten entstehen, weil prinzipiell eine Operation nach der anderen ausgeführt wird.
Legt die Administratorin nun einen clustered Index bspw. auf das Feld Nachname (wobei sie davon ausgeht, dass die Datensätze eben nicht in alphabetischer Reihenfolge eintreffen), so verteilen sich die Einfügungen über den gesamten Tabellenbereich: der Hotspot ist aufgelöst. Dieses Verfahren funktioniert gleichermaßen bei allen DBMS, die clustered Indizes unterstützen.
Allerdings kann es in der Implementierung sehr wohl Unterschiede geben: Der MS SQL Server z.B. wendet einen weiteren Trick an: Wenn es einen clustered Index gibt, so zeigen alle anderen Indizes nicht auf die Datenpages, sondern enthalten für jeden Datensatz „nur“ den Indexwert des clustered Index. Dort muss dann nachgesehen werden, bevor die eigentliche Seite referenziert werden kann. Obwohl das wie eine unnötige Komplizierung erscheint, ergibt sich daraus eine dramatische Vereinfachung beim Reorganisieren von Indizes: Nur der clustered Index braucht jemals angegriffen zu werden, alle anderen können nicht aus der Balance geraten.
PostgreSQL macht das grundsätzlich anders: clustered Indizes als solche existieren, funktionieren aber genau so wie die nonclustered Indizes. Die Tabelle ist also weitestgehend sortiert, aber neue Datensätze werden am Tabellenende angefügt. Diese müssen dann in Reorganisationsläufen an ihren „richtigen“ Platz gebracht werden. Hier liegt also das Hauptaugenmerk auf dem Nichtunterbrechen des normalen Tagesbetriebs.