Verwaltung spatio-temporaler Daten für die

Technische Universität Ilmenau
Fakultät für Informatik und Automatisierung
Institut für Praktische Informatik und Medieninformatik
Datenbanken und Informationssysteme
Diplomarbeit
Verwaltung spatio-temporaler Daten für die
Wellenfeldsynthese
Hendrik Rusch
Ilmenau, den 30. Mai 2005
Verantwortlicher Professor:
Hochschulbetreuer:
Betrieblicher Betreuer:
Prof. Dr.-Ing. habil. Kai-Uwe Sattler
Dipl.-Inf. Thomas Heimrich
Dipl.-Ing. Katrin Reichelt
Inventarisierungsnummer:
2005-06-01/071/IN99/2254
Danksagung
An dieser Stelle möchte ich allen danken, die mir bei der Entstehung dieser Diplomarbeit geholfen haben. Mein besonderer Dank für die Unterstützung gilt meinen Betreuern Dipl.-Inf. Katrin Reichelt, Prof. Dr. Kai-Uwe Sattler sowie Dipl.Inf. Thomas Heimrich.
Für das geduldige Korrekturlesen danke ich Melanie Krauße und Sebastian
Bauer.
Für die Unterstützung und den Rückhalt während des gesamten Studiums und
der Erstellung dieser Arbeit danke ich allen Freunden sowie meiner Freundin
Christiane Witter.
Diese Arbeit ist meinen Eltern Arlette und Detlef Rusch gewidmet, die mir
dieses Studium ermöglicht haben.
Ilmenau, den 30. Mai 2005
Inv.-Nr.: 2005-06-01/071/IN99/2254
Zusammenfassung
Die Diplomarbeit beschäftigt sich mit der Speicherung und Verwaltung der Daten
für das IOSONO-Raumklangsystem. Es werden die beteiligten Datenarten – Metadaten und Audiodaten – vorgestellt und die Anforderungen an die Verwaltung
derselben aufgezeigt. Techniken zur Umsetzung der Anforderungen werden, mit
Schwerpunkt auf Datenbankmanagementsysteme, betrachtet und verglichen. Für
einige Punkte werden zudem diverse Performancetests erläutert. Schließlich wird
die jeweils gewählte Lösung zur Datenverwaltung und -speicherung vorgestellt
und Implementierungsschritte erläutert.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Inhaltsverzeichnis
1 Einleitung
1.1 Gegenstand der Arbeit . .
1.2 Zielsetzung der Arbeit . .
1.3 Aufbau . . . . . . . . . .
1.4 Stand zu Beginn der Arbeit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Grundlagen
2.1 IOSONO . . . . . . . . . . . . . . . . . . . . . .
2.2 IOSONO-Komponenten . . . . . . . . . . . . . .
2.2.1 Spamix . . . . . . . . . . . . . . . . . . .
2.2.2 Audioserver . . . . . . . . . . . . . . . . .
2.2.3 Renderer . . . . . . . . . . . . . . . . . .
2.2.4 Control Unit . . . . . . . . . . . . . . . .
2.3 Systemarchitektur . . . . . . . . . . . . . . . . . .
2.4 IOSONO Daten . . . . . . . . . . . . . . . . . . .
2.4.1 Metadaten . . . . . . . . . . . . . . . . . .
2.4.1.1 Das Autorenformat XMT-SAW .
2.4.1.2 Inhalt einer Szenenbeschreibung
2.4.2 Audiodaten . . . . . . . . . . . . . . . . .
2.5 Workflow . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Modellierung/Szenenerstellung . . . . . .
2.5.2 Abspielvorgang . . . . . . . . . . . . . . .
2.6 Anforderungen . . . . . . . . . . . . . . . . . . .
2.6.1 Modellierungsprozess . . . . . . . . . . .
2.6.2 Abspielvorgang . . . . . . . . . . . . . . .
2.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
13
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
17
17
17
17
17
19
19
20
20
22
23
23
24
24
26
26
27
Inv.-Nr.: 2005-06-01/071/IN99/2254
8
INHALTSVERZEICHNIS
3 Metadaten
3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Speicherung von XML-Daten . . . . . . . . . . . . . . .
3.1.2 Export nach XMT-SAW . . . . . . . . . . . . . . . . . .
3.1.3 Suche über Metadaten . . . . . . . . . . . . . . . . . . .
3.1.4 Versionierung der Daten . . . . . . . . . . . . . . . . . .
3.1.5 Lange Transaktionen . . . . . . . . . . . . . . . . . . . .
3.1.6 Konsistenz von Audio- und Metadaten . . . . . . . . . . .
3.1.7 „Einfach und günstig“ . . . . . . . . . . . . . . . . . . .
3.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 XML-Parser . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Datenverwaltungssysteme . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Speicherung von XML . . . . . . . . . . . . . . . . . . .
3.3.2 Export nach XMT-SAW . . . . . . . . . . . . . . . . . .
3.3.3 Suche über Metadaten . . . . . . . . . . . . . . . . . . .
3.3.4 Versionierung . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.1 Integriert ins Datenverwaltungssystem . . . . .
3.3.4.2 Eigene Versionierung – Versionierung flacher
Dokumente . . . . . . . . . . . . . . . . . . .
3.3.4.3 Eigene Versionierung – Versionierung mit XML
3.3.5 Lange Transaktionen . . . . . . . . . . . . . . . . . . . .
3.3.6 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.1 XML-Datenbanken . . . . . . . . . . . . . . .
3.3.7 Berkeley DB XML . . . . . . . . . . . . . . . . . . . . .
3.3.7.1 Berkeley DB . . . . . . . . . . . . . . . . . . .
3.3.7.2 Datenverwaltung . . . . . . . . . . . . . . . . .
3.3.7.3 Features . . . . . . . . . . . . . . . . . . . . .
3.4 Speicherung von XMT-SAW . . . . . . . . . . . . . . . . . . . .
3.4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Verwaltungsstruktur . . . . . . . . . . . . . . . . . . . .
3.4.3 Implementierung . . . . . . . . . . . . . . . . . . . . . .
3.4.3.1 Export . . . . . . . . . . . . . . . . . . . . . .
3.5 Versionierungssystem . . . . . . . . . . . . . . . . . . . . . . . .
Inv.-Nr.: 2005-06-01/071/IN99/2254
29
30
30
30
31
31
31
31
32
32
32
33
33
34
34
35
36
37
38
38
40
42
45
46
46
49
49
49
50
50
51
51
52
54
54
INHALTSVERZEICHNIS
9
3.5.1
3.6
3.7
3.8
XMT-SAW spezifische Bestimmung von Versionierungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1.1 Persistente Identifier (PID) . . . . . . . . . . .
3.5.1.2 Reihenfolge und Textinhalte von Knoten . . . .
3.5.1.3 Prinzip der Differenzbestimmung . . . . . . . .
3.5.2 Speicherung von Versionsdaten . . . . . . . . . . . . . .
3.5.2.1 Deltas . . . . . . . . . . . . . . . . . . . . . .
3.5.2.2 Zeitstempel . . . . . . . . . . . . . . . . . . .
3.5.2.3 Vergleich von Deltas und Zeitstempeln . . . . .
3.5.2.4 Evaluierung . . . . . . . . . . . . . . . . . . .
3.5.3 Implementierung . . . . . . . . . . . . . . . . . . . . . .
Suche über Metadaten . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Was soll gesucht werden? . . . . . . . . . . . . . . . . .
3.6.2 Typische Anfragen . . . . . . . . . . . . . . . . . . . . .
3.6.3 Suche nach ganzen Wörtern und Teilwörtern . . . . . . .
3.6.4 Fehlertolerante Suche und Ähnlichkeitssuche . . . . . . .
3.6.4.1 Abstandsmaße . . . . . . . . . . . . . . . . . .
3.6.4.2 Eignung . . . . . . . . . . . . . . . . . . . . .
3.6.4.3 Algorithmus . . . . . . . . . . . . . . . . . . .
3.6.4.4 Speicherstrukturen . . . . . . . . . . . . . . . .
3.6.4.5 Zeitaufwand . . . . . . . . . . . . . . . . . . .
3.6.5 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.6 Implementierung . . . . . . . . . . . . . . . . . . . . . .
3.6.6.1 Dokument indizieren . . . . . . . . . . . . . .
3.6.6.2 Dokument-spezifische Indizierung entfernen . .
3.6.6.3 Elemente finden . . . . . . . . . . . . . . . . .
Offene Themen . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Mehrbenutzerunterstützung . . . . . . . . . . . . . . . .
3.7.2 Lange Transaktionen . . . . . . . . . . . . . . . . . . . .
3.7.3 Datenkonsistenz . . . . . . . . . . . . . . . . . . . . . .
3.7.3.1 Konsistenz von Referenzen und Eigenschaften .
3.7.3.2 Konsistenz von Szenenbeschreibungen . . . . .
Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . .
55
55
57
57
59
59
63
66
70
71
72
72
72
73
73
74
75
76
78
81
81
82
83
84
84
85
85
86
88
88
88
89
4 Audiodaten
91
4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1.1 Echtzeitwiedergabe . . . . . . . . . . . . . . . . . . . . . 92
Inv.-Nr.: 2005-06-01/071/IN99/2254
10
INHALTSVERZEICHNIS
4.1.2
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Wiedergabe entsprechend der Bedingungen der Szenenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . .
Systemkomponenten . . . . . . . . . . . . . . . . . . . . . . . .
Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Streaming-Server . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Datenbankmanagementsysteme . . . . . . . . . . . . . .
4.3.2.1 RDBMS und OODBMS . . . . . . . . . . . . .
4.3.2.2 Berkeley DB . . . . . . . . . . . . . . . . . . .
4.3.3 Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . .
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IOSONO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Implementierung . . . . . . . . . . . . . . . . . . . . . .
4.6.2 Performance . . . . . . . . . . . . . . . . . . . . . . . .
Berkeley DB . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 Konfigurationsmöglichkeiten für BDB-Tests . . . . . . .
4.7.1.1 Art des Datensatz-Schlüssels . . . . . . . . . .
4.7.1.2 Datensatzgröße . . . . . . . . . . . . . . . . .
4.7.1.3 BDB Zugriffsmethoden . . . . . . . . . . . . .
4.7.1.4 Datenzugriff . . . . . . . . . . . . . . . . . . .
4.7.1.5 Format der gespeicherten Daten . . . . . . . . .
4.7.1.6 Seitengröße (Pagesize) . . . . . . . . . . . . .
4.7.2 Testszenarien und Ergebnisse . . . . . . . . . . . . . . .
4.7.2.1 Erste Erkenntnisse . . . . . . . . . . . . . . . .
4.7.2.2 Speicherbedarf . . . . . . . . . . . . . . . . . .
4.7.2.3 Testreihe 1 . . . . . . . . . . . . . . . . . . . .
4.7.2.4 Testreihe 2 . . . . . . . . . . . . . . . . . . . .
4.7.3 Auswertung der Ergebnisse . . . . . . . . . . . . . . . .
4.7.3.1 Beste Konfiguration . . . . . . . . . . . . . . .
4.7.3.2 Fazit . . . . . . . . . . . . . . . . . . . . . . .
Integrierte Audiodatei . . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 Testergebnisse . . . . . . . . . . . . . . . . . . . . . . .
4.8.1.1 Evaluierung . . . . . . . . . . . . . . . . . . .
4.8.2 Die Datenstruktur . . . . . . . . . . . . . . . . . . . . . .
4.8.3 Erzeugung . . . . . . . . . . . . . . . . . . . . . . . . .
Inv.-Nr.: 2005-06-01/071/IN99/2254
92
92
93
94
94
95
95
95
96
96
97
97
98
98
99
100
101
101
102
103
105
106
106
107
107
108
109
112
116
116
117
118
118
119
119
121
INHALTSVERZEICHNIS
4.8.4
4.8.5
11
Integration . . . . . . . . . . . . . . . . . . . . . . . . . 122
Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . 123
5 Fazit und Ausblick
125
A XQuery-Funktionen
127
A.1 Abfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.2 Differenzbestimmung . . . . . . . . . . . . . . . . . . . . . . . . 128
Literaturverzeichnis
134
Abbildungsverzeichnis
136
Tabellenverzeichnis
137
Quelltextverzeichnis
138
Abkürzungsverzeichnis
139
Inv.-Nr.: 2005-06-01/071/IN99/2254
Kapitel 1
Einleitung
1.1 Gegenstand der Arbeit
Gegenstand der Arbeit stellt das IOSONO-System dar, das vom Fraunhofer-Institut für Digitale Medientechnologie zur Wiedergabe von akkuratem Raumklang
entwickelt wurde. Durch die Nutzung der Wellenfeldsynthese bietet es perfekten
natürlichen Raumklang und eine starke Einhüllung über den gesamten Wiedergaberaum. Das IOSONO-System baut auf einer Vielzahl von Daten auf. Diese werden zur Berechnung der Wellenfeldsynthese benötigt. Es handelt sich um spatiotemporale Daten, d.h. diese haben einen Raum- und Zeitbezug.
1.2 Zielsetzung der Arbeit
Ziel der Arbeit ist es, einen geeigneten Datenverwaltungsmechanismus für die Datenbasis des IOSONO-Systems zu finden. Die Eignung eines Datenbanksystems
für diese Zwecke ist zu testen. Anschließend gilt es, ein entsprechendes Datenlayout zu entwerfen. Auf diesem basierend ist ein funktionierendes System zu
implementieren.
1.3 Aufbau
Im ersten Teil der Arbeit wird das IOSONO-System, dessen Grundlagen und
Komponenten vorgestellt. Ebenso gibt es einen Überblick über die Anforderungen
an die neue Speicherverwaltung. In Kapitel 3 wird die Speicherung und Verwaltung der System-Metadaten vorgestellt. Nach der detaillierten Vorstellung der AnInv.-Nr.: 2005-06-01/071/IN99/2254
14
KAPITEL 1. EINLEITUNG
forderungen werden die zur Verfügung stehenden Möglichkeiten der Umsetzung
aufgezeigt und verglichen. Darauf basierend werden Implementierungsschritte
und -details zur gewählten Lösung erläutert. Die Verwaltung der Audiodaten des
IOSONO-Systems ist Inhalt von Kapitel 4. Einstieg in dieses Thema ist ebenfalls
die Vorstellung der Anforderungen und der zur Realisierung geeigneten Techniken. Anschließend werden zwei Möglichkeiten der Speicherung mit Hauptaugenmerk auf die Performance untersucht und darauf basierend die Entscheidung für
eine Implementierungsvariante getroffen.
1.4 Stand zu Beginn der Arbeit
Das IOSONO-System ist in kompletter und funktionierender Form implementiert.
Erste Systeme laufen erfolgreich in Testräumen und Referenzkinos, wie z.B. in Ilmenau in Thüringen. Die Datenverwaltung unterliegt jedoch keiner optimierenden
Verwaltung. Die Daten sind in Form von Dateien auf dem Dateisystem abgelegt.
Um das System leistungsfähiger und Teile des Produktionsprozesses komfortabler
zu machen, gilt es, dies entsprechend zu optimieren und damit den Bedürfnissen
besser anzupassen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Kapitel 2
Grundlagen
2.1 IOSONO
Das IOSONO-System [11] ist ein Wiedergabesystem zur Erstellung und Reproduktion von räumlichen Klangszenen basierend auf der Wellenfeldsynthese.
Die Grundidee des Systems begründet auf dem Huygens’schen Prinzip der
Wellentheorie [31]. Dieses besagt, dass jeder Punkt einer bestehenden Wellenfront selbst Ausgangspunkt einer kugelförmigen Elementarwelle ist. Diese hat die
gleiche Ausbreitungsgeschwindigkeit und Frequenz wie die Ursprungswelle. Die
Einhüllende aller Elementarwellen ergibt die Wellenfront zu einem späteren Zeitpunkt.
Im Beispiel einer Kugelquelle in Abb. 2.1 wird eine Wellenfront durch die
Überlagerung vieler elementarer Kugelquellen dargestellt.
Abbildung 2.1: Wellenüberlagerung bei Kugelquelle
Inv.-Nr.: 2005-06-01/071/IN99/2254
16
KAPITEL 2. GRUNDLAGEN
Bei der Audiowiedergabe ermöglicht das Huygens’sche Prinzip, Wellenfronten von Schallquellen bzw. Schallfeldern mit Hilfe eines linearen Lautsprecherarrays realitätsnah nachzubilden. Dies bedeutet, dass der Wiedergaberaum komplett
von Lautsprechern umgeben ist. Bei der Wiedergabe wird das Signal für jeden dieser Lautsprecher abhängig von der Position der einzelnen virtuellen Schallquellen
unterschiedlich berechnet, so dass ein homogenes Wellenfeld synthetisiert wird.
Dieses Prinzip bietet einen entscheidenden Vorteil gegenüber einem 5.1 (6.1,
7.1) Surround-System: während bei diesen nur ein Punkt der optimalen Klangwahrnehmung im Raum existiert (der Sweet-Spot), ist beim IOSONO-System der
Raumklang über die gesamte Hörfläche verteilt optimal. Der Hörer kann sich in
diesem Bereich frei bewegen, ohne Klangeinbußen hinzunehmen.
Auf technischer Seite werden im Unterschied zu kanalorientierten Systemen,
wie den angesprochenen bisherigen Surround-Systemen, keine vorberechneten
Lautsprechersignale ans IOSONO-System gesendet. Stattdessen gibt es objektorientierte Klangszenen. Dabei wird jedes Klangereignis mit seinen Eigenschaften
an die Systemkomponenten übertragen. Diese berechnen mit Hilfe von Renderern die eigentlichen Signale für jeden Lautsprecher. Dies hat den Vorteil, dass
sich die Klangwiedergabe an persönliche Konfigurationen des Hörers anpassen
lässt. Auch denkbar sind Variationen wie das nachträgliche Verändern der Position einer Klangquelle. Für den Produktionsprozess bietet die Objektorientierung
zudem den Aspekt der Wiederverwendung vorhandener Klangszenen oder deren
Bestandteile.
Die zur Berechnung benötigten Eigenschaften werden in Szenenbeschreibungen gespeichert, getrennt von den Audiodaten.
2.2 Komponenten des IOSONO-Systems
Das IOSONO-System besteht aus mehreren Software-Komponenten, die im Zusammenspiel die Erstellung, Berechnung und Wiedergabe von räumlichen Klangszenen realisieren [7]. Die dafür verwendeten Rechner bestehen aus StandardKomponenten, wie sie auch in Heim-PCs vorhanden sind. Einzig spezielle Soundkarten sind nötig, um die Datenübertragung von Audiodaten zwischen den
Komponenten zu ermöglichen.
Die in diesem Abschnitt vorgestellten Systemteile sind Software-Komponenten, welche integrale Bestandteile des Systems sind.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
17
2.2.1 Spamix
Das Autorenwerkzeug Spamix dient der Erzeugung und Verwaltung von Szenenbeschreibungen. Des Weiteren wird es während der Wiedergabe dazu benutzt, die
in den Beschreibungen enthaltenen Informationen an Renderer und Audioserver
zur Weiterbearbeitung zu senden. Ebenso ist zur Abspielzeit eine Ablaufverfolgung der Objekte einer Szene möglich, da aktuell aktive Objekte in ihrer Aktion
dargestellt werden. Interessant ist dies gerade mit Blick auf Audioobjekte, welche
in Bewegung sind.
2.2.2 Audioserver
Der Audioserver ist ebenfalls eine Software, die auf einem gesonderten Rechner
läuft. Auf diesem sind alle Audiodaten gespeichert, die für die Ausgabe benötigt
werden. Der Audioserver liest die benötigten Daten aus den Audiodateien und
überträgt sie über die Soundkarte an die Renderer.
2.2.3 Renderer
Der Renderer nimmt anhand der empfangenen Audio- und Metadaten die eigentlichen Geometrieberechnungen zur Wellenfeldsynthese vor. Die berechneten Audiosignale werden über eine entsprechende Audioschnittstelle an die Lautsprecher übertragen, welche den Hörraum beschallen. Es existieren mehrere Renderer,
um die Ausgabe produzieren zu können. Jeder Berechnungsprozess der Renderer
muss über die höchste Prozesspriorität verfügen, um die Berechnung der Lautsprechersignale in Echtzeit zu gewährleisten.
2.2.4 Control Unit
Diese Software läuft auf dem gleichen Rechner wie das Spamix-Tool. Ihre Aufgabe ist das Starten der Renderer sowie deren Überwachung. Dies ermöglicht die
Ausfallerkennung der beteiligten Renderer.
2.3 Systemarchitektur
Das Zusammenspiel der Systemkomponenten aus 2.2 ist in Abbildung 2.2 aufgezeigt.
Inv.-Nr.: 2005-06-01/071/IN99/2254
18
KAPITEL 2. GRUNDLAGEN
Abbildung 2.2: Systemarchitektur
Die dick umrandeten Elemente stellen jeweils eine Einheit dar. Es sind Software-Komponenten und Daten, die für die Berechungen der Wellenfeldsynthese
sowie die Audioausgabe benötigt werden. Diese Einheiten befinden sich auf einem eigenen Rechner.
Der Audioserver ist auf einem Rechner aktiv, auf welchem auch die Audiodaten abgelegt werden. Das Auslesen dieser Daten, die Umwandlung in das benötigte Ausgabeformat und die Übertragung der so generierten Audiosamples an die
Renderer sind Aufgaben, die dort durchgeführt werden.
Spamix und Control Unit laufen auf einem weiteren Rechner. Während Spamix Steuerdaten sowohl an den Audioserver als auch an die Renderer sendet
(speziell Positionsdaten), werden die Renderer von der Control Unit über weitere Steuerdaten gesteuert. Diese Spamix-Steuerdaten sind in XML-basierten Szenenbeschreibungen enthalten, welche als Dateien auf der Festplatte des SpamixRechners liegen.
Ein Rechner mit Timecode-Generator versorgt Audioserver und Spamix mit
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
19
Timecode, wodurch Synchronität zwischen den einzelnen Prozessen gewährleistet werden kann. Der Renderer dagegen läuft ohne zugespielten Timecode und
verarbeitet einkommende Daten sofort.
Die Renderer verwenden diese empfangenen Daten zur Berechnung der Audiosignale, welche an die Lautsprecherpanels übertragen werden. Dafür beziehen
sie die von Spamix zugespielten Positionsdaten ein.
Zwischen den verschiedenen Einheiten sind die Datenströme dargestellt, die
sich in Positionsdaten, Steuerdaten sowie Audiodaten aufgliedern. Audiodaten
werden über ein ALSA1 Interface von Soundkarte zu Soundkarte übertragen. Positionsdaten und Steuerdaten werden über Netzwerkverbindung transferiert.
2.4 IOSONO Daten
Zur Wiedergabe von Audioszenen und der damit verbundenen Berechnung der
Wellenfeldsynthese werden sowohl Meta- als auch Audiodaten benötigt. Erstere
sind Mittel zur Beschreibung objektorientierter Klangszenen. Audiodaten halten
die Signale zur Berechnung der Audiosignale zur Ansteuerung der Lautsprecher
für die Reproduktion des Wellenfelds, welche unter Verwendung der Informationen aus den Metadaten ausgeführt wird.
2.4.1 Metadaten
Metadaten werden zur Beschreibung der Klangszenen verwendet. Eine Klanszenen besteht aus einer bestimmten Anzahl an Klangquellen (im Weiteren auch: Audioquellen) inklusive deren Eigenschaften und räumlicher Position. Klangquellen
repräsentieren alle Schallquellen wie Sprache, Umgebungsgeräusche und sonstige
klanglichen Elemente. Sie sind bestimmt durch räumliche und zeitliche Position.
Die Metadaten können unabhängig von den Audiodaten, die sie beschreiben,
verändert und erweitert werden. Jedoch muss dabei die Integrität der Daten gesichert bleiben. Metadaten sind für die Funktion des IOSONO-Systems unabdingbar, da aus ihnen die diversen Parameter entnommen werden, welche zur Berechnung der Wellenfeldsynthese benötigt werden.
1
ALSA bietet Unterstützung für Audio- und MIDI-Hardware durch Treiber, eine API sowie
eine Bibliothek; weitere Informationen unter http://www.alsa-project.org/
Inv.-Nr.: 2005-06-01/071/IN99/2254
20
KAPITEL 2. GRUNDLAGEN
2.4.1.1 Das Autorenformat XMT-SAW
Die Metadaten werden im so genannten XMT-SAW Autorenformat beschrieben.
XMT-SAW [25] wurde am Fraunhofer-Institut für Digitale Medientechnologie auf
XMT (eXtensible MPEG-4 Textual Format [36]) basierend entwickelt. XMT ist
ein Framework, das MPEG-4 Szenenbeschreibungen mittels textueller Syntax repräsentiert. Es erlaubt Autoren solcher Szenen, deren Inhalt einfach mit anderen
Autoren oder Tools auszutauschen. Außerdem erleichtert es die Interoperabilität
mit Extensible 3D (X3D [37]) und der Synchronized Multimedia Integration Language (SMIL [33]).
2.4.1.2 Inhalt einer Szenenbeschreibung
Integraler Bestandteil eines XMT-SAW Beschreibung ist die Darstellung von statischen und dynamischen virtuellen Audioquellen. Dazu gehören alle Eigenschaften der Audioquelle. Dies sind u.a. die Position der Quelle, die Lautstärke und die
Art der Klangquelle. Für letztere stehen Punktquelle und ebene Welle als Alternativen zur Verfügung, die sich jeweils in ihrer Abstrahlcharakteristik unterscheiden.
Weitere Bestandteile einer Szenenbeschreibung sind:
• Virtuelle Räume, um die Charakteristiken des Raumes, in dem sich die Audioquellen befinden, zu reproduzieren
• Globale Parameter, wie
– Lautstärke der Szene – diese ist für alle Audioquellen gültig
– Lautstärke des Subwoofers
– ein Zeitwert, der einen absoluten zeitlichen Offset zur Synchronisation
aller Objekte einer Szene enthält
• Gruppierung virtueller Audioquellen; dies ermöglicht, Eigenschaften für
mehrere Objekte mit Hilfe eines Elements festzulegen
• Eine Referenz auf das eigentliche Audiosignal, d.h. im Normalfall die Angabe eines Dateinamens zu einer WAV-Datei.
Ein wichtiger Beschreibungsinhalt sind auch zeitliche Abläufe, da ein Audioobjekt in Bewegung sein kann. Beispiele hierfür sind ein laufender Mensch oder
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
21
ein fahrendes Auto. Diese Bewegung muss für eine korrekte räumliche Klangdarstellung berücksichtigt werden. Somit muss die Position des Objekts in Bezug zur
Szenenzeit mit in der Beschreibung festgehalten werden.
Wie eine XMT-SAW Szenenbeschreibung aussehen kann, ist im folgenden
Quelltext-Ausschnitt aufgezeigt. Um die Übersicht zu gewährleisten wurden einige der im realen Fall benötigten Attribute ausgelassen. Alle Eigenschaften, welche
für die hier durchgeführten Betrachtungen von Bedeutung sind, sind jedoch enthalten.
<XMT-SAW>
<head>
<topLayout>
<region name="region1" soundLevel="0.316228"
subwooferLoudness="100" />
</topLayout>
</head>
<body>
<room id="room1" />
<layer id="layer0">
<audio id="1" src="1:Tom_1" begin="0" end="10"
isPlaneWave="false">
<additionalSrc src="AS:1_Tom_1.wav"
begin="0" end="20"/>
<sound id="source1"
location="-1.64999998 3.3499999 0"
useRoom="room1" />
</audio>
<audio id="2" src="2:Cat" begin="7" end="20"
isPlaneWave="false">
<additionalSrc src="AS:2_Cat.wav"
begin="7" end="20"/>
<sound id="source2"
location="1.64999998 3.3499999 0"
useRoom="room1" />
</audio>
<audio id="3" src="3:Radio" begin="10" end="60"
isPlaneWave="false">
<additionalSrc src="AS:3_Radio.wav"
Inv.-Nr.: 2005-06-01/071/IN99/2254
22
KAPITEL 2. GRUNDLAGEN
begin="10" end="60"/>
<sound id="source3"
location="-5.0500000007 0.6400001 0"
useRoom="room1" />
</audio>
<audio id="4" src="4:Steps" begin="20" end="30"
isPlaneWave="false">
<additionalSrc src="AS:4_Steps.wav"
begin="20" end="60"/>
<sound id="source4"
location="-4.89999998 -2.71000004 0"
useRoom="room1" />
</audio>
<audio id="5" src="5:Door" begin="45" end="50"
isPlaneWave="false">
<additionalSrc src="AS:5_Door.wav"
begin="45" end="50"/>
<sound id="source5"
location="-1.89999998 -1.89999998 0"
useRoom="room1" />
</audio>
</layer>
</body>
</XMT-SAW>
Quelltext 2.0: Ausschnitt eines XMT-SAW Dokumentes
Jedes audio-Element beschreibt eine virtuelle Audioquelle mit all ihren Eigenschaften. Neben der Id sind dies z.B. Start- und Endzeit (begin/end) als auch die
Festlegung der Art der Klangquelle (isPlaneWave). Unterelemente von audio sind
additionalSrc, worin die Audiodaten referenziert werden, und sound, das Eigenschaften wie Position der Audioquelle (location) und zu verwendende Hörraumkonfiguration (useRoom) festlegt. Diese wird in einem room Element definiert.
2.4.2 Audiodaten
Audiodaten sind die Grundlage der Soundwiedergabe. Sie liegen im WAV-Format
vor [18]. Für qualitativ hochwertige Audiowiedergabe handelt es sich um Daten
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
23
mit einer Frequenz von 48.000 Hz und 16 oder 24 bit Datenbreite pro Sample.
Audiodaten für die Wellenfeldsynthese werden mit speziellem Equipment und
Mikrofonkonfigurationen aufgenommen.
Für eine Audioszene werden diverse WAV-Dateien benötigt. Diese werden in
der Szenenbeschreibung von Audioobjekten referenziert, mit Wiedergabezeiten
versehen und diesen entsprechend zum gegebenen Zeitpunkt abgespielt. Jede Audioquelle benötigt eine oder mehrere WAV-Dateien, um die zugehörige Audioausgabe für eine komplette Szene zur Verfügung zu stellen.
Zu einem Zeitpunkt werden hierbei mehrere Audiodateien gleichzeitig wiedergegeben. Sie liefern die Daten für die entsprechenden Audioobjekte, welche
gleichzeitig aktiv sein können. In der derzeitigen Systemkonfiguration liegt der
Grad der Parallelität bei maximal 32 Audioquellen.
WAV-Dateien Die WAV-Dateien ergeben sich aus der Digitalisierung analoger
Signale. Dazu werden die Signale in regelmäßigen Abständen – entsprechend der
Samplingfrequenz – abgetastet. Bei einer Frequenz von 48.000 Hz wird das Signal
48.000-mal pro Sekunde abgetastet und der jeweilige Signalwert, ein Sample, bestimmt. Dieses Sample hat eine bestimmte Größe. Dies kann z.B. 16 oder 24 Bit
sein und legt die Genauigkeit des Signalwertes fest. Mit 16 Bit können Werte
von Samplewerte von -32.767 bis 32.767 aufgenommen werden. Die Samplingfrequenz ist entscheidend für die Audioqualität, da mit zu geringer Frequenz nur
niedrigere Frequenzen festgestellt werden können - höhere Frequenzen gehen verloren. Mit 48.000 Hz können Frequenzen bis 24.000 Hz wiedergegeben werden,
da eine Schwingung aus einer Auf- und Abbewegung besteht und daher 2 Samples benötigt. Diese Frequenz ist vollkommen ausreichend, da das menschliche Ohr
nur Frequenzen von etwa 20 bis 16.000 Hz wahrnimmt.
2.5 Workflow
2.5.1 Modellierung/Szenenerstellung
Die Szenenerstellung umfasst die Abbildung einer realen Audiosituation in eine Szenenbeschreibung im XMT-SAW Format. Aus den so generierten Metadaten lassen sich die Parameter zur Berechnung der WFS extrahieren und an die
IOSONO-Komponenten übermitteln.
Die Erstellung einer Szenenbeschreibung erfolgt mittels Spamix. Dort wird
entsprechend der Konfiguration des Hörraums dieser mit seinen Parametern nachInv.-Nr.: 2005-06-01/071/IN99/2254
24
KAPITEL 2. GRUNDLAGEN
gebildet. So wird ein virtueller Raum erzeugt. Anschließend werden alle Klangquellen der Szene mittels virtueller Audioquellen nachgebildet, die als Audioobjekte repräsentiert werden. Diese werden im virtuellen Raum an entsprechender
räumlicher Stelle positioniert. Eigenschaften der Quellen sowie Bewegungsabläufe oder Lautstärkeveränderungen werden zugewiesen. Jedem Audioobjekt werden
zudem über Referenzen Audiodaten zugeordnet, die in Dateiform auf Festplatte
liegen. Somit wird die Beziehung zwischen Szenenbeschreibung und Audiosignalen hergestellt. Informationen zum Aufnahmeprozess der Audiodaten für die
Wellenfeldsynthese finden sich in der Diplomarbeit von Frank Melchior [24].
Die erstellten Szenen werden schließlich in Form von XML-basierten Dateien, im XMT-SAW Format, auf Festplatte gespeichert und ebenso von dort zur
Bearbeitung eingelesen.
2.5.2 Abspielvorgang
Der Abspielvorgang, d.h. die Wiedergabe von Audioszenen anhand der erstellten
Szenenbeschreibungen, ist in Abbildung 2.3 auf der nächsten Seite dargestellt. Im
Mittelpunkt stehen die drei Komponenten Spamix, Audioserver sowie Renderer.
Die Komponente „Timecode“ wurde aus Gründen der Übersichtlichkeit nicht
in die Darstellung einbezogen.
Nach Auswahl einer Szenenbeschreibung im Spamix werden die enthaltenen
Daten (Näheres unter 2.4.1) eingelesen. Die Steuerdaten werden zum Audioserver
übertragen, welcher daraus die Informationen über benötigte Audiodaten sowie
deren Abspielreihenfolge gewinnt. Diese Informationen werden zur weiteren Benutzung gespeichert. Zudem wird mit dem Auslesen und Zwischenspeichern der
Audiodaten begonnen. Wird der Abspielvorgang gestartet, werden seitens Spamix
Positionsdaten an die Renderer gesendet. Der Audioserver gibt die gepufferten
Audiodaten an die Renderer weiter und füllt die frei werdenden Puffer mit neuen
Audiodaten. Der Renderer nimmt die empfangenen Daten und berechnet daraus
sofort nach deren Eingang die Audiosignale für die Lautsprecher. Diese berechneten Audiosignale werden an die Lautsprecherpanels übertragen.
2.6 Anforderungen an die Verwaltung
An die Verwaltung von Audio- und Metadaten werden bestimmte Anforderungen
gestellt. Diese sollen dazu dienen, die bisherigen Verwaltungsmechanismen zu
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
25
Abbildung 2.3: Abspielvorgang
optimieren. Gegenwärtig werden beide Datenarten in einfachen Dateien im Dateisystem gespeichert. Dies bringt jedoch bestimmte Einschränkungen mit sich:
• Die Metadaten befinden sich in Form von XML-Dateien auf Festplatte.
Es existiert keine zentrale Verwaltung respektive komfortable Verwaltungsinformationen. Funktionen, die den Authoringprozess erleichtern könnten,
sind nicht implementiert. Unter anderem fehlt es an einer integrierten Suche
oder einer Möglichkeit zur einfachen Extraktion und Wiederverwendung
von Bestandteilen vorhandener Szenenbeschreibungen. Dies muss momentan manuell unter Zuhilfenahme externer Werkzeuge ausgeführt werden.
• Die Audiodaten liegen als WAV-Dateien auf Festplatte. Eine optimierende Datenorganisation ist dabei nicht berücksichtigt. Dies führt zu eingeschränkter Performance des Gesamtsystems, da das Auslesen der Audiodaten als geschwindigkeitsbestimmender Faktor nicht optimal verläuft.
Inv.-Nr.: 2005-06-01/071/IN99/2254
26
KAPITEL 2. GRUNDLAGEN
Beide Punkte führen zur Anforderung, ein modifiziertes und komplettes Datenverwaltungssystem für Audio- und Metadaten zu implementieren. Als Grundlage derselben wird ein Datenbankmanagementsystem (DBMS) in Betracht gezogen. Dies bietet die Mittel, eine übersichtliche integrierte Verwaltung der Metadaten zu erstellen. Auch sollte es über effiziente Datenverwaltungsmöglichkeiten
in der Lage sein, schnellere Datenausleseergebnisse zu liefern. Indexierung und
Caching werden hier als hilfreiche Mittel angesehen.
Im Folgenden werden die Anforderungen an die Datenverwaltung kurz vorgestellt - aufgeteilt in die Erstellung von Szenen (Modellierungsprozess) sowie das
Abspielen der Audiodaten (Abspielvorgang). Detaillierte Erläuterungen folgen in
den entsprechenden Kapiteln.
2.6.1 Modellierungsprozess
Der Modellierungsprozess umfasst alle Schritte zum Erstellen einer Szenenbeschreibung. Für diesen Vorgang ergeben sich Anforderungen, die den Erstellungsvorgang erleichtern sowie eine komfortable Datenspeicherung gewährleisten. Das
führt zu den Kriterien:
• Suche über Metadaten
• Versionierung der Daten
• Export nach XMT-SAW
Daneben gibt es noch die Anforderung, Konsistenz von Audio- und Metadaten
zu erhalten, was ein wichtiges Kriterium bei der Verwaltung der beteiligten Daten
und Dateien darstellt.
Auf der Ebene des Datenverwaltungssystems sind eine geeignete Form der
Speicherung von XML-Daten sowie unterstützende Funktionen wie (lange) Transaktionen als wünschenswert zu nennen. Grundlegend soll versucht werden, alle
Verwaltungsinformationen zentral in einer integrierten Lösung zu realisieren.
2.6.2 Abspielvorgang
Beim Abspielen einer Audioszene steht die Performance an oberster Stelle. Daraus sind die Anforderung formuliert:
• Echtzeitwiedergabe und
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 2. GRUNDLAGEN
27
• Wiedergabe entsprechend der Bedingungen der Szenenbeschreibung
Daher gilt es, ein Speichersystem zu finden, das die Echtzeitanforderungen
bzgl. der Audioausgabe umsetzen kann. Dabei soll die Speicherung der Audiodaten im WAV-Format beibehalten werden.
2.7 Fazit
Anforderungen an Modellierung und an Abspielvorgang unterscheiden sich in ihren primären Punkten. Es stehen Komfort und Integration gegen Performance. Aus
diesem Grund wird im Folgenden die Verwaltung in zwei verschiedene Punkte
aufgeteilt. Zum einen die Verwaltung der Metadaten, welchen in ein komfortables
und alle Funktionen integrierendes Datenverwaltungssystem eingebracht werden
sollen. Zum anderen die Verwaltung der Audiodaten, die in einer Form gespeichert werden sollen, welche performantes (echtzeitfähiges) Auslesen ermöglicht.
Die Umsetzung der Anforderungen beginnt mit denen für die Metadaten im
nächsten Kapitel. Das anschließende Kapitel widmet sich den Audiodaten. Entsprechend den jeweiligen Anforderungen werden Techniken vorgestellt, diese zu
realisieren. Anschließend werden Systeme angesprochen, welche diese Techniken
umsetzen, bzw. wie diese Techniken realisiert werden können. Zum Abschluss
wird die gewählte Implementierung vorgestellt.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Kapitel 3
Verwaltung der Metadaten
Abbildung 3.1: Systemarchitektur, Teilsystem Metadaten
Dieses Kapitel widmet sich der Verwaltung der Metadaten, in der Darstellung
dunkel hervorgehoben. Zwar sind diese eng mit den Audiodaten verzahnt, letztere
haben jedoch auf die Speicherung und Verwaltung der Metadaten keinen Einfluss.
Inv.-Nr.: 2005-06-01/071/IN99/2254
30
KAPITEL 3. METADATEN
Daher wird in diesem Kapitel mehrheitlich auf die Metadaten eingegangen, während sich Kapitel 4 mit den Audiodaten befasst.
Die Metadaten befinden sich bisher als XML-Dateien ungeordnet auf Festplatte. Über eine integrierte Verwaltung soll eine einheitliche Speicherung aller
erstellten Szenenbeschreibungen ermöglicht werden.
Um eine komplette Lösung zu erzielen, sind diverse Anforderungen zu beachten. Diese sollen den Authoring-Vorgang erleichtern und eine komfortable und
sichere Speicherung ermöglichen. Nach der kurzen Einführung der Anforderungen in der Einleitung folgt nun deren detaillierte Vorstellung. Danach werden für
jede Anforderung Lösungsmöglichkeiten, die Umsetzung und die entwickelte Datenstruktur dargestellt.
3.1 Anforderungen
3.1.1 Speicherung von XML-Daten
Die Metadaten liegen im XML-Format vor, einem Format zur Beschreibung von
strukturierten Daten. In dieser Form müssen die Daten auch im neuen Datenverwaltungssystem abgelegt werden. Das dies möglichst effizient geschehen soll versteht sich von selbst.
Im Optimalfall wird die Speicherung von XML in nativer Form unterstützt,
d.h. es wird ein logisches Modell für XML-Dokumente definiert, anhand welchem
Dokumente gespeichert und abgefragt werden. Der Vorteil: die physische Struktur
von XML-Dokumenten kann erhalten bleiben (incl. CDATA und Kommentaren)
und es wird der Inhalt nur über XML-basierte Technologien abgefragt (XPath,
DOM, etc.).
Zur komfortablen Arbeit mit XML sollte das Verwaltungssystem zudem Anfragen zum Retrieval von Teilen von XML-Dokumenten über ein XML-nahes
System wie XPath oder XQuery bieten.
3.1.2 Export nach XMT-SAW
Für die Transportabilität von Szenenbeschreibungen erfordert das Datenverwaltungssystem des Weiteren die Implementierung einer Exportschnittstelle, um eine Szenenbeschreibung in das aktuelle Speicherformat XMT-SAW zu exportieren. Damit wird das Abspielen dieser Szenenbeschreibung auf anderen IOSONOSystemen gewährleistet.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
31
3.1.3 Suche über Metadaten
Für die Produktion von Wellenfeldsynthese-Szenen ist es notwendig, bestimmte Szenenbestandteile wieder zu verwenden. Dazu ist die Implementierung einer
Schnittstelle zum Suchen von Szenenbestandteilen anhand bestimmter Kriterien
erforderlich. Die wichtigsten Suchkriterien sind hierbei der Name der Audioquelle
und der Name der zugehörigen Audiodateien.
3.1.4 Versionierung der Daten
Der Produktionsprozess soll mit Hilfe von Datenversionierung den Zugriff auf
vorangegangene Versionen der Daten mittels einer Historyfunktion realisieren.
Die Suche über Metadaten – als Anforderung schon vorgestellt – soll sowohl auf
der aktuellen Version eines Dokumentes als auch auf allen Daten vorheriger Versionen möglich sein.
3.1.5 Lange Transaktionen
Die Erstellung einer Szenenbeschreibung kann sich über mehrere Stunden, Tage
oder Wochen hinziehen. Standardtransaktionen [17] sind für diese Vorgänge nicht
geeignet. Sie laufen nach dem ACID-Prinzip1 ab und schränken dabei die Kooperation stark ein, was sich nicht mit mehrwöchigem Arbeiten an einem Projekt
vereinbaren lässt.
Wenn Transaktionen für lange Produktionsprozesse geeignet sind, spricht man
von langen Transaktionen. Diese können zu Problemen mit dem ACID-Prinzip
führen [27], speziell mit den Eigenschaften Atomarität, Konsistenz und Isolation.
Es müssen daher z.T. die ACID-Eigenschaften gelockert und spezielle Mechanismen und Kriterien entwickelt werden, um lange Transaktionen zu realisieren.
3.1.6 Konsistenz von Audio- und Metadaten
Werden Manipulationen an den Metadaten bzw. Audiodaten vorgenommen, so
muss die Konsistenz beider Datentypen überprüft werden. Verlängert man beispielsweise die Lebenszeit einer virtuellen Audioquelle, so muss unter Umständen darauf aufmerksam gemacht werden, dass die Länge der referenzierten Au1
ACID = Atomicity (Atomarität), Consistency (Konsistenz), Isolation, Durability (Dauerhaftigkeit); Transaktionen müssen diesen Eigenschaften bei ihrer Ausführung genügen, um Datenintegrität zu wahren
Inv.-Nr.: 2005-06-01/071/IN99/2254
32
KAPITEL 3. METADATEN
diodatei nicht mehr ausreichend ist, um die Laufzeit der virtuellen Audioquelle
abzudecken.
3.1.7 „Einfach und günstig“
Neben den schon erwähnten technischen Anforderungen gibt es noch weitere Faktoren. Da in der Regel Kinos die Einsatzumgebung von IOSONO sind, sollte der
Einsatz eines voll ausgestatteten DBMS vermieden werden. Dies hilft, den Kostenaufwand niedrig zu halten. Auch kann so der Administrationsaufwand, wie für
Installation und Wartung, auf einem Niveau wie dem derzeitigen gehalten werden.
Gerade während der Versuchsphase, in der nach einer geeigneten Lösung gesucht wird, ist zudem ein kostenfrei testbares System die erste Wahl.
3.2 Grundlagen
Da bestimmte Techniken in den folgenden Betrachtungen eine entscheidende Rolle spielen, werden diese für das weitere Verständnis hier kurz vorgestellt. Großteils beziehen diese sich auf XML und XML-basierte Techniken. Zum tieferen
Verständnis wird auf entsprechende Fachliteratur verwiesen.
3.2.1 XML
XML [32] ist eine einfache und flexible Auszeichnungssprache, die eine Untermenge von SGML2 darstellt und zur Definition beliebiger Dokumenttypen 3 eingesetzt werden kann. Ursprünglich für den Einsatz im Bereich elektronischer Veröffentlichungen konzipiert, spielt es mittlerweile eine große Rolle im Datenaustausch unterschiedlichster Daten in diversen Umgebungen, wie z.B. dem Internet.
Jedes XML-Dokument ist aus einzelnen Elementen aufgebaut, die durch Tags
markiert sind. Mithilfe dieser Elemente lassen sich beliebige Datenstrukturen und
deren Beziehungen beschreiben. Benötigt werden dafür neben den Elementen Attribute, welche die Eigenschaften von Elementen festlegen, sowie Verschachtelungen.
2
http://www.w3.org/MarkUp/SGML/
Dokumente gehören zum selben Dokumenttyp, wenn sie der gleichen Dokumenttyp Definition (DTD) folgen
3
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
33
3.2.2 XPath
Mit XPath [13] können Teile von XML-Dokumenten adressiert werden. Dabei
können ganze Mengen von Elementen selektiert werden, die sich durch Bedingungen einschränken lassen. Eine Normierung durch die W3C wurde vorgenommen [34]. XPath modelliert ein XML-Dokument als Baum von Knoten. Es existieren verschiedene Knotenarten, wie Element-Knoten oder Attribut-Knoten. Auf
den Bäumen wird in XPath über Achsen navigiert, welche Pfade bzw. Wege durch
den Baum darstellen. Beschrieben wird dieser zu gehende Weg durch Pfadausdrücke. Diese Lokalisierungspfade, welche meist aus mehreren Teilausdrücken
bestehen, selektieren die Knoten bzw. Knotenmengen des Dokumentes. Darauf
können mittels Verknüpfungen und Funktionsaufrufen zusätzliche Berechnungen
und Funktionen ausgeführt werden.
Anfragebeispiel Auf dem XML-Dokument aus 2.4.1.2 auf Seite 20 lässt sich
folgende Anfrage in XPath formulieren.
/layer/audio[@id="2"]/*
Diese selektiert alle Subelemente des Audio-Elementes mit der Id 2. Das Ergebnis dieser Anfrage wären die Elemente additionalSrc und sound.
3.2.3 XQuery
XQuery [21] stellt eine weitere Anfragesprache dar. Auch diese wurde durch
das W3C normiert [35]. XPath ist in XQuery integriert und wird dazu verwendet, Bestandteile von Dokumenten zu selektieren. Ein Hauptelement von XQuery
sind die FLWOR-Ausdrücke, zusammengesetzt aus den Komponenten FOR-LETWHERE-ORDERBY-RESULT. Mit FOR und LET werden Elemente eines Dokumentes selektiert und in Variablen übergeben. WHERE lässt Beschränkungen zu,
und mit RESULT können Ergebnisknoten zurückgeliefert werden. ORDERBY
erlaubt die Sortierung der Ergebnisse anhand gegebener Kriterien.
Anfragebeispiel Wieder auf Dokument aus 2.4.1.2 bezogen, ergibt sich die bei
XPath vorgestellte Anfrage zu folgendem XQuery-Ausdruck:
for $el in /layer/audio[@id="2"]/* return $el
Es wird deutlich, dass auch in XQuery XPath eine entscheidende Rolle zur
Selektion von Elementen spielt.
Inv.-Nr.: 2005-06-01/071/IN99/2254
34
KAPITEL 3. METADATEN
3.2.4 XML-Parser
Ein XML-Parser [23] nimmt ein XML-Dokument und stellt der nutzenden Anwendung die darin enthaltenen Informationen, d.h. Elemente, Attribute usw., zur
Verfügung. Bei XML-Parsern lässt sich nach verschieden Kriterien unterscheiden. So gibt es validierende und nicht validierende Parser. Erstere überprüfen,
ob ein Dokument valide ist, d.h. den Regeln einer DTD oder eines Schemas folgt.
Auch wird das Dokument auf Wohlgeformtheit getestet. Weiterhin kann zwischen
SAX- und DOM-Parsern unterschieden werden. Bei SAX-Parsern werden Dokumente seriell verarbeitet, d.h. von Element zu Element abgearbeitet. Die verarbeitende Anwendung wird mittels Ereignis-Handler über jedes erreichte Elemente informiert. DOM-Parser dagegen stellen ein Dokument in einer Baumstruktur
dar, welche über eine API auszulesen oder zu manipulieren ist. Dafür wird das
XML-Dokument komplett im Speicher gehalten.
3.3 Auswahl eines Datenverwaltungssystems
Um die Speicherung der Metadaten zu realisieren, ist ein geeignetes System basierend auf einem Datenverwaltungssystem zu entwickeln. Von den schon vorgestellten Anforderungen betreffen das Datenverwaltungssystem insbesondere:
• Speicherung komplexer Strukturen
• Export im XML-Format
• Eine Datenspeicherform, welche die Umsetzung der Suche über beliebige
Inhalte unterstützt
• Versionierung
• Lange Transaktionen
Zur Realisierung dieser Anforderungen existieren diverse Techniken, welche
hier im Kontext mit den Anforderungen vorgestellt werden. Systeme, welche diese
Techniken anbieten, werden vorgestellt, um vergleichend eine geeignete Lösung
als Grundlage der neuen Datenverwaltung zu finden.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
35
3.3.1 Speicherung von XML
Die grundlegendste Problematik ist zum Einstieg zu lösen: wie sind XML-Dokumente am besten zu speichern?
Die gegenwärtig umgesetzte und wohl auch einfachste Form der Speicherung
von XML ist, diese in Dateien auf Festplatte abzulegen. Dies wird von jedem
Dateisystem unterstützt. Es sind keine weiteren externen Dienste oder Programme vonnöten, und kann daher sofort auf jedem System umgesetzt werden. Jedoch werden in diesem Zusammenhang keine Dienste angeboten, welche helfen
könnten, die speziellen Verwaltungsanforderungen zu erfüllen. Dies wird in den
weiteren Abschnitten verdeutlicht.
Weitergehende Möglichkeiten bieten in dieser Hinsicht Datenbankmanagementsysteme (DBMS). Neben der effektiven Speicherung auch großer Datenmengen werden Mittel zur Verfügung gestellt, um einfach und gezielt Inhalte abzufragen.
Die am weitesten verbreitete Klasse von DBMS sind die relationalen DBMS
(RDBMS), in denen Daten auf dem relationalen Datenmodell basierend verwaltet werden. Die Daten werden in Form zweidimensionaler Tabellen repräsentiert,
welche über Schlüssel miteinander verknüpft werden können.
Soll XML in einer relationalen Datenbank gespeichert werden, gibt es zwei
Möglichkeiten. Lösung Nummer eins: XML-Dokumente können als Ganzes in
einem geeigneten Datentyp abgelegt werden, wie zum Beispiel Text-Typen oder
BLOBs4 . Deren Nachteil ist jedoch, dass die Datenbank keine Information über
die Struktur des Dokumentes erhält, und so auch keine strukturbezogenen Anfragen stattfinden können – bei der Arbeit mit XML ein nicht zu unterschätzendes Problem. Als zweite Möglichkeit kann die XML-Struktur in das relationale
Modell überführt werden, d.h. es wird ein Mapping durchgeführt. Dieses Mapping kann bei größerer Komplexität der abzubildenden Struktur mit großem Aufwand verbunden sein. Eine entsprechende Schnittstelle muss implementiert und
auf das Datenbanksystem aufgesetzt werden. Formatierungen im abgebildeten
XML-Dokument, welche z.B. zur Unterstützung der Lesbarkeit des Dokumentes vorgenommen wurden, gehen dabei im Normalfall verloren. Bei Änderungen
innerhalb der XML-Struktur der Dokumente oder der Tabellenstruktur des DBMS
ist zudem stets eine Anpassung des Mappings nötig. Auch sind auf diesen Datenbanken keine XML-spezifischen Anfragesprachen wie XPath verfügbar, d.h. die
Selektion (und Manipulation) von Teilen von XML-Elementen wird nicht unter4
BLOB-Datentypen speichern unstrukturierte (binäre) Daten in einer Datenbank
Inv.-Nr.: 2005-06-01/071/IN99/2254
36
KAPITEL 3. METADATEN
stützt.
Diese Nachteile treffen auch auf objektorientierte Datenbankmanagementsysteme (OODBMS) zu. Diese bieten dafür den Vorteil, dass sich XML-Strukturen einfacher in Objekte umformen lassen als in relationale Strukturen. Dies liegt
darin begründet, dass in XML praktisch Objektstrukturen abgebildet sind. Trotz
dessen wird ebenso ein Mapping gebraucht; auch bleibt die mangelnde Unterstützung von XML ein Manko.
Daher ist zur Speicherung von XML der Einsatz eines XML-Datenbanksystems sinnvoll, d.h. ein DBMS, das auf die Speicherung von XML-Daten spezialisiert ist. Im Bereich der (XML-)Datenbanken existieren grundsätzlich zwei
Varianten zur Speicherung von XML-Daten. Zum einen sind dies Datenbanken
mit Erweiterungen zum Speichern von XML, d.h. XML-erweiterte Datenbanken.
Es handelt sich um DBMS, welche auf einem relationalen oder sonstigen System
beruhen, und über Erweiterungen den Datentransfer zwischen XML-Dokumenten
und der Datenbank-eigenen Datenstruktur – sei diese relational, objektorientiert
oder proprietär – ermöglichen. Native XML-Datenbanken stellen die zweite Variante dar und speichern XML-Daten in ihrer strukturierten Form. Dabei sind XMLDokumente die Grundeinheit der logischen Speicherung und die Formatierungen
innerhalb des Dokumentes bleiben erhalten. Es ist kein bestimmtes Datenmodell
vonnöten.
Alle XML-DBMS bieten neben der Speicherung von XML diverse Hilfsmittel an, um diese gespeicherten Daten zu verwalten. Dazu gehören z.B. Anfragesprachen wie XPath oder XQuery, welche auf die speziellen Anforderungen
von XML-Dokumenten zugeschnitten sind. XML-Datenbanken sind daher für den
hier benötigten Einsatzzweck bestens geeignet, da sie auf die einfache Verwaltung
vieler XML-Dokumente spezialisiert sind.
3.3.2 Export nach XMT-SAW
Sind die Daten gespeichert, müssen sie in Form eines XMT-SAW Dokumentes
wieder exportiert werden können. Trivial ist dies im Falle der Speicherung als
XML-Datei: die Daten liegen so schon als XMT-SAW Dokumente vor und müssen nicht konvertiert werden.
Aber auch die Speicherung in einer XML-Datenbank erfordert keinen weiteren Aufwand. Es werden XML-Dokumente aus der Datenbank ausgeliefert, wie
sie auch eingebracht wurden. So werden XMT-SAW Inhalte im selben Format
ausgelesen und z.B. in eine Datei gespeichert, welche anschließend von IOSONO
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
37
eingelesen werden kann.
Die Speicherung in einer Nicht-XML-Datenbank – relational, objektorientiert oder sonstiges – erfordert eine Logik, die aus den Daten wieder ein XMLDokument (speziell ein XMT-SAW Dokument) erzeugt und exportiert. Dies erfordert je nach Modell größeren Aufwand, in Relation zu jenem für das Einfügen
von XML in die Datenbank. Das heißt, es wäre analog zu einem Mapping von
XML auf das datenbankeigene Datenmodell eines von diesem Datenmodell auf
XML nötigt.
Um diesen Aufwand zu vermeiden, stellt eine XML-Datenbank daher auch
hier die beste Wahl dar, wenn man vom trivialen Fall des Dateisystems absieht.
3.3.3 Suche über Metadaten
Bei der Suche sollen XML-Elemente anhand gegebener Attributwerte (und damit
Attributnamen) gefunden und inklusive ihres Inhalts (Attribute, Unterelemente,
. . . ) zurückgeliefert werden. Zur Realisierung dieser Funktion müssen Teile des
Inhalts eines XML-Dokumentes über diese Kriterien gefunden und, falls ein Ergebnis erzielt wurde, ausgelesen werden. Welche Techniken bieten sich dafür an?
Die einfachste Möglichkeit ist der Einsatz einer Anfragesprache wie XPath
oder XQuery. Hier ist es mittels Selektionsausdrücken, die sich einfach erstellen
lassen, möglich, Teile von Dokumenten zu selektieren. Anhand des Ausdrucks
erhält man alle Elemente zurückgeliefert, welche die Anfragebedingung erfüllen.
Das Element wird mit allen Eigenschaften und Unterelementen an den Aufrufer
übergeben. Dies ist genau die Anforderung, welche durch die Suche gestellt wird.
Eine Alternative stellt die Nutzung eines XML-Parsers dar. Lässt man diesen
über alle Elemente eines XML-Dokumentes laufen, kann man in diesem Sinne
alle zugehörigen Attribute und Attributwerte der Elemente abfragen. So kann man
leicht diese Werte mit den gegebenen Referenzwerten vergleichen und im Falle
der Übereinstimmung das entsprechende Element vermerken. Da Parser Zugriff
auf den kompletten Elementinhalt bieten, kann auch hier einfach alles an Inhalt
abgefragt werden. Im Vergleich zum Einsatz von z.B. XPath erfordert dies aber
erhöhten Aufwand. So muss manuell über das ganze Dokument iteriert werden.
Zudem ist der Vergleich aller Kriterien über eigene Funktionen durchzuführen.
Das lässt diese Lösung weniger praktikabel erscheinen.
Diese beiden Alternativen lassen sich für die Verwaltung von XML in Dateien
anwenden, indem externe Programme mit entsprechender Funktionalität erstellt
werden – eine umständliche Lösung, wenn man eine einheitliche und integrierte
Inv.-Nr.: 2005-06-01/071/IN99/2254
38
KAPITEL 3. METADATEN
Verwaltung als Ziel hat.
Auf Seiten der XML-DBMS haben viele eine Anfragesprache wie XPath integriert. Über diese können alle Inhalte der Datenbanken einfach abgefragt werden.
Somit wird die erste vorgestellte Variante, mittels Anfragesprachen zugleich die
einfachste und praktikabelste, ermöglicht.
Für Nicht-XML-Datenbanken ist ein anderer Weg zu wählen. Wegen mangelnder XML-Unterstützung müssen Inhalte entsprechend des gegebenen Datenmodells selektiert werden. Ist ein RDBMS vorhanden, kann über eine Sprache wie
SQL auf Inhalte zugegriffen werden. Wurde ein XML-Dokument in ein BLOB
oder als reiner Text gespeichert, sind die Suchmöglichkeiten eingeschränkt. Es
bleibt nur, eine reine Textsuche durchzuführen. Jedoch gestaltet sich dann sowohl
die Suche von Elementen als auch speziell das Auslesen des Element-Codes umständlich und kompliziert. Wurden die Dokumente über Mappings eingepflegt,
sind bessere Möglichkeiten gegeben. Dann lassen sich Selektionsbedingungen
formulieren, indem Attributname und -wert als Tabellenfeld und dessen Tupelinhalt gesehen werden. So können Elemente gefunden und in XML umgesetzt
werden. Weiterer Aufwand ist aber nötig, um über z.B. Schlüsselbeziehungen
Kindelemente zu finden und auszugeben.
Ebenso ist bei OODBMS vorzugehen, wo Objekte anhand Eigenschaften gefunden werden können. So lässt sich der Attributname auf eine Objekteigenschaft
und der Attributwert auf einen Eigenschaftswert abbilden. Das Mapping von Objekten auf XML ist analog zu RDBMS nötig, auch das Auflösen von ElternKinder-Beziehungen.
3.3.4 Versionierung
Versionierung – dies erfordert, Unterschiede zwischen unterschiedlichen Versionen von Dokumenten zu erkennen und in geeigneter Form zu speichern. Wie lässt
sich nun die Versionierung realisieren? Die einfachste Lösung ist, auf die Fähigkeiten des Datenverwaltungssystems zu vertrauen. Das Problem ist jedoch, dass
z.B. Dateisysteme keine Versionierungsmöglichkeiten bereitstellen.
3.3.4.1 Integriert ins Datenverwaltungssystem
Auch bei den Datenbanken ist die Versionierung keine Selbstverständlichkeit. Jedoch gibt es schon Vertreter, welche ein solches System integriert haben. In diesem Fall kann die Versionierung komplett vom DBMS übernommen werden und
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
39
braucht keine weitere Beachtung zu finden. Immer vorausgesetzt, dass die Versionierungsmechanismen ausreichend für die gestellten Anforderungen sind.
RDBMS setzen Versionierung oftmals auf Tupel-Ebene um. Jedes Tupel kann
einer anderen Version zugeordnet sein. Aus dem Bereich der relationalen DBMS
bietet Oracle5 mit dem Oracle Workspace Manager [6] (OWM) Versionierungsmöglichkeiten an. Dieses System basiert auf einem Versionierungsansatz auf Tupel-Ebene. Über so genannte Arbeitsbereiche (Workspaces) werden Sammlungen
von Tupel-Versionen logisch isoliert. Arbeitsbereich-Hierarchien können dabei
beliebig tief und breit werden. Savepoints gruppieren eine Reihe von Änderungen in einem Arbeitsbereich. Auch die XML-erweiterte Version von Oracle bietet
diese Funktion.
Unter den nicht-kommerziellen Systemen findet sich jedoch kein RDBMS mit
vergleichbaren Eigenschaften, und selbst unter den kommerziellen Anbietern sind
die Eigenschaften einmalig.
In OODBMS hat die Versionierung größere Verbreitung gefunden als in relationalen DBMS. Dabei haben sich verschiedene Techniken herausgebildet. Eine
Lösung ist, bei einem Update eines Objektes eine neue Version desselben an einer
neuen Stelle zu erzeugen. Die alte Version bleibt erhalten. Der Vorteil des Prinzips besteht darin, dass Referenzen auch nach dem Commit eines Updates erhalten
bleiben. Zugriffe werden ab dann automatisch auf die aktuellste Version geleitet.
Umgesetzt wurde dies z.B. bei Matisse6, einem XML-erweiterte OODBMS. Eine
weitere Möglichkeit ist bei Objectivity/DB 7 zu finden, ebenfalls eine Versionierung auf Objekt-Ebene. Hier wird zudem lineares und verzweigtes Versionieren
unterstützt. Auch gibt es das Konzept der Default-Version.
Unter den proprietären XML-Datenbankmanagementsystemen bieten Ipedo 8 ,
Sekaiju9 oder X-Hive/DB10 Versionierungsverfahren. Diese Systeme sind jedoch
alle den kommerziellen Datenbankmanagementsystemen zuzuordnen.
Da viele DBMS – speziell XML-DBMS – keine Versionierung bieten, bleibt
als Lösung, diese selbst zu implementieren. Die Implementierung kann durch verschiedene Mechanismen realisiert werden. Sowohl für allgemeine Dokumente als
auch speziell für XML-Daten gibt es unterschiedliche Ansätze, welche hier aufgezeigt werden.
5
http://www.oracle.com/
http://www.matisse.com/product_information/
7
http://www.objectivity.com/Products/Products.shtml
8
http://www.ipedo.com/html/products.html
9
http://www.mediafusion-usa.com/usa/seihin/sekaiju/index.html
10
http://www.x-hive.com/products/db/index.html
6
Inv.-Nr.: 2005-06-01/071/IN99/2254
40
KAPITEL 3. METADATEN
3.3.4.2 Eigene Versionierung – Versionierung flacher Dokumente
Am einfachsten ist die Versionierung unstrukturierter, flacher Daten wie Text-Dokumente. Hier existieren zeilenbasierte Verfahren wie RCS [2] oder SCCS [3].
Diese durchlaufen zu vergleichende Dokumente zeilenweise, um Änderungen zu
erkennen. Stimmen zwei gleich positionierte Zeilen nicht überein, wird dies als
Unterschied erkannt.
RCS RCS speichert die aktuellste Version eines Dokumentes. Alle anderen Revisionen sind als Edit Skripte gesichert. Durch diese Edit Skripte ist beschrieben,
wie man in der History eines Dokumentes zurück laufen muss. Dies bedeutet,
dass bei dem Retrieval eines Dokumentes für alle Versionen außer der aktuellsten
Bearbeitungsaufwand betrieben werden muss. Die Edit Skripte müssen rückwärts
auf die aktuellste Version angewandt werden.
SCCS SCCS speichert Änderungen nicht durch rückwärts gerichtete Edit Skripte. Es wird stets auf dem aktuellen Dokument gearbeitet und Änderungen eingebracht. Zeitlicher Bezug wird über Zeitstempel erreicht. Diese markieren die
Gültigkeitszeit von Teilen – aufeinander folgende Blöcke von Zeilen – des Dokumentes. Um eine Version zu erhalten, wird das komplette Dokument durchlaufen
und gültige Elemente werden anhand ihrer Zeitstempel ausgewählt.
Nachteile Zeilenbasierte Verfahren arbeiten, wie schon erläutert, auf Dokumentenebene, wo Zeile für Zeile verarbeitet wird und Differenzen als versionsrelevant vermerkt werden. Dies ist grundsätzlich auch auf XML-Dokumente anwendbar. Es bringt jedoch gewisse Einschränkungen mit sich, was mit der strukturellen Komponente von XML-Dokumenten zu tun hat. Diese bilden eine logische
Komposition von Elementen. Dabei können Dokumente auf semantischer Struktur identisch, jedoch auf textueller Ebene verschieden sein. Gerade, wenn XMLDokumente manuell erstellt werden, sind für die Leserlichkeit Leerzeichen und
Zeilenumbrüchen entsprechend der inhaltlichen Struktur eingefügt. Diese Zeichen
ändern aber nichts an dem Inhalt des Dokumentes, auch wenn auf textlicher Ebene
entscheidende Unterschiede entstehen.
Ein Beispiel für zwei textlich unterschiedliche, inhaltlich jedoch identische
Dokumente sind im Folgenden dargestellt.
<XMT-SAW
xsi:schemaLocation="http://www.emt.iis.fraunhofer.de/
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
41
xmt-saw config/schema/xmt-saw.xsd">
<body>
<timecode tcOffset="36000"/>
<room id="room1" roomPresence="0.0"
envelopment="0.0" runningReverb="0.0"
lateReverb="0.0" heaviness="1.0"
liveness="1.0" freqHeavy="250.0"
freqLive="4000.0"/>
<layer id="layer0">
<audio id="10" src="10:d_o" begin="0" end="65"
visible="true" isPlaneWave="false">
</audio>
</layer>
<body>
<XMT-SAW>
Quelltext 3.0: XML-Dokument mit Semantik im Layout
<XMT-SAW
xsi:schemaLocation="http://www.emt.iis.fraunhofer.de/
xmt-saw/config/schema/xmt-saw.xsd">
<body>
<timecode tcOffset="36000"/>
<room id="room1"
roomPresence="0.0"
envelopment="0.0"
runningReverb="0.0"
lateReverb="0.0"
heaviness="1.0"
liveness="1.0"
freqHeavy="250.0"
freqLive="4000.0"/>
<layer id="layer0">
<audio id="10"
src="10:d_o"
begin="0"
end="65"
Inv.-Nr.: 2005-06-01/071/IN99/2254
42
KAPITEL 3. METADATEN
visible="true"
isPlaneWave="false">
</audio>
</layer>
<body>
<XMT-SAW>
Quelltext 3.1: XML-Dokument ohne semantisches Layout
Ein zeilenbasierter Vergleich würde bei diesen Dokumenten in nahezu jeder
Zeile Unterschiede erkennen – das, obwohl der Inhalt identisch ist. Bei einem
Versionierungssystem, das speziell auf XML-Dokumente ausgerichtet ist, sollten
Formatierung oder Layout keinen Einfluss auf die Differenzerkennung von Dokumenten haben. Gleiches gilt für Dokumente, bei denen die Reihenfolge von
Attributen oder Knoten keine Rolle spielt – Umstellungen brauchen hier keine
Beachtung zu finden.
Um diesen Faktoren Rechenschaft zu tragen, gibt es Lösungen, welche speziell auf die XML-Struktur abgestimmt ist.
3.3.4.3 Eigene Versionierung – Versionierung mit XML
Für die Versionierung XML-basierter Daten sind Knoten und deren Attribute die
Grundlage. Bei dem Vergleich zweier Versionen gilt es, Unterschiede in Struktur
und Beziehungen zu erkennen. Dies läuft darauf hinaus herauszufinden, welche
Knoten hinzugekommen sind oder entfernt wurden. Dies gilt für alle Knoten auf
beliebiger Tiefe. Auch neue, gelöschte und veränderte Attribute sind zu erkennen.
Zusammengefasst erfordert der Versionsvergleich die Erkennung von:
• gelöschten Elementen
• geänderten Elementen
• hinzugekommenen Elementen
• verschobenen Elementen (optional)
Für die Versionierung entscheidend ist nun sowohl die Erkennung der genannten Unterschiede (mehr dazu in 3.5.1) als auch ein Verfahren, diese zu speichern.
Für letzteres gibt es diverse Ansätze, welche in den nächsten Abschnitten vorgestellt werden.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
43
Zur Realisierung von Versionen müssen die Unterschiede zwischen zwei Dokumentenzuständen gespeichert werden. Die Unterschiede sind mit entsprechenden Mitteln einem jeweiligen Zustand – d.h. einer Version – zuzuordnen. Dazu
existieren verschiedene Verfahren. Ein Ausschnitt daraus wird den nächsten Abschnitten vorgestellt.
Ein Großteil der aufgeführten Verfahren arbeitet mit Zeitstempeln. Damit sind
Versionsverfolgungen anhand genauer Zeitangaben möglich. Zum Beispiel lässt
sich nach der Version eines Dokument an einem bestimmten Datum fragen. Realisiert werden diese Verfahren mittels Zeitwerten, welche vorhandenen oder einzufügenden XML-Elementen zugewiesen werden. Diese Versionierungsinformationen werden in das zu versionierende Dokument eingebracht, d.h. es werden keine
weiteren Daten neben diesem Dokument angelegt.
Gültigkeitskontexte Bei diesem Verfahren, vorgestellt von Grandi und Mandreoli [14], wird auf Zeitstempeln operiert. Bereiche von XML-Dokumente werden, ähnlich wie Blöcke bei SCCS, mit diesen versehen. Dafür wird ein valid-Tag
eingeführt, das den zu versionierenden Bereich umschließt. Die Zeitstempel werden in Form eines <validity>-Elementes gesichert. Zur Umsetzung muss bei der
Abfrage abhängig von Zeitstempeln gearbeitet werden, um nur dementsprechend
gültige Elemente zu erhalten.
Als Nachteil kann gewertet werden, dass bei Attribut-Änderungen eines Elementes das ganze Element komplett in der neuen Version gespeichert werden
muss, auch wenn nur ein Attribut Änderungen aufweist. Bei XMT-SAW Dokumenten, wo Elemente grundsätzlich viele Attribute enthalten, führt dies leicht zu
großem Overhead.
τ XQuery Dies ist ein auf XQuery basierendes und aufwärtskompatibles Format, entwickelt von Gao und Snodgrass [12]. Es benutzt τ XSchema [9] für Datentypen, welche Zeitwerte anbieten. Entsprechende Elemente und Attribute werden
eingesetzt, um Zustände festzuhalten. Ein solches Tag ist timeVaryingAttribute,
das über die Attribute vtBegin und vtEnd die Gültigkeitszeit angibt. Zudem existiert ein timestamp-Tag zur Festlegung der Gültigkeit von Elementen.
Im Gegensatz zu den Gültigkeitskontexten werden Attribute gesondert versioniert, daher sind die Elternelemente von Attribut-Änderungen nicht in der Versionierung betroffen. Jedoch erfordert dieser Mechanismus, dass jedes Attribut
von einem timeVaryingAttribute-Element umgeschlossen wird, was grundlegend
wiederum Overhead nach sich zieht.
Inv.-Nr.: 2005-06-01/071/IN99/2254
44
KAPITEL 3. METADATEN
Temporal XPath Data Model Dies bezieht sich auf [4] und stellt eine Erweiterung von XPath um zeitliche Aspekte für die Versionierung vor. Dafür wird ein
Namespace time eingeführt, welcher diverse Attribute und Elemente umschließt.
Das Attribut valid wird Elementen zugeordnet und legt deren Gültigkeitszeit fest.
Die Elemente time:attribute und time:stringValue setzen die Versionierung von
Attributen und Textelementen um.
Grundsätzlich gilt hier das Gleiche wie für τ XQuery: das Verfahren produziert
Overhead für alle Attribute. Elemente werden mittels eines Attributes versioniert,
wodurch für diese kein extra Element eingefügt werden muss. Bei τ XQuery wird
dagegen die Attributmenge des Elementes nicht verändert.
τ τ XPath τ τ XPath ist ebenfalls eine Erweiterung von XPath und bleibt dabei
abwärtskompatibel. Vorgestellt wurde das Prinzip von Dyreson [10]. Ausgegangen wird hier von einer Client-Server-Architektur.
Da dies im IOSONO-System (noch) nicht der Fall ist, wird dieses Prinzip nicht
weiter untersucht.
T-XPath Kalb et al. stellen in [20] eine aufwärtskompatible Erweiterung von
XPath dar. Es werden atomare zeitliche Datentypen und Operationen für diese
eingeführt. value und valid_time sind z.B. Elemente, welche für Textelemente den
Wert und die zugehörige Gültigkeitszeit festhalten.
Deltas Deltas verfolgen ein anderes Prinzip als Zeitstempelverfahren. Es werden nicht jedem Element oder Attribut Zeitwerte zugeordnet. Stattdessen werden alle Änderungen zwischen zwei Zuständen (Versionen) gruppiert zusammengefasst und gespeichert [22]. Das Ausgangsdokument, z.B. die aktuellste Dokumentversion, bleibt im Gegensatz zu Zeitstempelverfahren unverändert. Stattdessen werden alle Änderungen in externen Strukturen verwaltet. Dies bedeutet z.T.
geringeren Overhead als bei Zeitstempel-Verfahren, da nur tatsächlich veränderte Elemente ein umschließendes Element erhalten, das die Änderung beschreibt.
Alle anderen Dokumententeile bleiben unverändert und ohne zusätzliche Informationen.
Fazit Letztendlich bieten sich somit verschiedene Möglichkeiten, die Versionsunterschiede von XMT-SAW Dokumenten zu beschreiben. Ungeeignet sind Verfahren wie Gültigkeitskontexte, da sich hier Attribut-Änderungen auf das ganze
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
45
Element niederschlagen – ungünstig bei XMT-SAW Dokumenten, wo jedes Element bis zu 10 oder mehr Attribute enthält. Bei einer Attributänderung müsste der
ganze zugehörige Knoten in der neuen Version gespeichert werden.
Dagegen ist z.B. τ XQuery günstig, da hier Elemente und Attribute getrennt
über Zeitstempel versioniert werden. Diese feingranulare Versionierung scheint
für XMT-SAW Dokumente gut geeignet. Ebenso bietet sich die Verwendung von
Deltas an, da hier nur Versionierungsdaten für Elemente vermerkt werden, die
tatsächlich einer Änderung unterliegen. Deltas können dabei in Zusammenhang
mit jedem Datenverwaltungssystem umgesetzt werden. Für τ XQuery muss dieses Anfragen über XQuery unterstützen, und dabei zusätzlich die Definition von
XQuery-eigenen Funktionen erlauben. Dies schränkt die Auswahl an verfügbaren Datenverwaltungssystemen wiederum ein. Werden XMT-SAW Dokumente als
Dateien gespeichert, kann ein externes Programm τ XQuery umsetzen. Bei den
DBMS dagegen existieren nur XML-Datenbanksysteme mit XQuery-Unterstützung, bei allen anderen Arten fehlt diese. Dort kann τ XQuery nicht verwendet
werden. Unter den Vertretern mit guter XQuery-Funktionalität findet sich z.B.
Berkeley DB XML.
3.3.5 Lange Transaktionen
Lange Transaktionen finden in RDBMS nahezu keine Unterstützung. Ausnahme hier ist wiederum Oracle mit dem OWM. Dieser implementiert auf Basis
der Workspaces ein Framework für lange Transaktionen. Mittels Standardtransaktionen und mehreren Datenversionen werden lange Transaktionen implementiert,
welche Atomarität und Nebenläufigkeit erfüllen.
Somit kann auch diese Anforderung von einem RDBMS erfüllt werden. Unter den nicht-kommerziellen Systemen findet sich jedoch kein System mit vergleichbaren Eigenschaften, und auch unter den kommerziellen Anbietern sind die
Eigenschaften recht einmalig.
Im Gegensatz dazu realisieren diverse OODBMS lange Transaktionen. Hier ist
z.B. wiederum Objectivity/DB vertreten. Lange Transaktionen werden dort über
das Ein- und Auschecken von Daten realisiert. Dabei werden Container oder Datenbanken für eine erweiterte Zeitperiode gesperrt, statt der sonst üblichen Session
pro Nutzer. Über Sperrverfahren werden somit lange Transaktionen unterstützt –
ein pessimistische Verfahren, das wenig Kooperation und Parallelität bietet.
Weitere Systeme bieten lange Transaktionen ebenfalls über das Prinzip des
Ein- und Auscheckens, aber basierend auf lokalen Arbeitsbereichen. Die Daten
Inv.-Nr.: 2005-06-01/071/IN99/2254
46
KAPITEL 3. METADATEN
werden in diese Arbeitsbereiche kopiert und Updates dort ausgeführt. Nach Ende des Bearbeitungsvorgangs werden die Änderungen auf die eigentlichen Daten
angewandt. Diese Vorgehensweise erlaubt die Bearbeitung derselben Daten durch
mehrere Nutzer und unterstützt dabei stärker die Parallelität als bei Sperrverfahren.
Des Weiteren wird mit geschachtelten Transaktionen gearbeitet, wobei eine
Transaktion in mehrere Subtransaktionen aufgeteilt wird. Dies hilft, Transaktionen übersichtlich zu halten und Teilschritte abschließen zu können.
Fazit ist, dass nur DBMS die Möglichkeit bieten, lange Transaktionen in integrierter Form zu nutzen. Sollte man kein DBMS benutzen, oder dieses keine langen Transaktionen unterstützen, muss ein eigenes System implementiert werden.
Möglichkeiten dazu werden in „Lange Transaktionen“, Abschnitt 3.7.2, näher betrachtet.
3.3.6 Evaluierung
In den vorherigen Teilabschnitten wurden diverse System zur Realisierung der
Anforderungen aufgeführt. Dabei lässt sich als Fazit Folgendes feststellen:
Die wenigsten Möglichkeiten für die Verwaltung der Metadaten bieten Dateisysteme. Zwar gestalten sich Speicherung und Export der Daten trivial. Jedoch
findet sich keinerlei integrierte Unterstützung für Versionierung, Suche oder lange Transaktionen. Diese müssen daher über externe Programme zur Verfügung
gestellt werden. Auch ist keine zentrale Speicherstelle gegeben; die Verwaltung
und Kontrolle über die Dokumente müsste ebenfalls über ein zentrales Verwaltungsprogramm organisiert werden.
Relationale oder objektorientierte DBMS bieten da nicht viel mehr. Zwar sind
z.B. Transaktionen oder Mehrbenutzerunterstützung als Datenbankfeatures integriert. Auch ist eine zentrale Speicherung und Verwaltung aller Daten gegeben.
An der Erfüllung der gestellten Anforderungen mangelt es jedoch. Zudem wird
ein Mapping der XML-Daten auf das Datenbankmodell benötigt, wenn man wenigstens rudimentäre Unterstützung der strukturellen Eigenschaften der verwalteten XML-Dokumente erhalten will. Letztendlich bleibt somit ein gegenüber dem
Dateisystem erhöhter Aufwand, mit dem Vorteil der Datenbankeigenschaften.
3.3.6.1 XML-Datenbanken
Die beste Wahl stellt eine XML-Datenbank dar, speziell in Bezug auf die Verwaltung der XML-Dokumente. Sie bieten ebenfalls Datenbankfeatures wie TransakInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
47
tionen oder Sperren. Auch lässt sich bei Vorhandensein von Anfragesprachen wie
XPath die Suche einfach realisieren. Zudem finden sich in einigen die Unterstützung für Versionierung oder lange Transaktionen.
Daher ist zu entscheiden, welche der verfügbaren XML-Datenbanken für die
Implementierung gewählt wird.
Der Bereich der XML-erweiterten Datenbanken wird generell nur von kommerziellen RDBMS und OODBMS abgedeckt. Diese bleiben somit außen vor.
Native XML-Datenbanken sind sowohl kommerziell als auch als Open Source
in großer Zahl verfügbar. Sie basieren auf den unterschiedlichsten Datenbankmodellen und bieten unterschiedlichste Variationen an Features.
Schaut man sich bei XML-Datenbanken die Features an, bietet sich folgendes
Bild:
• Alle Datenbanken erlauben die native Speicherung von XML.
• Integrierte Versionierung bieten Ipedo, Sekaiju oder X-Hive/DB – alle sind
kommerzielle DBMS.
• Lange Transaktionen sind in keinem der Vertreter zu finden, müssen daher
selbst implementiert werden.
• Standard-Datenbankfeatures wie Transaktionen oder Sperren sind dagegen
im Normalfall enthalten. Systeme mit diesen Funktionen sind in größerem
Maße auch nicht-kommerziell verfügbar.
• Unterschiede finden sich in der Unterstützung von XPath oder XQuery sowie der Schnittstelle für den Zugriff. Bei letzterem ist eine C++-Schnittstelle
wünschenswert, da IOSONO komplett in C++ umgesetzt ist. Auch gibt es
Unterschiede in der Art der Datenbank, wo Standalone-Systeme ebenso angeboten werden wie eingebettete Lösungen. Hier wäre eine eingebettete
Lösung wünschenswert, da so zusätzlicher Installations- und Konfigurationsaufwand komplett entfällt.
Letztendlich stehen mehrere Open Source XML-DBMS zur Auswahl, welche
ähnliche Eigenschaften anbieten. Tabelle 3.1 zeigt eine nähere Gegenüberstellung
der Features. Neben den integrierten Abfragesprachen (XPath, XQuery), Updatemöglichkeiten (XUpdate) und den unterstützten Parsermodellen (DOM/SAX)
interessieren auch Standard-Datenbankfeatures wie Transaktionen und Indexe.
Inv.-Nr.: 2005-06-01/071/IN99/2254
48
KAPITEL 3. METADATEN
Zudem, wie schon angesprochen, die Verfügbarkeit einer C++-Schnittstelle. Aufgezeigt sind die Systeme 4suite11, dbXML12 , Berkeley DB XML13 , eXist14 sowie
OZONE15 und Xindice16 .
4suite BDB XML dbXML eXist OZONE Xindice
XPath
x
x
x
x
x
x
x
XQuery
x
x
x
x
x
XUpdate
DOM
x
x
x
x
SAX
C++-API
x
x
x
x
x
(x)
Trans.
x
x
x
x
?
x
Indexe
Tabelle 3.1: Native XML-Datenbanken
Nach Bewertung der Eigenschaften zeigen sich Berkeley DB XML und eXist
als die besten Alternativen. Die Wahl fällt schließlich auf Berkeley DB. Als der
Hauptgrund kann die C++-Schnittstelle gesehen werden, welche eine leichte Integrierbarkeit in IOSONO gewährleistet. Weiterhin unterstützt es im Gegensatz zu
eXist Transaktionen, welche in jeder Datenbankumgebung ein nützliches Feature
darstellen.
Offene Themen bzgl. Berkeley DB XML bleiben lange Transaktionen und
die Versionierung, welche über eine eigene Implementierung eingebracht werden
müssen. Positiv: XQuery wird inkl. der Definition von Funktionen unterstützt,
somit kann die Versionierung angelehnt an τ XQuery realisiert werden.
Da nun die komplette Umsetzung der Verwaltung der Metadaten mittels Berkeley DB XML umgesetzt wird, folgt hier eine Vorstellung dieses DBMS. Anschließend befassen sich die Abschnitte 3.4, 3.5 und 3.6 mit der Umsetzung der
Anforderungen: Speicherung von XMT-SAW, Versionierung und Suche mit Hilfe
von BDB XML. Darauf folgt ein Ausblick über noch offene Themen dieser Arbeit
im Abschnitt 3.7.
11
http://4suite.org/index.xhtml
http://www.dbxml.com/product.html
13
http://www.sleepycat.com/products/xml.shtml
14
http://exist.sourceforge.net/
15
http://ozone-db.org/frames/home/what.html
16
http://xml.apache.org/xindice/
12
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
49
3.3.7 Berkeley DB XML
Berkeley DB XML ist eine Datenbankbibliothek. Es basiert auf Berkeley DB, das
nun kurz vorgestellt wird. Anschließend werden Datenverwaltung und Datenbankfeatures des DBMS aufgezeigt.
3.3.7.1 Berkeley DB
Bei Berkeley DB handelt es sich um eine Datenbankbibliothek, im Gegensatz zu
einem Standalone-DBMS. Das heißt: die Bibliothek wird direkt zum Programm
gelinkt; damit sind die Datenbankfunktionen sofort verfügbar. Über Funktionsaufrufe sind alle Zugriffe und Abfragen auf die Inhalte der Datenbank durchführbar.
Ebenso sind damit direkte Eingriffe in die Datenbankkonfiguration möglich, wie
z.B. auf Cachegröße oder Zugriffsmethode. Dafür werden diverse APIs zur Verfügung gestellt, u.A. in C, C++ und JAVA. Durch die Verfügbarkeit für nahezu alle
Plattformen ist BDB universell einsetzbar.
Der Datenbank liegt kein relationales, objektorientiertes, oder sonstiges gebräuchliches Datenmodell zugrunde. Stattdessen werden Daten in proprietärer
Form in einfachen Datensätzen abgelegt. Diese Datensätze bestehen aus einem
Schlüssel, welcher der Identifikation beim Zugriff dient, sowie den eigentlichen
Daten. Von BDB werden diverse Zugriffsmethoden und Arten des Datenzugriffs
angeboten. Näheres dazu wird im Zusammenhang mit der Speicherung der Audiodaten (Kapitel 4, ab Seite 91) vorgestellt.
3.3.7.2 Datenverwaltung
Grundlage aller Betrachtungen ist die Art der Verwaltung von XML-Daten durch
Berkeley DB XML [28]. Grundsätzlich geschieht die Ablage der Daten in nativer
Form. Dabei werden XML-Dokumente in so genannten Containern gespeichert
und verwaltet. Ein Container ist eine einzelne Datei, welche ein oder mehrere
XML-Dokumente sowie deren Metadaten und Indizes enthält. Zu jedem Dokument können beliebige Metadaten hinzugefügt werden, d.h. Daten außerhalb der
Dokumentenstruktur. Auch ist die Erstellung von Indizes über beliebige Teile eines Dokumentes möglich.
BDB bietet zwei Möglichkeiten zur Speicherung von XML-Dokumenten in
Containern: als ganzes Dokument sowie aufgesplittet in die Dokumententeile. Bei
der Speicherung als Ganzes wird das Dokument komplett erhalten und abgelegt,
inklusive aller Leerzeichen und Zeilenumbrüchen. Bei der Speicherung in Teilen
Inv.-Nr.: 2005-06-01/071/IN99/2254
50
KAPITEL 3. METADATEN
wird das Dokument so aufgeteilt, dass jeder Datensatz der Datenbank einen Blattknoten mit allen Attributen, Attributwerten und Textknoten enthält. Grundsätzlich sollte für die Speicherung kompletter Dokumente deren Größe 1 MB nicht
übersteigen, da andernfalls starke Performance-Einbußen zu erwarten sind. Jedoch wird für oftmaliges Retrieval ganzer Dokumente die komplette Speicherung
bevorzugt.
3.3.7.3 Features
Auf Daten in der Datenbank können XPath-Anfragen angewandt werden, um Dokumente oder Teile von diesen abzufragen. Da XQuery eine Erweiterung von
XPath 2.0 ist, wird diese Sprache ebenfalls unterstützt.
Das Datenbanksystem bietet des Weiteren integrierte Funktionen zur Modifikation, dem Hinzufügen und Entfernen von Dokumententeilen – eigener Code zur
Manipulation von z.B. DOM-Bäumen ist dadurch überflüssig. Realisiert wird dies
wiederum über XQuery-Ausdrücke.
Auch datenbankspezifische Eigenschaften wie Transaktionen, Logging und
Sperren werden von Berkeley DB XML zur Verfügung gestellt. Dies bildet die
Grundlage, um stets einen konsistenten Datenbestand zu gewährleisten sowie eine mehrbenutzerfähige Anwendung unter Nutzung von BDB XML zu realisieren.
Mittels Recovery-Tools lässt sich zudem nach Systemabstürzen oder sonstigen
Problemen ein konsistenter Datenbankzustand wiederherstellen.
3.4 Speicherung von XMT-SAW Dokumenten
Die erste umgesetzte Anforderung betrifft die Speicherung der Metadaten. Alle Metadaten sind im XMT-SAW Format gespeichert, einer XML-basierten Beschreibungsform. Für die Speicherung und Verwaltung derselben wurde in Kapitel 3.3 BDB XML ausgewählt. Diese XML-Datenbank bietet gerade mit Blick auf
die Anforderung „Export nach XMT-SAW“ den entscheidenden Vorteil, dieses
ohne zusätzlichen Aufwand umsetzen zu können. Die Struktur der von Spamix
ausgegebenen XMT-SAW Dokumente muss nicht angetastet werden. Sie werden
wie bisher von Spamix erzeugt, um dann anstatt auf die Festplatte in die Datenbank transferiert zu werden. Ebenso problemlos gestaltet sich das Auslesen von
Dokumenten aus der Datenbank, d.h. der Export nach XMT-SAW, da nur die Daten aus der Datenbank ausgelesen werden und so fertig verwendbar vorliegen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
51
Abbildung 3.2: Verwaltungsstruktur für XMT-SAW Dokumente
Da somit der Export der Daten trivial ist, wird diese Anforderung nicht weiter betrachtet. Erst während der Erläuterungen zur programmiertechnischen Implementierung (Abschnitt 3.8 auf Seite 89) wird nochmals darauf eingegangen,
speziell in Zusammenhang mit dem Versionierungssystem.
Offen ist daher vorrangig das Thema der Konzeption einer geeigneten Verwaltungsstruktur für in die Datenbank eingepflegte XMT-SAW Dokumente. Dieses
Thema wird nun eingehend behandelt.
3.4.1 Überblick
In Berkeley DB XML werden XML-Dokumente unter einem eindeutigen Namen
(dem Identifier) gespeichert. Über diesen ist das Dokument jederzeit abrufbar. So
lassen sich (theoretisch) unbegrenzt XMT-SAW Dokumente in der Datenbank ablegen, immer unter Angabe dieses eindeutigen Namens. Jedoch ist kein Bordmittel
vorhanden, um einfach Überblick über den Inhalt der Datenbank zu erhalten. Insbesondere im vorliegenden Anwendungsfall, der die Versionierung einbezieht, ist
eine Übersicht über eingepflegte Dokumente incl. aktueller Version sinnvoll.
Ausgangspunkt ist daher die von BDB umgesetzte Speicherung von XMLDokumenten unter einem eindeutigen Namen. Darauf basierend wird eine erweiterte Verwaltung angelegt, um XMT-SAW Inhalte zu pflegen.
3.4.2 Verwaltungsstruktur
Für die Verwaltung der XMT-SAW-Dokumente wird in der Datenbank eine XMLStruktur angelegt, die in Abbildung 3.2 vorgestellt ist. Diese erlaubt es, einen
Überblick über alle in der Datenbank enthaltenen Dokumente zu erhalten. Informationen wie aktuelle Version und zugehöriger Kommentar sind dabei integriert.
Oberstes Element ist der Knoten docs. Für jedes XMT-SAW Dokument in der
Inv.-Nr.: 2005-06-01/071/IN99/2254
52
KAPITEL 3. METADATEN
Datenbank wird diesem ein doc genannter Knoten zugeordnet, welcher das Dokument repräsentiert. Dessen Attribute sind name und id. Name ist ein verständlicher
und aussagekräftiger Name für das Dokument, der vom Benutzer beim Einpflegen
in die Datenbank zu wählen ist. Id ist der Identifier, welcher zur Identifikation des
Dokumentes in der Datenbank angelegt und genutzt wird. Er wird bei Eingabe eines Dokumentes automatisch vom Programm angelegt. Mit diesen Informationen
hat man einen Überblick über den Inhalt der Datenbank.
Das doc-Element wird des Weiteren auch für die Versionsverwaltung benötigt.
Um schnell die derzeit aktuelle Version des Dokuments in der Datenbank auslesen zu können, erhält das doc-Element ein Kind namens version. Dieses Element
enthält nur einen Text-Knoten, welcher die Version in Form einer Zahl angibt.
Weiterhin wird dem Umstand Rechnung getragen, dass bei vielen Versionen
schnell der Überblick über die jeweiligen Änderungen verloren geht. Zwar lassen
sich die Änderungen schnell auslesen. Jedoch erkennt man anhand der empfangenen XML-Daten nicht sofort die eigentlichen Veränderungen. Daher wird ein
comment genannter Knoten als Unterelement von doc eingefügt. Für jede Version des Dokumentes in der Datenbank kann dieser Knoten angelegt werden. Zu
welcher Version der Kommentar gehört, ist anhand des Attributes version erkennbar. Damit ist ein leichteres Auffinden einer bestimmten Änderung anhand des
Kommentars möglich. Dieser findet sich als Text im comment-Element wieder.
Diese einfache XML-Struktur wird wie die eigentlichen Dokumente in der
Datenbank abgespeichert und erfüllt in dieser Form die grundlegenden Verwaltungsfunktionen. Für Features wie Versionierung oder Suche sind weitere Datenstrukturen gefragt, welche in den folgenden Abschnitten vorgestellt werden.
3.4.3 Implementierung
Der zentrale Punkt aller Aktionen der Datenverwaltung ist eine grafische Oberfläche, die neu implementiert wurde. Diese ist in das aktuelle Spamix integriert und
ermöglicht die Steuerung aller Funktionen, welche die Datenverwaltung anbietet.
Dies sind im Einzelnen:
• Einfügen eines neuen Dokumentes in die Datenbank von Festplatte
• Einfügen eines in Spamix neu erstellten Dokumentes in die Datenbank
• Einfügen einer neuen Version eines Dokumentes von Festplatte
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
53
• Speichern des aktuellen Bearbeitungszustandes eines Dokumentes in der
Datenbank
• Entfernen von Dokumenten aus der Datenbank
• Suche von Elementen
• Indizierung von Dokumenten für die Suche
• Export von Dokumenten
Die grafische Schnittstelle, inklusive der Präsentation aller Dialoge, ist in der
Klasse DbFrontend umgesetzt. Diese wird in die vorhandene Implementierung
eingebunden. Sie stellt die Nutzerschnittstelle zur Verfügung und leitet die Aktionen an die anderen Klassen weiter, welche die eigentliche Anwendungslogik
implementiert haben.
Den Mittelpunkt der Logik bildet die Klasse XMTSAWDbHandler. Diese wird
von DbFrontend benutzt.
Zur Verwaltung des Datenbestandes dienen die Funktionen:
• getDocs Informationen über alle Dokumente in der Datenbank abfragen
• getChanges Versionshistorie für ein Dokument abfragen
• getComment Kommentar zu einem Dokument in einer bestimmten Version
abfragen
Sowohl getDocs als auch getComment bedienen sich der Informationen unterhalb des docs-Elementes, vorgestellt in Abschnitt 3.4.2 auf Seite 51. Von dort
lassen sich über XPath-Anfragen der Form
collection(’<containerName>’)/docs/doc
die benötigten Informationen abfragen. Es finden sich Name, Identifier und Version aller Dokumente innerhalb des doc-Elementes, welche so einfach ausgelesen
werden können.
Den Kommentar kann man für jedes gewünschte Dokument über den Ausdruck
collection(’<containerName>’)/docs/doc[@id=’docId’]
/comment[@version=5]
Inv.-Nr.: 2005-06-01/071/IN99/2254
54
KAPITEL 3. METADATEN
erhalten. Für das Dokument mit dem Identifier „docId“ in der Version 5 wird hier
der Kommentar ausgelesen.
Die Funktion getChanges wiederum nutzt die Informationen in den gespeicherten Dokumenten, um die Änderungen zwischen zwei Versionen abzufragen.
Dazu werden timestamp- und timeVaryingAttribute-Elemente im Dokument gesucht, deren Anfangs- oder Endzeit (vtBegin und vtEnd) mit der gewünschten Version übereinstimmen. Bei gleicher Anfangszeit wurde das Element in der Version
hinzugefügt oder geändert, bei Endzeit entfernt. Elemente und Attribute, die diese
Bedingung erfüllen, werden daher als Änderung zurückgegeben.
3.4.3.1 Export
Um Dokumente zu exportieren, stehen in XMTSAWDbHandler die Funktionen
exportDocument und getDocument zur Verfügung. Erstere exportiert das Dokument in eine Datei, letztere dagegen importiert das Dokument nach Spamix, um es
dort zu bearbeiten. Beide Funktionen fragen die zu exportierende Dokumentversion aus der Datenbank ab, unter Benutzung der XQuery-Funktion in Anhang A.1.
Zurückgeliefert wird dabei ein XmlDocument-Objekt, das in BDB XML ein
XML-Dokument repräsentiert. Dieses hält die Struktur des in der gewünschten
Version angeforderten Dokumentes. Über Funktionen des Xerces-Parsers17 kann
es in eine Datei geschrieben werden. Um die Verwendung des Dokumentes in
Spamix zu erlauben, wird der Dokumentinhalt dagegen in einen Speicherbereich
transferiert und so dem in Spamix verwendeten XML-Parser zur Verfügung gestellt. Dieser liest die Dokumentenstruktur ein und erzeugt die Spamix-interne
Repräsentation der Szenenbeschreibung.
Für Versionierung, Suche und Export sind eigene Funktionen und Klassen implementiert, welche in den folgenden Abschnitten noch erläutert werden.
3.5 Versionierungssystem
Verfahren zur Speicherung von Versionsdaten wurden schon ausgiebig vorgestellt.
Eigenschaften wurde zwei Ansätze für die Versionierung als positiv gewertet: ein
Verfahren auf Basis von Zeitstempeln sowie eines mit dem Einsatz von Deltas.
Dieser Abschnitt behandelt die Frage, welches Verfahren für die XMT-SAW spezifische Versionierung unter Verwendung von Berkeley DB die besseren Ergebnisse liefert. Eine Gegenüberstellung wird anhand der jeweiligen Eigenschaften
17
http://xml.apache.org/xerces-j/
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
55
und Ergebnisse in verschiedenen Untersuchungen eine Entscheidung zugunsten
eines der Verfahren liefern. Details hierzu gibt der Teil „Speicherung von Versionsdaten“ ab Seite 59.
Doch vorher wird der bis hierhin offene Punkt der Bestimmung dieser Versionierungsdaten bei zwei gegebenen XMT-SAW Dokumenten behandelt. Der kommende Teilabschnitt widmet sich diesem Thema.
3.5.1 XMT-SAW spezifische Bestimmung von Versionierungsdaten
Allen Versionierungsverfahren ist gleich, dass die Unterschiede zwischen zwei
Versionen erkannt werden müssen. Die möglichen Änderungen wie neue Knoten
oder veränderte Attribute wurden bereits vorgestellt. Eine Erkennung derselben
erfordert andere Schritte als bei zeilenbasierten Verfahren, wie in diesem Zusammenhang schon erläutert wurde. Wie sich dies mit XMT-SAW Dokumenten umsetzen lässt, ist Inhalt dieses Abschnitts.
3.5.1.1 Persistente Identifier (PID)
Die Möglichkeit, dass viele Knoten in einem XML-Dokument denselben Namen
haben können, erschwert die Differenzierung beim Dokumentenvergleich. Wurde
einer von verschiedenen gleichnamigen Knoten zwischen zwei Versionen verändert, ist nicht immer erkennbar, welcher von diesen verändert wurde. Eine eindeutige Zuordnung ist schwer möglich.
Daher ist für die Versionierung mit XML (somit auch XMT-SAW) die Identifizierbarkeit von Knoten entscheidend. Um dies zu ermöglichen, werden persistente
Identifier eingeführt. Dies sind eindeutige Identifikatoren, welche jedem Knoten
zugewiesen werden, diesen innerhalb aller Dokumente eindeutig machen und mit
dem Dokumenteninhalt in der Datenbank gespeichert werden.
Über diese Identifier ist es problemlos möglich, Elemente eines Dokumentes
über viele Versionen verfolgen und unterscheiden zu können. Dies ist wichtig
für eine Vereinfachung der kompletten Versionierung. Anhand des PID kann man
bei gegebenem Knoten diesen in einem anderen Dokument suchen. Bei NichtAuffinden ist dieser dort entfernt. Falls gefunden, kann einfach die Attributmenge
der Knoten auf Unterschiede untersucht werden.
Das Vertrauen in PIDs erfordert, dass jedem Knoten eines XMT-SAW Dokumentes ein solcher zugewiesen wird, da andernfalls der entwickelte Algorithmus
Inv.-Nr.: 2005-06-01/071/IN99/2254
56
KAPITEL 3. METADATEN
Knotenname Attribut
room
id
layer
id
audio
id
additionalSrc
src
spamixSrc
ref
Tabelle 3.2: ID-geeignete Attribute
fehleranfällig oder unkorrekt arbeiten könnte. Dabei ist ein vereinfachender Faktor in der Struktur von XMT-SAW Dokumenten zu beachten: das Vorhandensein
von als PID nutzbaren Attributen.
Nutzbare Ids Die XMT-SAW spezifische Versionierung ermöglicht es, bezüglich der Zuweisung von PIDs eine Vereinfachung vorzunehmen. Grund hierfür
ist, dass das Schema für XMT-SAW Dokumente für eine Vielzahl der Knoten ein
Attribut aufweist, das sich als Identifier einsetzen lässt.
Voraussetzung ist dabei, dass jeder Knoten für dieses Attribut einen dokumentenweit eindeutigen Wert zugewiesen bekommt. Ist das entsprechende Attribut
eines Knotens in einem gegebenen Dokument vorhanden und dessen Wert eindeutig, ist das Einfügen eines PID für diesen Knoten unnötig. Dies spart Aufwand
bei der Dokumentenverwaltung sowie unnötigen Overhead durch doppelte Identifikationsmöglichkeiten.
Tabelle 3.2 zeigt einen Ausschnitt von Knoten mit zugehörigen, als Identifier
nutzbaren Attributen.
Des Weiteren existieren Elemente, welche in jedem Dokument nur ein Mal
auftreten können – daher muss für diese keine PID erzeugt werden. Dazu gehören
XMT-SAW, body, head, spamixCfg oder Timestamp.
Verwaltung von PIDs Trifft die Versionsverwaltung bei einem neu zu verwaltenden Dokument auf einen Knoten, bei dem das zugehörige Attribut nicht gesetzt wurde, oder bei dem kein geeignetes Attribut existiert, so muss ein Identifier
generiert und eingefügt werden. Zu diesem Zweck werden alle Knoten eines neuen Dokumentes, oder einer neuen Version eines existierenden Dokumentes, auf
das Vorhandensein eines PID-fähigen Attributes oder eines PID überprüft. Jedes
Dokument wird nur inklusive der PIDs abgespeichert, d.h. es existieren in der
Verwaltung keine Dokumente mit nicht eindeutig identifizierbaren Knoten.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
57
Das PID-Prinzip erfordert auch, dass Änderungen an Dokumenten, welche der
Versionsverwaltung unterliegen, nur auf Dokumenten aus der Datenbank geschehen dürfen. Hier haben alle Knoten einen PID, die zur Bearbeitung mit ausgeliefert wird. Beim Rückschreiben der geänderten Version lassen sich Änderungen
wie beschrieben auf den Identifikatoren basierend nachvollziehen. Würde jedoch
ein externes, nicht in der Datenbank verwaltetes Dokument als neue Version eingefügt, wären in diesem noch keine PIDs vergeben worden. Somit würden auch
Knoten, die keinerlei Unterschiede aufweisen, mangels übereinstimmender Identifikation als verschieden erkannt.
3.5.1.2 Reihenfolge und Textinhalte von Knoten
Weiterer Faktor für eine Differenzerkennung von XML-Dokumenten ist die Reihenfolge von Knoten. Im hier vorgestellten Fall wird die Versionierung dadurch
erleichtert, dass Knoten in XMT-SAW Dokument unabhängig von der Reihenfolge sind. Somit ist die Reihenfolge von Elementen bei der hier vorgestellten
Versionierung nicht berücksichtigt, d.h. verschobene Elemente werden nicht vom
System als Unterschied erkannt.
Auch zu beachten ist der Umstand, dass XMT-SAW Dokumente keine reinen
Textknoten oder uninterpretierte Elemente (CDATA) besitzen. Somit treten Elemente der Form
<element>text</element>
nicht auf. Veränderte Textinhalte von Knoten müssen daher nicht erkannt werden.
3.5.1.3 Prinzip der Differenzbestimmung
Die Bestimmung von Versiondifferenzen erfolgt entsprechend einem Algorithmus, der über die XML-Struktur der beiden zu vergleichenden Dokumente iteriert. Er macht dabei in der Implementierung vom vorgestellten Prinzip der PIDs
Gebrauch.
Gegeben seien zwei XML-Bäume B1 und B2. B1 repräsentiert die Struktur
der neuen Version eines XML-Dokumenten, B2 die der alten Version.
Besuche alle Knoten von B1
/*Erkenne Einfügungen und Updates*/
Sei x der aktuelle Knoten aus B1
If x hat keinen Partner in B2
Inv.-Nr.: 2005-06-01/071/IN99/2254
58
KAPITEL 3. METADATEN
vermerke Neuer_Knoten(x)
Else sei y Partner von x in B2
Seien a Attribut von x, b Attribut von y
Für alle a
If a hat Partner in b
If Wert(a) != Wert(b)
vermerke Attribut_Änderung(a)
Else
vermerke Attribut_Neu(a)
Für alle b
If b hat keinen Partner in a
vermerke Attribut_Entfernt(b)
Besuche alle Knoten in B2
/*Erkenne Löschungen*/
Sei y aktueller Knoten aus B2
If y hat keinen Partner in B1
vermerke Neuer_Knoten(y)
Quelltext 3.2: Differenzbestimmung zweier XML-Dokumente
Der Algorithmus macht nichts anderes, als zuerst über den XML-Baum des
neuen Dokumentes zu iterieren. Über Vergleiche mit dem alten Dokument lässt
sich erkennen, ob ein Knoten neu hinzugefügt wurden. Falls nicht, können ebenso
alle Unterschiede in den Attributmengen, d.h. Einfügungen, Löschungen oder Änderungen, erkennen. Anschließend liefern ein Durchlaufen des alten Dokumentes
und ein Vergleich mit der neuen Version alle gelöschten Knoten zurück. Somit
werden alle in XMT-SAW Dokumenten möglichen Änderungen erkannt.
Der Algorithmus lässt sich auf unterschiedliche Arten implementieren. Liegt
die Hauptlogik auf der Ebene des Anwendungsprogramms, das auf die Datenbank
zugreift, wird die Iteration über Objekte abgewickelt, welche XML-Elemente der
Dokumente in der Datenbank repräsentieren. Verlagert man die Logik in die Datenbank, kann die Iteration über XQuery Funktionen direkt auf dem Datenbestand
durchgeführt werden. Beide Verfahren weisen unterschiedliche Performance-Charakteristiken auf und eignen sich jeweils für unterschiedliche Verfahren zur Speicherung von Versionsdaten. Dies zeigt sich in Abschnitt 3.5.2.3.
Wie die Änderungen vermerkt werden, ist abhängig von der Methode zur
Speicherung von Versionsdaten. So wird bei Deltas für jede Änderung ein entInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
59
sprechendes Element (siehe 3.5.2.1) erzeugt, das die Änderung aufzeichnet. Beim
Zeitstempelverfahren werden entsprechend Elemente eingefügt, welche die Gültigkeitszeiten der veränderten Elemente anpassen.
3.5.2 Speicherung von Versionsdaten
Nachdem die Möglichkeiten zur Speicherung der Versionsdaten, d.h. der Differenzen zwischen zwei Dokumenten, vorgestellt wurden, geht es jetzt an die Umsetzung für IOSONO. Es werden zwei Verfahren detailliert beschrieben und getestet:
Deltas sowie eine auf τ XQuery basierende Methode. Über diesen Vergleich wird
die geeignetste Methode bestimmt. Gleichzeitig wird so schon die Realisierung
des entsprechenden Versionierungssystems aufgezeigt.
3.5.2.1 Deltas
Das erste untersuchte Verfahren basiert auf der Verwendung von Deltas für die
Speicherung von Versionsdaten.
Prinzip Grundlage der Speicherung ist der Fakt, dass die aktuellste Version eines Dokumentes stets komplett gespeichert ist. Ältere Versionen befinden sich
dagegen nicht komplett in der Datenbank, sondern sind nur in den Änderungen
– d.h. in Form der Deltas – repräsentiert. Die Änderungen sind dabei von der
aktuelleren Version zur älteren bestimmt.
Der Vorteil dieses Vorgehens: die häufigste Anwendung, das Abfragen der aktuellsten Version, kann sehr schnell und ohne großen Aufwand geschehen. Dafür
braucht nur das entsprechende Dokument aus der Datenbank abgefragt werden.
Zur Abfrage älterer Versionen dagegen müssen die Änderungen in umgekehrter
Reihenfolge auf das Ausgangsdokument angewendet werden. Klar ist: der dafür nötige Aufwand nimmt mit zunehmender Distanz zur Vollversion zu. Um einem linearen Anstieg entgegenzuwirken werden daher noch Hauptversionen eingeführt. Dabei handelt es sich um Versionen, die in regelmäßigen Abständen zusätzlich zu den eigentlichen Änderungen als komplettes Dokument gespeichert
werden. Somit kann bei Abfragen weit zurück liegender Versionen auf die nächste Hauptversion zugegriffen werden, um die Änderungen einzubringen.
Die Deltas verzeichnen nun alle Änderungen, die sich zwischen zwei Version
ergeben haben. Sie enthalten eine Reihe von Operationen, mit welchen man von
der neueren zur älteren Version kommen kann. Dabei sind Deltas nicht geordnet,
Inv.-Nr.: 2005-06-01/071/IN99/2254
60
KAPITEL 3. METADATEN
d.h. sie geben keine explizite Ordnung vor. Jedoch ist die Ausführungsreihenfolge
zu beachten. Sollen z.B. Kindelemente vor den zugehörigen Eltern wiederhergestellte werden, kann dies fehlerhafte Ergebnisse verursachen. Daher gilt die Regel,
dass Eltern immer vor Kindern zu bearbeiten sind.
Im entwickelten Algorithmus ist dies erfüllt durch die Bearbeitungsreihenfolge sowohl beim Erkennen von Änderungen als auch beim Rückändern. Änderungen werden in Reihenfolge und Tiefe geordnet gespeichert und in dieser Folge
auch umgekehrt. Im Falle von Löschungen ist das Prinzip umzukehren.
Durch die Speicherung von Änderungen mit dem kompletten Pfad sind auch
Eltern von Änderungen einfach erkennbar.
Details Die Deltas verzeichnen die Unterschiede zwischen zwei Versionen. Dies
geschieht strukturerhaltend. Abgelegt werden sie in einem XML-Dokument, im
Weiteren History genannt. Versionsunterschiede äußern sich in verschiedenen Änderungen, welche mittels zugehöriger XML-Elemente abgelegt werden. Die folgende Auflistung zeigt die entsprechenden Elemente sowie deren Bedeutung:
• changedAttribute: Beschreibt ein verändertes Attribut
• addedAttribute: Hinzugekommenes Attribut
• removedAttribute: Gelöschtes Attribut
• addedNode: Neuer Knoten
• removedNode: Gelöschter Knoten
Alle Knoten, die Änderungen an Attributen betreffen, haben zwei Attribute:
name und value. Während name den Namen des Attributes, das von der Änderung
betroffen ist, erthält, wird value der Wert des Attributes aus der alten Version des
Dokumentes zugewiesen.
Elemente, welche Knoten betreffen, haben keine Attribute. Stattdessen enthalten sie entweder den kompletten XML-Code eines entfernten Knoten, inklusive
aller Kind-Elemente. Oder eben den eines Knotens, so wie er neu in das Dokument aufgenommen wurde.
Um die Änderungen in die Dokumentenstruktur einordnen zu können, werden
die aufgeführten Elemente unter dem Lokalisierungspfad gespeichert, der zu dem
veränderten Knoten oder Attribut führt. Somit kann die History durchlaufen werden und bei jedem Element dessen Lokalisierungspfad benutzt werden, um die
Änderung im Originaldokument zu lokalisieren und einzubringen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
61
Abbildung 3.3: Ausschnitt aus der Struktur eines XMT-SAW Dokuments
Dazu ein kurzes Beispiel, basierend auf einem schemahaft konstruierten XMTSAW Dokument mit einer Struktur wie in Abbildung 3.3. Das Element audio wird
über das Attribut id mit dem Wert 4 identifiziert.
Es wird nun angenommen, dass die Anfangszeit (festgehalten im Attribut begin) dieses Audioobjektes von 20 auf 10 geändert wurde. Der Lokalisierungspfad
zum zugehörigen audio-Element und dem begin-Attribut wäre dementsprechend
/XMT-SAW/body/layer[@id=’layer0’]/audio[@id=’4’]
/@begin
Soll diese Änderung in die History gespeichert werden, ergibt sich eine XMLStruktur wie in Abbildung 3.4 auf der nächsten Seite gezeigt. Klar ist, dass nicht
der aktuelle, sondern der alte Wert des Attributes in die History übernommen wird.
Man sieht, dass die komplette Struktur des Original-Dokumentes bis zum geänderten Element, somit dessen kompletter Lokalisierungspfad, in der Struktur abgebildet ist. Die Änderung selber wird in Form des Elementes changedAttribute
vermerkt. Dieses enthält mit dem Namen und Wert des geänderten Attributes alle
Informationen für die Wiederherstellung der Vorgängerversion.
Gesamtstruktur Die so strukturierten Änderungen müssen nun Informationen
erhalten, um einem Dokument sowie einer Version zugeordnet werden zu können.
Dafür gibt es eine eigene XML-Struktur zur Verwaltung der History. Das
history-Element ist oberster Knoten. Es besitzt für jedes Dokument ein itemInv.-Nr.: 2005-06-01/071/IN99/2254
62
KAPITEL 3. METADATEN
Abbildung 3.4: XML-Struktur der Versionsdaten in Form von Deltas
Unterelement. Dessen Attribut id identifiziert das Dokument, zu welchem die
History-Einträge gehören. Unter diesem Element finden sich für jede Version alle Änderungen in Form der Elemente addedNode, removedNode, addedAttribute,
changedAttribute und removedAttribute, die schon aufgeführt wurden. Aufgeführt
sind diese im values-Element, das die zugehörige Version mittels des versionAttributes angibt.
Daraus ergibt sich eine XML-Struktur, die folgendem Aufbau folgt:
<history>
<item id=’the_document_id’>
<values version=’1’>
<-- path to changed nodes/attributes -->
<changedAttribute
name=’attribute_name’
value=’attribute_value’/>
<addedAttribute name=’...’ value=’...’ />
<removedAttribute name=’...’ value=’...’ />
<addedNode>
<node_name>
...
node content including all subnodes
and attributes
...
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
63
</addedNode>
<removedNode>
...
</removedNode>
</values>
<values version=’...’>
...
</values>
</item>
<item id=’next_document_id’>
...
</item>
</history>
Quelltext 3.3: History-Struktur bei Delta-Versionierung
Diese Struktur kann beliebige Ausmaße und Tiefe annehmen, ist dabei aber
immer mit der eigentlichen Dokumentenstruktur verknüpft.
Bewertung Welches sind die Nachteile dieses Verfahrens? Der gravierendste
Punkt ist der hohe Wiederherstellungsaufwand für ältere Versionen. Für alle Versionen, die aktuellste ausgenommen, müssen Deltas in das aktuelle Dokument
eingebracht werden. Mit zunehmender Anzahl an Versionen, die wiederhergestellt
werden müssen, steigt daher auch der Aufwand.
Um diesen Aufwand einzuschränken, werden Hauptversionen benutzt. Diese gehen jedoch mit steigendem Overhead einher. Somit ist ein Kompromiss zu
finden bzw. die Priorität auf Performance oder Speicherplatz zu legen.
3.5.2.2 Zeitstempel
Beim Zeitstempelverfahren erhalten alle Elemente eines Dokumentes eine Gültigkeitszeit. Im Unterschied zum Verfahren in τ XQuery wird jedoch nicht mit
Zeitwerten gearbeitet. Stattdessen werden Versionen durch ganzzahlige Versionsnummern repräsentiert.
Realisiert wird die Zuweisung von Versionsnummern über die beiden Elemente timestamp und timeVaryingAttribute. Während timestamp der Markierung
von Knoten dient und als Kind-Element zugewiesen wird, werden Attribute mit
timeVaryingAttribute versioniert. Beide Elemente enthalten die Attribute vtBegin
Inv.-Nr.: 2005-06-01/071/IN99/2254
64
KAPITEL 3. METADATEN
und vtEnd zur Markierung von Anfang und Ende der Gültigkeitszeit, angegeben mittels einer Versionsnummer. Letzteres erhält zudem die Attribute name und
value, um Attributname und -wert des versionierten Attributes anzugeben.
Vergabe von Versionsnummern Bei dem Einpflegen eines Dokuments in die
Datenbank wird die Dokumentenstruktur durchlaufen und allen Knoten eine Versionsnummer in Form des timestamp-Elementes zugewiesen. Das zugehörige Attribut vtBegin wird auf den Wert 1 (für die erste Dokumentversion) gesetzt. Die
Attribute des Dokuments werden noch nicht versioniert – um unnötigen Overhead
zu vermeiden, passiert dies erst mit der ersten Änderung an einem Attribut. Dies
erfordert auch, beim Retrieval einer Version zunächst alle Attribute eines Elementes abzufragen, welche diesem zugeordnet sind. Daraufhin werden alle Attribute, welche mittels timeVaryingAttribute versioniert sind, auf Gültigkeit untersucht
und dementsprechend zugewiesen.
Wird ein neuer Knoten erkannt, erhalten dieser sowie alle seine Kindelemente
eine Versionsnummer über einen eigenen timestamp. Für neue Attribute wiederum wird ein timeVaryingAttribute mit Name und Wert des Attributes sowie einer
Anfangsversion entsprechend der neuen Version eingefügt.
Wird ein Knoten gelöscht, erhält das zugehörige timestamp-Element das Ende
der Gültigkeitszeit durch Setzen von vtEnd auf die aktuelle Version. Ebenso wird
vorgegangen bei gelöschten Attributen, welche schon in ein timeVaryingAttributeElement integriert sind. Ist dieses noch nicht vorhanden, wird es angelegt und
mit den benötigten Werten gefüllt, sowie das Attribut aus seinem Elternelement
entfernt. Damit wird vermieden, dass es wegen seines Vorhandenseins im Element
später als gültig erkannt wird.
Das Vorgehen bei geänderten Attributen ist ähnlich: ist noch kein entsprechendes timeVaryingAttribute vorhanden, wird dies angelegt und das Attribut aus dem
Elternelement gelöscht. Andernfalls wird dem aktuellsten timeVaryingAttributeElement ein tvEnd zugewiesen, welches dort noch nicht vorhanden ist. Zudem
wird ein neues timeVaryingAttribute mit aktuellem Attributwert und der aktuellen
Dokumentversion als Anfangszeit zugewiesen.
Das bei den Deltas eingeführte Beispieldokument sähe nach Einbringen in die
Datenbank aus wie in Darstellung 3.5. Wie erläutert hat jeder Knoten ein Unterelement timestamp – in der Abbildung kursiv markiert – erhalten.
Zu beachten ist, dass bestimmte Elemente keiner Versionierung bedürfen. Dies
sind z.B. das oberste Element XMT-SAW oder Knoten wie body und head, welche
in jedem Dokument nur einmal vorkommen und keine eigenen änderbaren Daten
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
65
Abbildung 3.5: Versioniertes XML-Dokument mit Zeitstempeln, Version 1
Abbildung 3.6: XML-Dokument in Version 2
oder Attribute enthalten. Daher bleiben diese unverändert.
Soll nun hier wiederum eine Änderung des Attributes begin von 20 auf 10
vermerkt werden, ändert sich die XML-Struktur wie in der Abbildung 3.6 gezeigt. Das Dokument befindet sich dann in Version zwei. Es ist erkenntlich, dass
zwei timeVaryingAttribute-Elemente hinzugekommen sind. Das erste beschreibt
den Wert des Attributes vtBegin in Version eins, das zweite ab Version zwei.
Versionsabfrage Um eine bestimmte Version zu finden, ist eine XQuery-Anfrage nötig. Darin wird eine Funktion definiert, welche die Selektion aller Elemente ermöglicht, die der geforderten Version entsprechen. Dies sind alle Knoten
Inv.-Nr.: 2005-06-01/071/IN99/2254
66
KAPITEL 3. METADATEN
und Attribute, deren timestamp einen vtBegin-Wert kleiner oder gleich der Versionsnummer haben, sowie einen offenen vtEnd-Wert bzw. einen Wert größer der
Versionsnummer für das Attribut vtEnd.
Bewertung Nachteil bei diesem Verfahren ist der Overhead durch die Zuweisung von timestamp-Elementen für Knoten, welche nie einer Änderung unterzogen waren. Zudem ist auch bei Abfrage der aktuellen Version etwas Verarbeitungsaufwand nötig, da aus dem Pool vorhandener Elemente im Dokument diejenigen ausgewählt werden müssen, welche eine der gefragten Version entsprechende Versionsnummer aufweisen.
Dafür ist die Abfrage von allen Versionen gleich performant. Einbrüche bei
weiter zurück liegenden Versionen gibt es nicht, da alle Anfragen auf einem Dokument ausgeführt werden können.
3.5.2.3 Vergleich von Deltas und Zeitstempeln
Ein Vergleich verschiedener Faktoren soll die bessere der beiden Varianten bestimmen. Festgemacht wird dies an dem Overhead durch die Versionierungsdaten,
die Zeiten für das Abspeichern von Dokumenten in der Datenbank als auch an der
Zeit, die zum Auslesen einer bestimmten Dokumentversion benötigt wird.
Datenaufwand für die Änderungsspeicherung Der Umfang der für die Änderungsspeicherung benötigten Daten zeigt, welcher Overhead sich durch die Versionierung, bezogen auf die eigentlichen Dokumentdaten, ergibt. Es wurden zur
Untersuchung dieser Größe Dokumente in die Datenbank eingepflegt und mit einer Reihe neuer Dokumentversionen versehen. Die Tabelle 3.3 auf der nächsten
Seite zeigt den Overhead von Versionsdaten zur Größe der jeweils aktuellen Dokumentversion.
Zur Verdeutlichung nochmals kurz ein Überblick, wie sich die Versionsdaten
zusammensetzen. Bei Deltas gibt es versionsabhängige Daten erst nach der zweiten Version, da in Version eins das Originaldokument ohne zusätzliche Informationen in der Datenbank gespeichert ist. Der Overhead bleibt damit bei 0%. Ab der
zweiten Version werden alle Änderungen strukturiert gespeichert. Das Dokument
bleibt erhalten, wie es ist. Dazu kommen je nach Änderung die Elemente:
• addedNode mit dem neuen Knoten als Kind
• addedAttribute mit den Attributinformationen
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
Version |
1
2
3
4
5
Delta
Versions- Gesamt- Overdaten
größe
head
[kByte]
[kByte]
[%]
20.5
305.4
6.7
26.3
311.3
8.5
50.0
334.9
14.9
57.8
342.7
16.9
371.3
656.2
56.6
67
Timestamp
Versions- Gesamt- Overdaten
größe
head
[kByte]
[kByte]
[%]
0
289.4
0
32.7
322.1
10.2
65.4
354.8
18.4
370.8
374.6
99.0
681.1
970.5
69.1
Tabelle 3.3: Overhead der Versionierungsverfahren
• removedNode und
• changedNode mit denselben Infos, letzteres zusätzlich mit dem alten Attributwert
• deletedNode mit dem gelöschten Knoten als Kind
Wurden in der aktuellen Dokumentversion viele Knoten eingefügt, ergibt sich
großer Overhead, da diese Elemente in kompletter Struktur sowohl im Dokument als auch in der Versionsstruktur enthalten sind. Dies sind in diesem Moment
redundante Daten. Wird ein Knoten wieder gelöscht, kommt er in Form eines
deletedNode wieder komplett in die Versionierung und ist daher erneut doppelt
gespeichert. So sind diese Daten stets redundant vorhanden.
Beim Zeitstempelverfahren entsteht schon mit der ersten Version Overhead,
da jeder Knoten ein timestamp-Element zugeordnet bekommt. Das Problem der
Redundanz ist geringer als beim Delta-Verfahren. Dies lieg daran, dass neue Knoten im Originaldokument eingefügt werden, aber keine weitere Stelle diese Daten
enthält. Beim Entfernen eines solchen Knotens wird nur dessen Zeitstempel angepasst, die eigentlichen Daten jedoch nicht mehrfach gespeichert.
Somit werden für Änderungen
• timestamp- und
• timeVaryingAttribute-Elemente
eingefügt bzw. deren Gültigkeitszeiten angepasst. Letzteres passiert bei gelöschten Knoten oder Attributen, wo das das vtEnd-Attribut auf die entsprechende Version gesetzt wird. Bei gelöschten Attributen wird dieses zudem aus dem betroffenen Element entfernt.
Inv.-Nr.: 2005-06-01/071/IN99/2254
68
KAPITEL 3. METADATEN
Speicherzeiten Getestet wurde, wie groß der Aufwand für das Einfügen einer
neuen Dokumentversion ist. Dabei wurden unterschiedliche Szenarien untersucht.
Zu einem in der Datenbank befindlichen Dokument wurde eine neue Version hinzugefügt. Zum einen getestet mit zwei relativ großen Dokumenten (300 kByte)
und Änderungen von ca. 30 neuen bzw. entfernten Elementen. Dabei wurden zwei
unterschiedliche Implementierungen untersucht, welche starke Zeitunterschiede
aufweisen. Weiterhin wurde untersucht, wie sich die Systeme verhalten, wenn
viele Änderungen (ca. 230) auftreten, und dabei die beiden Versionen starke Größenunterschiede aufweisen (300 kByte gegenüber 7 kByte). Hier wurde auch getestet, wie sich die Reihenfolge der Größen bemerkbar macht – d.h. die aktuelle
Version in der Datenbank ist kleiner als die neue hinzugefügte Version, sowie in
umgekehrter Form.
Bezüglich der Implementierung des Algorithmus zur Bestimmung der Versionsdifferenzen wurden drei verschiedene Verfahren untersucht:
• Verfahren 1 Mit der ersten gewählten Implementierung ergaben sich sehr
langsame Zeiten für das Zeitstempelverfahren, aber auch das Delta-Verfahren war relativ langsam. Dabei wurden die Iterationen des Algorithmus auf
Objekten des XML-Baumes der Dokumente ausgeführt. Dabei musste für
jedes Element des neuen Dokumentes eine Anfrage an die Datenbank gestellt werden, was einen hohen zeitlichen Aufwand erforderte.
• Verfahren 2 Eine erste Verbesserung konnte erreicht werden, indem diese
Anfragen pro Element beim Durchlaufen der alten Version des Dokumentes
eingespart wurden. Dafür werden beim Durchlaufen des neuen Dokumentes
alle vorhandenen Elemente vermerkt. So kann vergleichend mit der alten
Version festgestellt werden, welche Elemente nicht mehr vorhanden sind
und somit gelöscht wurden.
• Verfahren 3 Nach Änderung der Implementierung auf ein Verfahren, das
nahezu alle Iterationen mittels XQuery-Anfragen und -Funktionen ausführt,
waren starke Verbesserungen der Ergebnisse möglich. Dadurch konnten akzeptable Speicherzeiten für dieses Verfahren ermöglicht werden. Jedoch
muss dafür das verwendete DBMS Funktionen in XQuery unterstützen.
Tabelle 3.4 zeigt die erzielten Speicherzeiten. Die Spalte Verfahren gibt an,
mit welchem Verfahren die Bestimmung der Versionsdaten vonstatten ging. In
der ersten Zeile, welche die schlechtesten Ergebnisse zeigt, ist dies das Verfahren 1. Alle weitern Zeilen zeigen die optimierte Umsetzung, mit Verfahren 2 für
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
Verfahren
1
2/3
2/3
2/3
Dok 1
[kByte]
300
300
300
7
69
Dok 2 Änderungen Delta Zeitstempel
[kByte]
[Anzahl]
[s]
[s]
300
30
35.0
70.0
300
30
18.5
13.0
7
230
1.9
4.3
300
230
0.2
6.4
Tabelle 3.4: Speicherzeiten
Deltas und Verfahren 3 mit Zeitstempeln. Dok 1 und Dok 2 geben die Größe der
beteiligten Dokumente an, wobei Dok 1 die aktuelle Version darstellt, und Dok 2
die neu eingefügte. Änderungen enthält die Anzahl an neuen/gelöschten Knoten
sowie Attributänderungen. Es sind durch die Verwendung von XQuery gute Ergebnisse erzielbar. Es zeigt sich dabei auch, dass die Zeiten für das Einpflegen
einer neuen Version stark von der Größe der zu vergleichenden Dokumente, als
auch von der Anzahl der veränderten Elemente abhängen. Die Größe macht sich
beim Aufwand des Durchlaufens der Dokumentstruktur bemerkbar, sowohl bei
Deltas als auch bei Zeitstempeln. Letztendlich zeigen letztere die bessere Performance. Die Anzahl der zu vermerkenden Änderungen spiegeln sich dagegen bei
den Zeitstempeln stärker in einer längeren Verarbeitungszeit wieder. Der Grund
liegt darin, dass hier für jede Änderung an einer beliebigen Stelle innerhalb eines
Dokumente Knoten und Attribute eingefügt werden müssen, was relativ aufwendig ist. Speziell im Vergleich zu den Deltas, wo alle Versionierungsdaten in einer
einzigen XML-Struktur gespeichert werden und diese in einem Änderungsvorgang in die Datenbank eingebracht werden kann.
Retrievalzeiten Die Retrievalzeiten geben an, wie lange das Auslesen eines Dokumentes in einer gegebenen Version aus der Datenbank andauert. Dies wurde
mittels in der Datenbank befindlichen Dokumenten in diversen Versionen untersucht. Beim Delta-Verfahren wurde ohne Hauptversionen operiert, da das Auslesen von Hauptversionen dem von Version eins entspricht, da keine Änderungen
eingebracht werden müssen. Alle sechs untersuchten Versionen sind dem Versionierungsverfahren entsprechend gespeichert – die Deltas über eine eigene XMLStruktur, Zeitstempel mittels zugehöriger Elemente im Dokument.
Wie schon in den theoretischen Betrachtungen angesprochen sind die Auslesezeiten (Abbildung 3.7 auf der nächsten Seite) beim Zeitstempelverfahren versionsunabhängig. Die Deltas dagegen hängen stark von der Anzahl der umzukehInv.-Nr.: 2005-06-01/071/IN99/2254
70
KAPITEL 3. METADATEN
Abbildung 3.7: Retrieval mittels Zeitstempeln und Deltas
renden Änderungen ab. Der Aufwand dafür steigt linear im Verhältnis der einzubringenden Änderungen an. Mit Zeitstempeln sind immer die geringsten Zeiten
zu erwarten.
3.5.2.4 Evaluierung
Nach dem Vergleich der in den Untersuchungen erzielten Ergebnisse fällt die Entscheidung zwischen Delta- und Zeitstempel-Verfahren zugunsten der Zeistempelbasierten Lösung. Primärer Entscheidungspunkt sind die konstant sehr kurzen
Auslesezeiten für beliebige Dokumentversionen. Auch die Zeiten zum Einbringen neuer Versionen in die Datenbank sind als ausreichend anzusehen, wenn auch
bei bestimmten Konfigurationen relevante Abstände zum Delta-basierten Prinzip
auftreten. Im strukturellen Bereich dagegen überzeugen die Zeitstempel mit einer klaren Struktur innerhalb des Originaldokumentes; eine externe Verwaltungsstruktur wie von Deltas benötigt ist überflüssig. Dies erleichtert auch den Umgang
mit der Ähnlichkeitssuche, wo der Platz eines XML-Elementes in der Datenbank
eine Rolle spielt. Dieser bleibt bei Zeitstempeln unverändert – bei Deltas dagegen wandern Elemente in die Änderungsstruktur, ausgehend vom zuletzt aktuellen
Versionsstand. Auch ist im Sinne des Overheads der Zeitstempel das optimalere
Verfahren, da er hilft, Speicherplatz zu sparen.
Jedoch ist zu bedenken, dass eine rasche Ausführung des Zeitstempelverfahrens die Definition eigener Funktionen in XQuery seitens des Datenbanksystems
verlangt. Dies stellt noch keine Selbstverständlichkeit dar.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
71
3.5.3 Implementierung
Kernpunkt der Implementierung des Versionierungssystems sind die Funktionen
insertDoc und storeDoc, beide von XMTSAWDbHandler implementiert. Sie werden aufgerufen, wenn der Nutzer in der Dialog-Eingabe entsprechend auf „Dokument einfügen“ oder „Version hinzufügen“ klickt, oder beim Speichern von
Szenenbeschreibungen über Spamix. Die Funktion insertDoc fügt ein neues Dokument in die Datenbank ein, während storeDoc eine neue Version eines Dokumentes speichert. Beide Funktionen nutzen die Funktionalität des Versionierungssytems, das basierend auf τ XQuery implementiert ist.
Neues Dokument Wird ein neues Dokument über insertDoc eingefügt, werden
zu Beginn alle Elemente des Dokumentes mit einem Zeitstempel versehen. Dafür wird das Dokument in seiner ganzen Hierarchie durchlaufen. Dies geschieht
auf dessen XML-Struktur über Xerces-spezifische Objekte, welche das XMLDokument repräsentieren. Zugleich muss sichergestellt werden, dass alle Elemente ihren PID haben. Im Zuge des Iterierens über alle Dokumentelemente kann dieser, wo benötigt, einfach eingefügt werden. Der PID ergibt sich aus einer Kombination von Elementname und aktueller Systemzeit. Anschließend wird das Dokument inklusive Zeitstempeln in die Datenbank eingefügt und die docs-Struktur
(vorgestellt in 3.4.2) um einen neuen Eintrag erweitert.
Neue Version Mittels der Funktion storeDoc wird eine neue Version in die Datenbank eingefügt. Dafür werden, wie in 3.5.1.3 erläutert, die Unterschiede zwischen alter und neuer Version des Dokumentes bestimmt. Die Bestimmung der
Differenzen geschieht hier über mehrere Funktionen, die in XQuery formuliert
und ausgeführt werden. Dargestellt sind diese Funktionen in Anhang A.2. Sie ermöglichen – da direkt vom Datenbanksystem auf dem Datenbestand ausgeführt –
die schnellste Ausführung der Differenzbestimmung.
Zum Abschluss werden diese Änderungen inklusive Zeitstempel in das neue
Dokument übertragen. Für geänderte oder gelöschte Elemente werden zudem die
Zeitstempel des Dokumentes in der Datenbank angepasst. Das dem Dokument
entsprechende doc-Element in der Verwaltungsstruktur (3.4.2) wird anschließend
um einen neuen Kommentar ergänzt und die Versionsnummer angepasst.
Inv.-Nr.: 2005-06-01/071/IN99/2254
72
KAPITEL 3. METADATEN
3.6 Suche über Metadaten
Es gilt, die Suche innerhalb der XMT-SAW Dokumente auf die Strukturen und
Techniken, welche von BDB XML angeboten werden, umzusetzen. Nach einer
Vorstellung der typischen Suchvorgänge werden speziell für die Ähnlichkeitssuche einige Techniken aufgelistet und die umgesetzte Implementierung erläutert.
3.6.1 Was soll gesucht werden?
Die Suche soll es ermöglichen, innerhalb von Szenenbeschreibungen Teile derselben auf Grundlage von Attributen und Attributwerten aufzufinden. Alle Suchfunktionen beschränken sich auf die Suche anhand von Attributwerten. Eine Volltextsuche über Textknoten wird nicht umgesetzt – im XMT-SAW Format sind solche
nicht vorhanden.
So läuft alles darauf hinaus, über einem gegebenen Attributwert und zusätzlichen Infos wie den Attributnamen oder die Beschränkung auf Elemente mit bestimmten Namen, ein oder mehrere Element(e) aus einem XML-Dokument zu
erhalten.
Die Anforderung „Suche“ lässt sich in drei Teilbereiche untergliedern. Erster
ist die Suche nach ganzen Zeichenketten. Weitere Anforderung ist die Suche anhand von gegebenen Teilwörtern. Sind so z.B. verschiedene Quellen einem Fahrzeug zugeordnet und haben den Namen „Fahrzeug_1“ und „Fahrzeug_2“, ist ein
Auffinden aller Vorkommen über eine gegebene feste Zeichenkette wie „Fahrzeug_1“ nicht möglich. Gibt man jedoch das Teilwort „Fahrzeug“ als Suchbegriff
an, können alle zu einem Fahrzeug gehörenden Quellen gefunden werden. Dritter Teilbereich ist die fehlertolerante Suche. Dies kann Tippfehler bei der Dateneingabe in Suchvorgängen ausgleichen, aber auch Werte ähnlich dem gegebenen
Suchwort selektieren.
Im Folgenden wird auf die einzelnen Bereiche näher eingegangen. Vorher werden kurz typische, zu erwartende Anfragen erläutert.
3.6.2 Typische Anfragen
Eine einfache typische Anfrage wird z.B. ein audio-Element anhand seines Attributes id suchen. Dies entspricht dem Fall, dass man ein Element mittels seines
Namens wieder finden möchte.
Auch möglich ist die Suche nach dem Attribut src eines Audioobjektes, das
auf die referenzierten Audiodaten verweist. Muss dieser Verweis geändert werInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
73
den, kann anhand des bisherigen Namens der Quelle das zugehörige virtuelle
Audioobjekt innerhalb der Szene gesucht werden. Hierbei kann die Suche nach
Teilzeichenketten helfen, da das src-Attribut die Form
<Kanalnummer>:<Quellenname>
hat. Eine Suche sollte hier anhand des gegebenen Quellennames zum Erfolg führen. Dies ist über die Suche nach Teilwörtern oder eine Ähnlichkeitssuche realisierbar.
Die erfolgreiche Ausführung solcher Suchanforderung ist mittels verschiedener Mittel realisierbar. Diese werden in den folgenden Abschnitten vorgestellt.
3.6.3 Suche nach ganzen Wörtern und Teilwörtern
Die Suche nach vollständigen Wörtern und auch Teilwörtern ist über die von BDB
XML zur Verfügung gestellten Mittel realisierbar. XPath erlaubt die Selektion von
XML-Elementen anhand von Attributwerten. So kann das Suchwort als Attribut
in einem XPath-Ausdruck zur Selektion der geforderten XML-Elemente dienen.
Die Syntax zur Auswahl anhand eines Attributwertes ist hierbei
.../[@attributname=’wert’]
Ebenso können Elemente mittels eines gegebenen Teilstrings in einer XPathAnfrage selektiert werden. Dafür wird die XPath-Funktion contains verwendet,
mit welcher ein Teilausdruck der Form
.../[contains(@attributname, ’wert’)]
entsteht.
Die Nutzung von Anfrageausdrücken als Bestandteil des Datenbanksystems
für die Suchaufgaben bedeutet, dass keinerlei zusätzliche Informationen gespeichert werden müssen, um eine Suche durchführen zu können. Somit steht auch
jedes Element eines neu in die Datenbank aufgenommenen Dokumentes sofort
der Suche zur Verfügung.
3.6.4 Fehlertolerante Suche und Ähnlichkeitssuche
Die fehlertolerante Suche erlaubt sinnvolle Ergebnisse auch dann, wenn sich in
den zu vergleichenden Wörtern Buchstaben unterscheiden oder sich Tippfehler
eingeschlichen haben.
Inv.-Nr.: 2005-06-01/071/IN99/2254
74
KAPITEL 3. METADATEN
Zur Umsetzung fehlertoleranter Suche können Zeichenketten-Abstandsmaße
verwendet werden. Beim einfachen zeichenbasierten Vergleich von Zeichenketten wird jedes einzelne Zeichen verglichen. Bei nur einer Unterscheidung werden
sie als ungleich eingestuft. Es müssen alle Zeichen an den jeweiligen Positionen
übereinstimmen, um Gleichheit zu erreichen. Tests auf Ähnlichkeit sind mit solchen Methoden kaum möglich. Daher sind Abstandsmaße ein gutes Mittel für die
Ähnlichkeitssuche.
3.6.4.1 Abstandsmaße
Um tolerante Vergleiche durchzuführen, benutzt man ein Maß, das Abstand oder
Übereinstimmung zweier Zeichenketten durch eine Zahl ausdrückt. Die Größe der
Zahl gibt das Maß der Übereinstimmung wieder. Um eine solche Zahl zu erhalten
gibt es verschiedene Ansätze. Drei davon – Editierabstand, Hamming-Distanz und
N-Gramme – werden hier kurz erläutert.
Editierabstand (Levenshtein-Abstand) Dieser ist beschrieben als die kleinste Menge elementarer Operationen, mit denen eine Zeichenkette in eine andere
Zeichenkette überführt werden kann. Zu diesen Operationen können gehören:
• Zeichen einfügen
• Zeichen löschen
• Zeichen ersetzen
• (Zeichen vertauschen)
Der Editierabstand kann als Erweiterung der Hamming-Distanz gesehen werden,
welche sich auf die Ersetzung von Buchstaben beschränkt.
Hamming-Distanz Dieses Maß ermittelt die Anzahl an Positionen, in denen
der Inhalt von zwei Zeichenketten voneinander abweicht. Bei Zeichenketten unterschiedlicher Länge wird die kürzere mit Dummy-Zeichen aufgefüllt, die als
nicht übereinstimmend gewertet werden. Sollen die Wörter Audioserver und Audiowiedergabe verglichen werden, ist somit das kürzere Wort (hier: Audioserver)
mit Dummy-Zeichen aufzufüllen, was zu dem Ergebnis „Audioserver$$$$“ führt.
Der Vergleich mit Audiowiedergabe führt schließlich zu einer Abweichung an
acht Stellen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
75
N-Gramme Ein N-Gramm ist eine Folge benachbarter Elemente. N ist dabei
die Länge der verwendeten Folge. Man vergleicht das gemeinsame Auftauchen
von Substrings. Je kleiner N, desto toleranter ist das Verfahren. Ist N größer oder
gleich dem Maximum der Länge der Strings, wird nur 1 oder 0 zurückgeliefert, je
nachdem ob die Strings identisch sind oder nicht.
Die Berechnung für N-Gramme geschieht wie folgt: Seien Na und Nb alle
N-Gramme, die in der jeweiligen Zeichenkette a und b vorkommen. Dann gilt für
den Abstand der beiden Zeichenketten die Formel:
dN −Gramm = 1 − 2
#(Na ∩ Nb )
#Na + #Nb
3.6.4.2 Eignung
Jedes dieser Verfahren hat eine andere Eignung für unterschiedliche Anwendungen vorzuweisen.
Editierabstand Zeicheneinfügungen, -löschungen und -änderungen werden als
kleine Änderungen erkannt. Jedoch wird bei Verschiebungen die Verschiebungsdistanz nicht registriert. Die Folge: weiträumige Umstellungen einzelner Buchstaben bleiben ohne entsprechende Änderung des Ähnlichkeitswertes.
Hamming-Distanz Dieses Verfahren ist wenig tolerant. Ist in der Zeichenkette
sehr weit vorn ein abweichendes Zeichen eingefügt, bricht die Korrespondenz ab.
N-Gramme N-Gramme bieten ein gutes Maß bei Zeichenketten, die als sehr
ähnlich empfunden werden. Es ist toleranter als die Hamming-Distanz, da es nicht
auf den absoluten Positionen der Zeichen in der Zeichenkette beruht. Jedoch gibt
es starke Reaktionen bei Buchstabendrehern, d.h. zum Ausgleichen von Tippfehlern sind N-Gramme weniger geeignet. Zudem ergibt sich bei kurzen N-Grammen
eine sehr hohe Toleranz.
Fazit Nach Bewertung der Eigenschaften fällt die Wahl auf eine Kombination
aus N-Grammen und Editierabstand. Die Hamming-Distanz, mit geringer Toleranz, wird nicht berücksichtigt. Stattdessen wird die Suche über N-Gramme begonnen. Nachdem daraus Ergebnisse erzielt wurden, wird letztendlich noch eine
Inv.-Nr.: 2005-06-01/071/IN99/2254
76
KAPITEL 3. METADATEN
Berechnung des Editierabstandes durchgeführt. Dadurch können Wörter ausgeschlossen werden, die viele N-Gramme teilen, jedoch grundverschieden sind. Somit kann auch das Problem der zu hohen Toleranz bei kurzen N-Grammen eingeschränkt werden. Zudem wird auf 3-Gramme (auch: Tri-Gramme) vertraut. Diese
sind nicht zu tolerant, wie dies u. U. bei 2-Grammen der Fall ist, und bieten somit
einen guten Kompromiss zwischen Toleranz und Ähnlichkeitsstrenge.
Für das weitere Verständnis hier noch ein kurzes Beispiel dafür, wie solche
N-Gramme letztendlich aussehen. Dazu werden 3-Gramme für eine Zeichenkette
erstellt. Dafür wird diese Zeichenkette in eine Sequenz von Zeichenketten der
Länge 3 unterteilt. Für das Wort „Motion“ ergibt sich die Sequenz wie folgt:
{##M, #Mo, Mot, oti, tio, ion, on$, n$$}. Wie zu sehen, wird ein N-Gramm
schon mit dem ersten Buchstaben eines Wortes gebildet. Für offene Stellen werden Platzhalter eingefügt – hier sind dies ’#’ am Anfang eines Wortes und ’$’ am
Ende.
3.6.4.3 Algorithmus
Der für die Suche umgesetzte Algorithmus ist an Gravano et al. [15] angelehnt
und auf das Berkeley Datenbanksystem angepasst. Die N-Gramme werden als positionsabhängige N-Gramme gespeichert. Das bedeutet: jedes N-Gramm wird mit
der zugehörigen Position innerhalb der Zeichenkette gesichert. So wird der Fall
ausgeschlossen, dass zwei Zeichenketten viele N-Gramme teilen, die sich jedoch
an komplett unterschiedlichen Positionen befinden und damit die Zeichenketten
eigentlich wenig Ähnlichkeit aufweisen.
Der Algorithmus enthält 3 Filterkriterien. Diese basieren auf der Verwendung des Editierabstands als zusätzliches Vergleichskriterium. Die Kriterien sind
dementsprechend:
Anzahl-Filter Grundlage dieses Filters ist der Umstand, dass Strings mit geringem Editierabstand viele gemeinsame positionsunabhängige N-Gramme haben. In einem Zusammenhang ausgedrückt, heißt dies: Seien s1 und s2 zwei
Zeichenketten mit Länge |s1 | und |s2 |. Wenn s1 und s2 in Editdistanz k sind,
dann muss die Kardinalität der N-Gramm-Mengen G(s 1 ) und G(s2 ) mindestens
max(|s1 |, |s2|) − 1 − (k − 1) ∗ q sein.
Positionsfilter Sind s1 und s2 in Editierabstand k, dann kann ein positionales
N-Gramm in einer Zeichenkette nicht zu einem anderen korrespondieren, wenn
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
77
mehr als k Positionen Distanz sind.
Längenfilter Sind s1 und s2 in Edit-Distanz k, können sich die Längen der Zeichenketten um nicht mehr als k unterscheiden.
Der in das Verwaltungssystem integrierte Algorithmus, welcher diese Kriterien vereint, sieht aus wie folgt:
array<qgram_s> found;
foreach qgram_s in string //N-Gramme der Zeichenkette
{
foreach qgram_db_s in db //N-Gramme der ZK aus DB
{
if( qgram_s.qgram == qgram_db_s.qgram &&
// Positionsfilter
abs( qgram_s.pos - qgram_db_s.pos) <= k &&
// Längenfilter
abs( qgram_s.string.length qgram_db_s.string.length) <= k &&
// Editierabstand
edit_distance( qgram_s.string,
qgram_db_s.string) <= k )
{
if( found.contains(qgram_db_s )
found[qgram_db_s].count ++;
else
found.add(qgram_db_s);
}
}
}
// Test des Anzahl-Filters
for each qgram_s in found
{
if( qgram_s.count < min_count )
{
found.remove(qgram_s);
Inv.-Nr.: 2005-06-01/071/IN99/2254
78
KAPITEL 3. METADATEN
}
}
handle_results(found);
Quelltext 3.4: Algorithmus der Ähnlichkeitssuche
Der Ablauf: alle N-Gramme (stehen in der Struktur qgram_s) der gegebenen
Suchzeichenkette werden mit den N-Grammen in der Datenbank (entsprechende
Struktur: qgram_s_db) verglichen. Bei Übereinstimmung kommt die Anwendung
der Filter zum Einsatz. Es wird die Position der N-Gramme überprüft, ebenso wie
die Länge und Edit-Distanz ihrer Zeichenketten.
Als Resultat der Abarbeitung des Algorithmus befinden sich im Feld found
alle N-Gramm-Strukturen (qram_s), welche die Filterung positiv überstanden haben und somit die Zeichenketten enthalten, die genügend Ähnlichkeit zur gegebenen Zeichenkette aufweisen. Eine solche N-Gramm-Struktur (qgram_s) enthält
die Felder:
• qgram das N-Gramm
• string die Zeichenkette zu der das N-Gramm gehört
• pos die Position des QGrams innerhalb der Zeichenkette
Durch die Anwendung der Filter werden alle relevanten Strukturen im Array
found zusammengefasst und können so zur Weiterbearbeitung übergeben werden.
3.6.4.4 Speicherstrukturen
Zur Verwaltung der fehlertoleranten Suche müssen bestimmte Daten gespeichert
werden: die vergleichbaren Zeichenketten müssen für die Suche indiziert sowie
mit einer Information versehen werden, in welchem XMT-SAW Dokument sie an
welcher Position zu finden sind. Dies führt zu einer Datenstruktur, welche zu allen
durchsuchbaren Zeichenketten folgendes speichert:
• Alle zugehörigen N-Gramme mit der jeweiligen Position innerhalb der Zeichenkette. Dies sind die positionsabhängigen N-Gramme, benötigt für die
vorgestellte Vorgehensweise zur Ähnlichkeitsbestimmung.
• Eine Form der Lokalisierung der verglichenen Zeichenketten innerhalb der
XMT-SAW Dokumente der XML Datenbank. Dafür eignet sich ein Lokalisierungspfad, wie er in XPath-Ausdrücken verwendet wird. Somit lässt sich
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
79
das XML-Element eines Dokumentes, zu welchem die Zeichenkette gehört,
einfach mittels einer XPath-Anfrage wieder finden.
Damit ergibt sich eine Speicherlayout wie folgt: für den Vergleich von Zeichenketten müssen deren N-Gramme positionsabhängig untersucht werden. Daher ergibt sich der Schlüssel, d.h. die Grundlage für den Datenzugriff, aus einer
Kombination von N-Gramm und dessen Position. Als Daten werden diesem Referenzen auf
• die eigentliche Zeichenkette
• Lokalisierungspfad und
• Attribut
zugeordnet.
Warum nur Referenzen? Es ist klar, dass für eine Zeichenkette mehrere Einträge in der Tabelle nötig sind, einer für jedes N-Gramm. Würden alle zugeordneten
Werte wie Lokalisierungspfad oder Attribut für jeden Eintrag komplett gespeichert, würde dies das Datenaufkommen stark erhöhen und unnötige Redundanz
verursachen. Durch die Speicherung dieser Daten in jeweils einer eigenen Tabelle, unter einer eindeutigen Id, kann dies stark vermindert werden. Es werden nur
Ids in der N-Gramm-Tabelle zugeordnet.
Die Zeichenkette wird dabei für den Vergleich von Zeichenkettenlänge sowie
den Editierabstand benötigt. Der Lokalisierungspfad, zusammen mit dem Attributnamen, wird schließlich zum Rückliefern des eigentlichen XML-Elementes
gebraucht.
Die Speicherung dieser Daten benötigt keine logische Struktur, wie sie z.B.
von XML zur Verfügung gestellt wird. Daher wird für die Ausführung von Suchfunktionen die Datenablage der Zeichenketten nicht in einer XML-Datenbank vorgenommen. Stattdessen werden Standard-Datenbanken von Berkeley DB genutzt.
Da Berkeley DB Basis von BDB XML ist, ist es automatisch auf einem System
verfügbar und nutzbar, auf dem BDB XML installiert ist. Somit ist keine zusätzlichen Installation oder Konfiguration erforderlich. Auch kann davon ausgegangen
werden, dass der Zugriff über Funktionen auf BDB-Daten schneller vonstatten
geht als über Selektionen auf XML-Datenbanken.
Daher werden verschieden Datenbanken (Tabellen) angelegt, welche oben aufgezählte Daten enthalten. Es entstehen jeweils Tabellen für:
• N-Gramme (Haupttabelle) mit den Attributen
Inv.-Nr.: 2005-06-01/071/IN99/2254
80
KAPITEL 3. METADATEN
– N-Gramm
– Position des N-Gramms
– Zeichenketten-Identifier der zugehörigen Zeichenkette
– Lokalisierungspfad-Identifier des Pfades zum N-Gramm-String
– Attribut-Identifier für das N-Gramm-Attribut
• Attribute
– Attribut-Identifier
– Attribut
• Zeichenketten
– Zeichenketten-Identifier
– Zeichenkette
• Lokalisierungspfade
– Pfad-Identifier
– Pfad
Die einzelnen Tabellen sind über die entsprechenden Identifier miteinander
verbunden.
Ein Beispiel verdeutliche die für die Speicherung benötigten Einträge. Das
Attribut src des Elementes audio habe Wert 4:Steps. Diese Information soll für
die Suche indiziert werden. Die entsprechende Referenz ist dann
doc{container.bdbxml/doc}/XMT-SAW
/layer[@id="’layer0"’]/audio[@id="’4]
und wird so in die Referenzen-Tabelle eingetragen. Die Attribut-Tabelle erhält
einen Eintrag src für das zugehörige Attribut. In die Haupttabelle werden neun
Einträge eingefügt – entsprechend neun N-Grammen für das Wort 4:Steps –, jeweils bestehend aus N-Gramm sowie Verweis auf String-, Attribut- und Referenztabelle. Die Grafik 3.8 stellt die entstehenden Beziehungen und Einträge der
einzelnen Tabellen in illustrierter Form dar.
Wird ein Dokument aus der Verwaltung gelöscht, ist es erforderlich, alle enthaltenen und für die Suche indizierten Zeichenketten aus den N-Gramm-spezifischen Tabellen zu entfernen. Dazu gehören auch nicht mehr benötigte Lokalisierungspfade, Zeichenketten und Attribute aus den zugehörigen Tabellen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
81
Abbildung 3.8: Tabellenlayout der N-Gramme
3.6.4.5 Zeitaufwand
Für die Suche müssen alle relevanten Wörter innerhalb eines Dokumentes indiziert werden. Speziell dieser Vorgang nimmt entsprechend der Dokumentgröße,
respektive der Anzahl zu indizierender Wörter, lange Zeit in Anspruch. Dies wird
durch den Umstand erschwert, dass XMT-SAW Dokumente über viele Attribute
verfügen, welche indiziert werden müssen. Zudem nimmt der Aufwand für das
Einpflegen der Daten in die Datenbank mit zunehmender Größe der Datenbankdateien stetig zu. So verlangt die Indizierung eines Dokumentes von 10 kByte
mit leerer Datenbank noch 0,03 Sekunden, bei einer Größe der Datei für die
N-Gramme von ca. 800 kByte jedoch schon 2,5 Sekunden. Ein 300 kByte großes
Dokument benötigt dann schon 50 Sekunden zur Indizierung. Und hat die Datenbankdatei eine Größe von 5 MByte angenommen, dauert derselbe Vorgang ganze
3 Minuten. Unter Berücksichtigung dieser Zeiten gilt es zu prüfen, ob eine Beschränkung der indizierten Attribute auf eine Teilmenge derselben vorgenommen
wird.
3.6.5 Evaluierung
Die fehlertolerante Suche mittels N-Grammen lässt sich auf dem Datenmodell
von Berkeley DB gut umsetzen. Eine zuverlässige und schnelle Suche über alle
Dokumentinhalte ist möglich. Einziges Problem stellt der Zeitaufwand für die
Inv.-Nr.: 2005-06-01/071/IN99/2254
82
KAPITEL 3. METADATEN
Abbildung 3.9: Oberfläche des Suchdialogs
Indizierung der Dokumente dar, welcher schnell hohe Werte annehmen kann.
Um dies nicht im Produktionsprozess als unerwünschte Begleiterscheinung
zu haben, wird die Indizierung von Dokumenten vom Einpflegen derselben in
die Datenbank abgekoppelt. Stattdessen wird eine eigene Funktion implementiert,
bei deren Aufruf die gewünschten Dokumente für die Suche indiziert werden.
So kann die zeitaufwändige Indizierung dann durchgeführt werden, wenn keine
zeitkritischen Aufgaben anstehen.
Um den Zeitaufwand entscheidend einzuschränken, bleibt jedoch nur eine
sinnvolle Lösung: anstatt alle Attribute eines Elementes für die Suche zu indizieren, wird dies nur mit einer Teilmenge durchgeführt. Attribute, die voraussichtlich nie eine Rolle in der Suche spielen werden, verbrauchen unnötig Speicherplatz und verlangsamen die Indizierung merklich. Wird die Menge der relevanten
Attribute auf wenige Vertreter eingeschränkt, bringt dies merkliche Geschwindigkeitsvorteile.
3.6.6 Implementierung
Zur Verwaltung aller Suchfunktionen wurde die Klasse DbSearch implementiert.
Für alle benötigten Aufgaben gibt es entsprechende Funktionen. Sie sind über den
in Abbildung 3.9 dargestellten Dialog abrufbar. Dieser erlaubt die Eingabe der
Suchkriterien sowie weitere Möglichkeiten, Details zum Suchvorgang anzugeben.
Basis ist ein Eingabefeld zur Eingabe des Wortes, welches das Suchkriterium darstellt. Die weiteren zu tätigenden Angaben entscheiden danach, ob eine
Ähnlichkeitssuche durchgeführt werden soll. Dies kann über ein AuswahlkästInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
83
chen definiert werden. Wurde es markiert, und damit eine Ähnlichkeitssuche aktiviert, kann der Suchvorgang gestartet werden. Es werden alle Vorkommen in der
Datenbank aufgezeigt, welche dem gegebenen Suchwort ähneln.
Bei einer Standardsuche lassen sich weitere Faktoren festlegen. So ist es möglich, den Namen des der Suche zugrunde liegenden Attributes festzulegen, ebenso
wie den Namen der Elemente, welche in die Suche einbezogen werden dürfen.
Ergebnis jedes Suchvorgangs ist eine Ausgabe, welche die gefundenen Elemente präsentiert. Nun ist es möglich, eines der Elemente auszuwählen und sofort
nach Spamix zu exportieren. Dort kann es in die gegenwärtig bearbeitete Szene
eingefügt werden. So lassen sich schon in früheren Beschreibungen erstellte Audioobjekte, inklusive aller Eigenschaften, einfach in eine neu zu erstellende Szene
übernehmen.
3.6.6.1 Dokument indizieren
Die Funktion storeQGrams speichert alle Informationen zu einer Zeichenkette,
welche für die Suche indiziert wird. Die Zeichenkette wird zusammen mit dem
zugehörigen Attributnamen, dem Elementnamen und dem Lokalisierungspfad als
Parameter an die Funktion übergeben. Aufgerufen wird diese Funktion im Normalfall beim Einpflegen eines neuen Dokumentes oder einer neuen Dokumentversion in die Datenbank, wenn die enthaltenen Attribute indiziert werden müssen.
Beim Speichern der Suchdaten werden zuerst die zuletzt genannten Daten in
die entsprechenden Tabellen gespeichert. Sollten die Elemente dort schon vorhanden sein, wird nur der Schlüssel zurückgeliefert, andernfalls ein neuer erstellt. Die
Funktion verfügt nun über Zeichenketten-Id, Pfad-Id und Attribut-Id.
Anschließend werden die N-Gramme entsprechend folgender Funktion bestimmt:
void getQGrams()
{
string temp;
int tempLength;
for( int i = -QGRAM_LENGTH + 1; i < 0; i++ )
{
temp = "";
for( int j = 0 ; j < -i; j++ )
Inv.-Nr.: 2005-06-01/071/IN99/2254
84
KAPITEL 3. METADATEN
temp += "#";
temp += value.substr(0, QGRAM_LENGTH - (-i));
qgrams.push_back(temp);
}
for( unsigned int i = 0; i < value.length(); i++ )
{
temp = value.substr(i, QGRAM_LENGTH);
tempLength = temp.length();
for( int j = 0; j < QGRAM_LENGTH-tempLength; j++)
temp += "$";
qgrams.push_back(temp);
}
}
Quelltext 3.5: Bestimmung von QGrams
Die im Array qgrams enthaltenen N-Gramme werden anschließend mit ihrer
Position und den vorher bestimmten Ids in die N-Gramme-Tabelle abgelegt.
3.6.6.2 Dokument-spezifische Indizierung entfernen
Um alle N-Gramme zu einem bestimmten Dokument zu entfernen, wird die Funktion removeQGrams bereitgestellt. Anhand einer übergebenen Dokument-Id können alle zu diesem Dokument indizierten Zeichenketten wieder aus der Datenbank
entfernt werden.
3.6.6.3 Elemente finden
Mittels findNode wird Voll- und Teilwortsuche realisiert, während findString die
N-Gramm-Suche umsetzt.
findNode setzt dies über XPath-Funktionen um, wie in 3.6.3 vorgestellt. Diese
Anfragen werden an den aktuellen Datenbestand in der Datenbank gestellt und
liefern alle XML-Elemente zurück, welche die Kriterien erfüllen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
85
Um die Ähnlichkeitssuche mittels N-Grammen durchzuführen, wird der Algorithmus wie in 3.6.4.3 gezeigt in C++ umgesetzt. Damit werden alle XMLElemente, welche ein Attribut mit einem Wert ähnlich dem Suchwort enthalten,
zurückgegeben.
3.7 Offene Themen
Dieser Abschnitt widmet sich den Anforderungen, welche nicht im Rahmen dieser
Diplomarbeit gelöst wurden.
3.7.1 Mehrbenutzerunterstützung
Mehrbenutzerunterstützung ist im Moment noch nicht in Spamix integriert. Dies
impliziert die Einschränkung, dass stets nur ein Benutzer an einer Szene arbeiten
kann. Das gleichzeitige Bearbeiten einer Szene durch mehrere Benutzer wird nicht
unterstützt. Gerade jedoch bei umfangreichen Szenen kann es erforderlich sein,
dass mehrere Beteiligte am Produktionsprozess einer Szene mitwirken.
Zur Realisierung der Mehrbenutzerunterstützung wird auf ein Client-ServerModell zurückgegriffen. Eine zentrale Instanz (Server) regelt für alle Zugriffe auf
das Datenbanksystem. Es existieren keine weiteren Prozesse, welche Datenbankzugriff erhalten. Somit kann die Koordination der Zugriffe, inklusive Sperren,
Konsistenzkontrolle etc., zentral durchgeführt werden.
Zur Arbeit mit dem Datenbestand erhält jeder Arbeitsplatz einen Client, welcher sich an der zentralen Instanz anmeldet. Möchte er eine Szene bearbeiten,
stellt er eine entsprechende Anfrage an den Server und bekommt die angeforderten Daten zugesandt. Tätigt ein Client eine Änderung, wird dies dem Server
mitgeteilt.
Wie viele Clients gleichzeitig dieselben Daten verändern dürfen liegt im Ermessen der zugestandenen Parallelität. Hier stehen optimistische und pessimistische Verfahren in der Realisierung zur Verfügung. Pessimistische Verfahren ermöglichen die Bearbeitung von Daten oder Teilen der Daten nur einem Benutzer
und sperren diese Daten für weitere Zugriffe bis zum Ende der Bearbeitung. Dies
führt zu praktisch keiner Parallelität, da weitere Nutzer ausgeschlossen werden.
Realisiert wird dieses Prinzip über Sperren. Optimistische Verfahren erlauben nebenläufige Änderungen, erfordern damit jedoch eine Konfliktauflösung beim Einbringen der Änderungen. Somit erkauft man hohe Parallelität im Bearbeitungsprozess durch größeren Aufwand beim Einbringen von Änderungen. Umgesetzt
Inv.-Nr.: 2005-06-01/071/IN99/2254
86
KAPITEL 3. METADATEN
werden kann dieses Verfahren in Kombination mit einem Versionierungssystem.
Die optimistische Variante bietet damit komfortable Zusammenarbeit. Der
Server verwaltet hierfür eine Liste aller konnektierten Clients. Über diese kann
er Meldungen über Änderungen an die beteiligten Teilnehmer weiterleiten. Wird
so eine Szene von mehreren Nutzern gleichzeitig bearbeitet und ein Beteiligter hat
Daten verändert, kann diese Änderung über den Server direkt an alle Beteiligten
propagiert werden, welche ebenso an dieser Szene arbeiten.
Diese Information kann im Idealfall in Echtzeit übertragen werden, oder alternativ nach Einbringen der Änderung in die Datenbank. Hier ist die Priorität auf
entweder stete Aktualität oder leichte Rücksetzbarkeit zu setzen. Denn: wird jede Änderung unverzüglich an die anderen Teilnehmer übermittelt, können diese
sofort darauf reagieren. Sollte der initiierende Nutzer jedoch einige Änderungen
zurücknehmen, müsste dies ebenso bei allen anderen Teilnehmern passieren. Haben diese schon mit dem geänderten Datenbestand gearbeitet, kann dies hohen
Rücksetzaufwand erfordern. Dabei kann auch differenziert werden, ob Änderungen direkt in die Datenbank reflektiert werden, oder ob jeder Client eine eigene
Kopie der Daten bearbeitet. In letzterem Falle werden z.B. nach einem Commit
des Clients dessen Änderungen in den Datenbestand übernommen, während dies
andernfalls stets geschieht.
Der Server ist für alle datenbankspezifischen Aufgaben wie Transaktionsverwaltung, Sperren etc. zuständig. Zudem muss über Konsistenz bei simultaner Bearbeitung gewacht werden.
Die Umsetzung eines optimistischen Verfahrens sollte im Zusammenhang mit
einer Konzeption für lange Transaktionen erfolgen. Dafür eignet sich z.B. eine
Lösung mit Arbeitsbereichen, wie im nächsten Abschnitt kurz angesprochen.
3.7.2 Lange Transaktionen
Im Einbenutzerbetrieb ist das Konzept der langen Transaktionen schon durch das
Versionierungssystem realisiert. Es ermöglicht, beliebige „alte“ Zustände eines
Dokumentes wieder herzustellen, welche Tage oder Wochen zurückliegen.
Nicht Bestandteil dieser Arbeit ist die Umsetzung langer Transaktionen im
Mehrbenutzerbetrieb. Hier ist, wie bei der Mehrbenutzerunterstützung, der Grad
der Parallelität – ausgedrückt in pessimistischen und optimistischen Verfahren –
Ausschlag gebend für den zu betreibenden Aufwand.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
87
Pessimistische Verfahren Die einfachste Lösung der Problematik bietet ein
pessimistisches Verfahren, da dieses keinen größeren Implementierungsaufwand
erfordert. Denn: bei pessimistischen Verfahren sind durch das Sperren von Daten
diese für nur einen Nutzer gleichzeitig veränderbar. Das im Zuge dieser Diplomarbeit implementierte Versionierungssystem kann darauf einfach angepasst werden,
da theoretisch weiter ein Einbenutzerbetrieb vorliegt. Jedoch ist damit ein Teil der
Daten über längere Zeiträume für nur einen Nutzer verfügbar, was nicht praktikabel ist.
Optimistische Verfahren Ein optimistisches Verfahren erlaubt hohe Parallelität, erfordert aber auch größeren Aufwand. Dafür existieren verschiedene Möglichkeiten, die hier kurz angerissen werden. Diese basieren wiederum auf dem
Versionierungssystem, bedürfen jedoch weiterer Funktionalitäten.
Wird eine optimistische Variante gewählt, ist die Bearbeitung gleicher Daten
durch mehrere Nutzer möglich. Basis ist hier eine Originalversion der Daten. Von
dieser ausgehend wird die Parallelität ermöglicht. Eine Möglichkeit zur Realisierung sind Checkouts. Es wird eine Kopie von Teilen des Datenbestandes angelegt, damit ergibt sich ein Arbeitsbereich für den anfordernden Nutzer. In diesem
wird gearbeitet, und nach Ende des Bearbeitungsvorgangs bzw. der Transaktion wird der neue Stand in die Originaldaten eingebracht. Dies kann wiederum
Konfliktauflösung erfordern, wenn zwischenzeitlich schon andere Änderungen in
die Originaldaten eingebracht wurden. In bestimmten Szenarien kann das Prinzip
des Checkout Probleme bereiten – im Normalfall dann, wenn nur Teile des Datenbestandes ausgecheckt sind, für das weitere Vorgehen jedoch ein erweiterter
Teil benötigt wird. Dies kann z.B. der Fall sein, wenn die Daten untereinander in
Beziehung stehen. Erforderlich sind darauf hin weitere Checkouts, wofür die entsprechenden Daten wiederum zur Verfügung stehen müssen. Zu bedenken ist, dass
jeder Checkoutvorgang auch zeitliche Auswirkungen hat, da er sich über längere
Zeit erstrecken kann.
Eine weitere Möglichkeit stellt der Einsatz von sog. Alternativen dar. Es werden letztendlich von der Originalversion ausgehend neue Zweige gestartet. In diesen Zweigen werden alle Änderungen zur Ausgangsversion vermerkt, d.h. das Anlegen einer kompletten Datenkopie entfällt. Ist der Änderungsprozess vollendet,
werden die vermerkten Änderungen in die Originalversion eingebracht. Durch
dieses Prinzip ist einfach nebenläufiges Arbeiten möglich. Die Unterstützung von
sich so entwickelnden Baumstrukturen ist als Vorteil zu werten. So können von
Zweigen wiederum neue Zweige abgehen. Vorteil ist zudem, dass kein Checkout
Inv.-Nr.: 2005-06-01/071/IN99/2254
88
KAPITEL 3. METADATEN
der Daten nötig ist, der in bestimmten DBS und DB-Szenarien sehr lange Zeit
beanspruchen kann.
Zur Umsetzung der Transaktionsverwaltung, in welcher Art auch immer, kann
das System zur Mehrbenutzerunterstützung genutzt werden. Es setzt den Datencheckout als auch die Konfliktauflösung um, um letztendlich für viele Clients die
gemeinsame Arbeit zu unterstützen.
3.7.3 Konsistenz von Meta- und Audiodaten
Die Datenkonsistenz betrifft verschiedene Teile der Erstellung und Verwaltung
von Szenen und in diesen referenzierten Daten.
3.7.3.1 Konsistenz von Referenzen und Eigenschaften
Zum einen gilt es, Szenendaten (Metadaten) und von diesen referenzierte Audiodaten konsistent zu halten. Dies betrifft z.B. die Kontrolle der Übereinstimmung
von Aktivitätszeiten (Lebenszeit) eines Audioobjekts und der Spielzeit der zugewiesenen Audiodatei. Es gilt zu vermeiden, dass ein Audioobjekt eine längere
Lebenszeit hat als die Audiodatei Daten zur Verfügung stellen kann. Eine fehlende
Audiowiedergabe wäre sonst die Folge.
Um den Nutzer im Arbeitsprozess zu unterstützen, ist zudem die Verwaltung
von Referenzzählern auf verwendete Audiodaten sinnvoll. Diese Zähler enthalten
Informationen über die Anzahl an Audioobjekten, welche auf bestimmte physische Audiodaten verweisen. Sind keine Verweise mehr auf eine Audiodatei vorhanden, kann dieses automatisch vom System entfernt werden. Der entgegengesetzte Weg wird gegangen, um leere Referenzen zu finden. Das heißt, eine Szene verweist auf eine Audiodatei, welche nicht auf Festplatte existiert. Hier ist es
wiederum am System, den Nutzer auf diese Inkonsistenz hinzuweisen. Bezüglich
der Verwaltung gilt zu entscheiden, ob die Audiodaten weiterhin in einer Ordnerstruktur auf Festplatte verbleiben, oder in die Datenbank aufgenommen werden.
In letzterem Fall kann ungewollter Eingriff von außen vermieden werden. Dazu
gehören Löschungen oder Verschiebungen referenzierter Daten, was zu Leerverweisen führen könnte.
3.7.3.2 Konsistenz von Szenenbeschreibungen
Auch eine zentrale Rolle spielt die Konsistenz des Inhalts von Szenenbeschreibungen. Hier dürfen keine Inkonsistenzen in der Definition von Audioobjekten
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 3. METADATEN
89
und deren Start- und Endzeiten auftreten. Im Moment sind diese Zeiten noch absolut zum Szenenstart angegeben. Perspektivisch wird jedoch die Umstellung auf
relative Zeiten, und damit auf relative Abhängigkeiten zwischen Audioobjekten,
angestrebt. Es ergeben sich dann Ausgabebedingungen wie „Audioobjekt x startet
5 s nach Audioobjekt y“. Dabei spielt die Konsistenz der angegebenen Bedingungen (Constraints) eine große Rolle.
In der Diplomarbeit von Schröder [29] wird ein System zur Überprüfung von
Ausgabebedingungen in Multimedia-Datenbanken vorgestellt. Dies ist auch für
den Einsatzzweck im IOSONO-System geeignet. Ausgabebedingungen werden
über Difference Constraints18 definiert und in einen Graphen transformiert. Unter
Verwendung z.B. eines Bellman und Ford Algorithmus kann dieser auf Konsistenz
überprüft werden. Anschließend kann mittels des Graphen ein Ausgabeschedule
berechnet werden. Anhand dessen kann die Ausgabe der Audioobjekte erkannt
und vorgenommen werden. Gültigkeit und Konsistenz sind damit gesichert.
3.8 Implementierung - Zusammenfassung
Zur Umsetzung der vorgestellten Funktionen und Datenstrukturen wurden diverse
Klassen und Funktionen implementiert, die schon vorgestellt wurden. Zusammenfassend sind diese Ausschnittsweise in Abbildung 3.10 dargestellt. Enthalten sind
nur wichtige Funktionen für den Zugriff von anderen Klassen. Private Funktionen
zur Realisierung der Funktionalität sind nicht aufgeführt.
Eindeutig ist die zentrale Rolle der Klasse XMTSAWDbHandler, von der alle
Aktionen ausgehen. Unterstützend stehen die Klassen DbSearch, DbUpdate und
DbLoad zur Verfügung, welche spezifische Funktionalitäten anbieten. DbSearch
übernimmt alle Suchfunktionen und wurde schon eingehend erläutert. DbUpdate
und DbLoad sind zuständig für das Ausführen von Updates auf dem Datenbankbestand sowie für das Einfügen von Dokumenten, die in Form von Zeichenketten
oder Dateien vorliegen.
Die Strukturen dbChanges und dbDocument werden für den Datenaustausch
bei Funktionsaufrufen eingesetzt. Wenn mittels getChanges die Änderungen zwischen zwei Versionen abgefragt werden, kann jede Änderung in dbChanges eingetragen werden. Bei getDocs wird für jedes Dokument in der Datenbank ein
Objekt vom Typ dbDocuments angelegt, um dort die dokumentspezifischen Infor18
Difference Constraints erlauben, zeitliche und räumliche funktionelle Zusammenhänge zwischen Objekten zu definieren
Inv.-Nr.: 2005-06-01/071/IN99/2254
90
KAPITEL 3. METADATEN
Abbildung 3.10: Klassenstruktur der implementierten Metadatenverwaltung
mationen wie Name (im Attribut name) oder aktuelle Version (Attribut version)
einzutragen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Kapitel 4
Verwaltung der Audiodaten
Abbildung 4.1: Systemarchitektur, Teilsystem Audiodaten
Dieses Kapitel widmet sich der Verwaltung und Speicherung der Audiodaten.
Dies betrifft die Komponente Audioserver im IOSONO-System, in Abbildung 4.1
entsprechend hervorgehoben.
Inv.-Nr.: 2005-06-01/071/IN99/2254
92
KAPITEL 4. AUDIODATEN
4.1 Anforderungen
Auch bei den Audiodaten stehen spezielle Anforderungen an die Verwaltung im
Vordergrund. Im Gegensatz zu den Metadaten, wo die komfortable Verwaltung
primäres Ziel ist, spielen hier die Echtzeitanforderungen die größte Rolle. Im Zuge der Neuorientierung der Datenspeicherung sind somit dahin gehende Optimierungen vorzunehmen. Die Anforderungen sind in den folgenden Abschnitten detailliert formuliert.
4.1.1 Echtzeitwiedergabe
Beim Wiedergabeprozess von WFS-Content ist die Ausgabeschnittstelle hinsichtlich Performance derart zu optimieren, dass mindestens 32 Audiodateien gleichzeitig in Echtzeit ausgespielt werden können.
4.1.2 Wiedergabe entsprechend der Bedingungen der Szenenbeschreibung
Da WFS einen objektorientierten Soundwiedergabeansatz verfolgt, verfügen die
einzelnen virtuellen Audioquellen über Lebenszeiten. Entsprechend dieser Lebenszeiten erfolgt die Ausgabe der Audiodaten an die WFS-Renderer. Während
der Wiedergabe ist zu prüfen, inwiefern die Ressourcen es zulassen, dass die Audiodaten entsprechend der in der Szenenbeschreibung definierten Wiedergabezeitpunkte ausgespielt werden können und keine Kapazitätsengpässe auftreten.
4.1.3 Evaluierung
Diese Anforderungen müssen mit geeigneten Mitteln erfüllt werden. Die Performance hängt maßgeblich von der Datenrate ab, mit welcher die Audiodaten von
Festplatte gelesen werden. Um die Geschwindigkeit des Auslesens zu erhöhen,
muss letztendlich die Datenrate verbessert werden.
Die zentrale Frage ist daher: Wie kann diese Verbesserung erreicht werden?
Als mögliche Mittel werden gesehen:
• Datenkompression Werden die Audiodaten in komprimierter Form (wie im
MP3-Format) gespeichert, kann Speicherplatz gespart und die Anzahl der
Festplattenzugriffe reduziert werden.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
93
• Partitionierung Werden die Daten auf mehrere Festplatten verteilt, welche
parallel gelesen werden können, lässt sich die Gesamttransferrate steigern.
Zugriffszeit und Speichereffizienz lassen sich so optimieren.
• Datenanordnung Durch eine Anordnung der Daten in Abspielreihenfolge
kann die Anzahl der wahlfreien Zugriffe auf unterschiedliche Festplattenpositionen vermindert werden.
• Indexierung Für den wahlfreien Zugriff, d.h. wenn Sound ab einer bestimmten Position abgefragt werden soll, wirkt eine Indexierung unterstützend.
Ein Zeitgewinn durch den Direktzugriff sollte sich bemerkbar machen.
• Caching Bei Schleifen oder der wiederholten Verwendung derselben Objekte kann Caching die Anzahl der Festplattenzugriffe reduzieren. Dieser
Fall ist im IOSONO-System jedoch recht selten, daher wird der Erfolg von
Caching als recht gering angesehen.
• Prefetching Um Engpässe auszugleichen, kann ein Prefetching von Audiodaten verwendet werden. Damit findet stets eine Vorpufferung der als
nächstes benötigten Daten statt. Tritt so ein Lesezugriff mit hohem Zeitbedarf auf, kann dieser im Optimalfall durch die vorgepufferten Daten ausgeglichen werden. Natürlich muss zwischen solchen Ausreißern genügend
Zeit für das Prefetching bleiben.
Eingeschränkt werden müssen diese Möglichkeiten mit Blick auf die Umsetzung in IOSONO. Zum einen soll im Moment darauf verzichtet werden, mehrere
Festplatten vorauszusetzen. Dies soll es Kinos oder sonstigen Anbietern erleichtern, das IOSONO-System zum Einsatz zu bringen, ohne in aufwändige Hardware
investieren zu müssen. Zum anderen wird darauf verzichtet, die Daten zu komprimieren. IOSONO ist auf optimalen Klang ausgelegt. Da z.B. mp3 mit Qualitätseinbußen einhergeht, wird vom Einsatz eines solchen Systems abgesehen. Langfristig wird jedoch über die Verwendung von z.B. mpeg4 nachgedacht.
Somit bleiben die Möglichkeiten, welche an Strukturen und Funktionen betreffs Speicherung und Retrieval von Audiodaten ansetzen.
4.2 Wichtige Systemkomponenten
Alle Aktionen, für welche die Audiodaten von Relevanz sind, spielen sich im
Audioserver ab. Dieser liest die Audiodaten von Festplatte, puffert diese und ist
Inv.-Nr.: 2005-06-01/071/IN99/2254
94
KAPITEL 4. AUDIODATEN
für ihre Weiterleitung an die Renderer verantwortlich. Da die Datenübertragung
an die Renderer keinen Flaschenhals darstellt, sind alle performancerelevanten
Faktoren im Audioserver zu finden. Alle optimierenden Hard- oder SoftwareÄnderungen sind dort anzusetzen.
Der Audioserver besteht aus diversen Komponenten, welche die Gesamtfunktion zur Verfügung stellen. Verantwortlich für das Auslesen der WAV-Dateien sind
die Klassen DiskThread und DiskThreadScheduler. Diese übernehmen im Kern
die Funktionen des Audioservers, welche in Abbildung 2.3 auf Seite 25 schon
dargestellt wurden.
Um ein neues Datenspeicherformat zu integrieren, bilden diese Klassen die
anzupassende bzw. zu ersetzende Schnittstelle. Andere Komponenten und enthaltene Klassen können bestehen bleiben, wodurch sich der Änderungsaufwand für
ein neues Datenverwaltungssystem in Grenzen hält.
4.3 Systeme zur Speicherung von Audiodaten
Derzeitig werden die Audiodaten in WAV-Dateien auf Festplatte gespeichert. Somit ist das Dateisystem Basis der Speicherung. Eine optimierende Datenverwaltung existiert nicht. Indexierung oder Datenanordnung spielen keine Rolle oder
sind nicht beachtet. Einzig ein Prefetching ist implementiert, um unperformante
Lesevorgänge auszugleichen.
Es muss nun ein Verwaltungssystem gefunden werden, das große Mengen an
Audiodaten in Echtzeit zur Verfügung stellen kann. Dafür als geeignet angesehene
Techniken werden im Folgenden vorgestellt.
4.3.1 Streaming-Server
Streaming-Server sind für die Auslieferung von Audiodaten in Echtzeit konzipiert und erfüllen daher die hier gestellte Anforderung. Verschiedene Anbieter,
wie Apple mit QuickTime1, bieten solche Systeme an. Diese sind im weltweiten
Netz für das Streamen von Audio-Inhalten an vielen Clients im Einsatz. Der Nachteil aller Vertreter ist, dass die Systeme auf proprietären Formaten basieren. Daten
werden über Encoder in komprimierte Datenformate umgewandelt. Da IOSONO
das WAV-Format beibehalten soll, und auch die Qualität dieser Daten nicht sinken
darf, fallen Streaming-Server aus der Liste der brauchbaren Lösungen.
1
http://developer.apple.com/quicktime/
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
95
4.3.2 Datenbankmanagementsysteme
Indexierung und Caching, als mögliche performancesteigernde Faktoren gesehen,
sind in nahezu jedem Datenbanksystem integriert. Die Datenanordnung kann dabei den Speicherstrukturen hinsichtlich optimaler Performance angepasst werden.
Prefetching muss jedoch über eigene Mechanismen zur Verfügung gestellt werden.
Somit kann ein Datenbankmanagementsystem als mögliche Lösung der Speicherproblematik gesehen werden. Ein kurzer Blick auf herkömmliche RDBMS
oder OODBMS soll deren Tauglichkeit zeigen.
4.3.2.1 RDBMS und OODBMS
In einem solchen Datenbanksystem lässt sich jede Art von Daten speichern, somit
auch Audiodaten. Jedoch existieren keine Hilfsmittel zur Speicherung von Multimediadaten, gerade was die Performance angeht. Zwar lassen sich bei RDBMS
in Form von BLOBs oder ähnlichen Strukturen beliebige Daten speichern und
verwalten – damit auch Audiodaten, wie hier gefordert. Jedoch müssen bzgl. der
Echtzeitanforderungen Abstriche gemacht werden. Gleiches gilt für OODBMS,
bei denen die Audiodaten in Objektform überführt werden müssten.
Da somit diese DBMS keine herausragenden Vorteile bieten, ist die Verwendung eines DBMS mit proprietärem Datenmodell denkbar. Hier entfällt der Aufwand für die Umwandlung der Daten in relationale Strukturen. Da für die Verwaltung der Metadaten mit BDB XML schon ein proprietäres DBMS verwendet wurde, bietet sich die Verwendung von dessen Basis für die Audiodatenspeicherung
an. Diese Basis ist das schon vorgestellte Berkeley DB, das ein komplettes Datenbankmanagementsystem zur Verfügung stellt. Da es schon in IOSONO integriert
ist, ließe sich durch dessen Verwendung die Abhängigkeit des IOSONO-Systems
von weiteren Datenbankdateien und -bibliotheken vermeiden.
4.3.2.2 Berkeley DB
Berkeley DB bietet einen schlanken Aufbau, ist als Bibliothek leicht ins bestehende System integrierbar und verzichtet auf umfangreiche Zusatzelemente. Grafische Oberflächen oder sonstige Tools sind nicht vorhanden, werden aber im betrachteten Fall auch nicht benötigt. Berkeley DB vertraut nicht auf ein relationales
oder objektorientiertes Datenmodell. Daten müssen daher nicht in Relationen oder
Objekte überführt werden. Sie werden mit zugeordnetem Schlüssel, welcher der
Inv.-Nr.: 2005-06-01/071/IN99/2254
96
KAPITEL 4. AUDIODATEN
Identifikation dient, in Dateien abgelegt. Durch dieses Prinzip lassen sich beliebige Daten einfach speichern und adressieren. Auch wird nicht über eine Anfragesprache wie SQL auf die Daten zugegriffen. Stattdessen werden Daten direkt über
Funktionsaufrufe und darin integrierte Dateizugriffe abgefragt. Dies verspricht
performantere Zugriffe als z.B. relationale DBMS dies anbieten, da der mit SQL
verbundene Anfrageaufwand und die Abbildung von Relationen aufs Dateisystem
entfallen.
4.3.3 Dateisystem
Alternativ bietet sich weiterhin die Speicherung in Dateien an, worauf schon gegenwärtig gebaut wird. Im Unterschied zur bisherigen Variante sollte jedoch vom
Prinzip der vielen, meist kleinen, WAV-Dateien abgesehen werden. Durch Zusammenlegen der in diesen enthaltenen Audiodaten in nur eine Datei (oder wenige große Dateien, d.h. unter Umständen bis zum Gigabyte-Bereich), angeordnet
entsprechend der Abspielreihenfolge der Daten, kann womöglich eine optimierte Leseperformance erreicht werden. Als Grundlage dafür wird der Punkt angesehen, dass das oftmalige Lesen kleiner Datenmengen aus vielen Dateien dann
vermieden werden kann. Es ist kein stetiger Wechsel zwischen den beteiligten
Dateien nötig, was durch Festplattenrotationen zur Ansteuerung der Dateicluster
Performance kostet. Optimal wird die Ein-Datei-Lösung, wenn diese Datei nicht
fragmentiert auf Festplatte liegt.
Im Vergleich zur Lösung mit Berkeley DB entfällt zusätzlich der Aufwand
zur Verwaltung der Daten in bestimmten Zugriffsstrukturen. So können Leseanfragen direkt und in chronologischer Ordnung bearbeitet werden, ohne erst anhand z.B. Baumstrukturen die benötigten Dateien oder Dateiabschnitte aufzusuchen und auszulesen.
4.3.4 Fazit
Da Streaming-Server durch proprietäre Audioformate nicht verwendbar sind und
Standard-DBMS keine wirklich positiven Eigenschafen bieten, wird letztendlich
das DBMS Berkeley DB als Lösung der Datenverwaltungsproblematik in Betracht
gezogen. Dort können verschiedene Arten der Datenanordnung, diverse Zugriffsmethoden und weitere Konfigurationsmöglichkeiten so an die Anforderungen angepasst werden, dass eine optimale Speicherung der Daten möglich erscheint.
Weniger Konfigurationsoptionen bietet eine Speicherung in Form einfacher
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
97
Dateien. Jedoch sind hier noch Optimierungen im Vergleich zur aktuellen Implementierung möglich, welche daher auf ihre Eignung untersucht werden.
Somit spielen diese zwei Systeme in den folgenden Betrachtungen die zentrale Rolle. Anhand diverser Performancetests wird die Eignung für den Einsatz in
IOSONO untersucht. Diese lassen erkennen, ob datenbankspezifische Mittel wie
Indexierung und Caching die Performance gegenüber dem Dateisystem verbessern können. Als Vertreter des Dateisystems wird vergleichend eine neue Variante
der Speicherung der Audiodaten in Dateien auf ihre Performance untersucht.
4.4 Randbedingungen
Um die Echtzeitanforderungen – die primäre Anforderung an die AudiodatenVerwaltung – näher zu spezifizieren, kommt im Folgenden eine kurze Vorstellung
der verschiedenen beteiligten Werte. Im IOSONO-System werden Audiodaten
im WAV-Format mit einer Samplegröße von 24 Bit und einer Samplingfrequenz
von 48.000 Hz verarbeitet. Dies erfordert eine Datenrate von 48.000 Samples/s ·
3 Byte ≈ 140 kByte/s pro Audioobjekt. Wird der Fall von 64 simultan aktiven Audioobjekten angenommen, so ergibt sich ein Bedarf von ca. 9 MByte Audiodaten
pro Sekunde, welche ausgelesen und in IOSONO verarbeitet werden müssen.
Als technische Randbedingung ist zu nennen, dass für Datenspeicherung und
-retrieval ein Standard-Rechner zu verwenden ist. Daher sind bestimmte Performance bestimmende Faktoren durch verwendete Hardware, Betriebssystem sowie
Dateisystem eingeschränkt.
4.5 Tests
Vor der Umsetzung in ein neues Datenverwaltungssystem stehen umfangreiche
Tests. Für eine Realisierung in Berkeley DB gilt es, unter Beachtung von Faktoren
wie Datenorganisation, Indizes, Caching und anderen Konfigurationsparametern
die geeignetste Datenbankkonfiguration zu finden. Anschließend wird anhand von
Testergebnissen über die Eignung für den Einsatz im IOSONO-System entschieden (Abschnitt 4.7).
Ebenso werden Tests für die neue auf Dateien basierende Lösung durchgeführt
(Abschnitt 4.8). Dies ermöglicht einen Vergleich der verschiedenen Realisierungsmöglichkeiten untereinander und zur gegenwärtigen Umsetzung in IOSONO. Deren Performance wird zuerst untersucht (Abschnitt 4.6) Alle durchgeführten UnInv.-Nr.: 2005-06-01/071/IN99/2254
98
KAPITEL 4. AUDIODATEN
tersuchungen basieren auf WAV-Daten mit einer Samplegröße von 24 Bit und einer Frequenz von 48.000 Hz.
Alle Tests simulieren das Lesen von Audiodaten zu einer gegebenen Menge
von gleichzeitig aktiven Audioobjekten. Deren Zahl wird je nach Test auf 32 bzw.
64 festgesetzt. 32 entspricht der aktuellen Grenze des IOSONO-Systems, und mit
64 Quellen lässt sich das Potential der untersuchten Speichermethoden erkennen,
insbesondere ob noch Spielraum für eine Erweiterung um weitere Quellen existiert. In jedem Test wird eine bestimmte Anzahl von Abfragen durchgeführt. Pro
Abfrage werden am Stück 512 Samples für jedes der 32 bzw. 64 beteiligten Audioobjekte gelesen. Der Wert von 512 Samples hat sich als für die Tests genauso
geeignet herausgestellt wie z.B. 4.096 oder andere Werte, d.h. diese zeigten keine
Zeitunterschiede. Auch lassen sich mit 512 Samples die erzielten Lesezeiten gut
vergleichen. Die Basis für die Vergleiche stellt ein Soll von ca. 10 ms dar. In dieser Zeit müssen für alle aktiven Quellen die 512 Samples gelesen werden. Mit der
Anzahl an Abfragen lässt sich schließlich die Gesamtmenge an gelesenen Daten
und somit die Aussagekraft der Durchschnittswerte pro Abfrage erhöhen.
Jedes Testszenario wurde mehrmals (im Durchschnitt 10 Mal) durchgeführt,
um repräsentative Ergebnisse zu erzielen. Die im Folgenden angegebenen Zeiten
sind daher als Mittelwerte aus diesen Durchgängen zu sehen.
4.6 Die aktuelle IOSONO-Implementierung
Grundlage aller Vergleiche und Optimierungsversuche ist ein Blick auf die aktuelle Systemimplementierung des Auslesens der Audiodaten. Um die Performance
von Datenbankentwurf und alternativen Lösungen beurteilen zu können, wird die
aktuelle Implementierung einem ersten Test unterzogen. Dies ermöglicht später
eine Einordnung der Ergebnisse der untersuchten Alternativen.
4.6.1 Implementierung
Von technischer Seite sind Grundlage der aktuellen Lösung WAV-Dateien, welche
die Audiodaten enthalten. Jedem Audioobjekt sind entsprechende Dateien zugeordnet. Das Auslesen geschieht über verschiedene C++-Klassen, welche letztendlich auf die read-Funktion des Dateisystems zugreifen.
Die Übertragung beruht auf einem Slot-Konzept. Slots repräsentieren die Audioströme mit den Audiodaten aus den WAV-Dateien in einem für den Renderer
verarbeitbaren Format. Die Slots können zeitgetaktet ausgelesen werden.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
99
Jeder Slot enthält Audiodaten für ein zugehöriges Audioobjekt. Das heißt: bei
einem System mit max. 32 parallel aktiven Audioobjekten existieren 32 Slots.
Während der Wiedergabe werden ständig Audiodaten aus den WAV-Dateien gelesen, deren Sample-Werte bestimmt und in die Slots eingefügt. Dort werden
sie gepuffert, bis sie für die Übertragung an die Renderer benötigt werden. Die
Pufferung ist nötig, da das Auslesen der Audiodateien keine verlässlich gleichniedrigen Zeiten vereinnahmt, sondern auch Ausreißer auftreten können. Es gilt,
diese auszugleichen, wofür die Puffer eingesetzt werden. Dabei enthält jeder Slot
Speicherplatz für 100.000 Samples, um ausreichend Spielraum zu haben.
Bei jeder Abfrage wird nur eine bestimmte Anzahl an Samples pro Datei gelesen. Es gilt, aus allen Dateien für alle Slots gleichmäßig Daten zu lesen, um nicht
einen Slot an das Pufferende kommen zu lassen. Andernfalls würde ein Kanal keine Audiodaten für die Wiedergabe enthalten und somit in der Audiowiedergabe
Lücken auftreten. Die Slots werden entsprechend des aktuellen Bedarfs nach Prioritäten sortiert und in dieser Reihenfolge mit Daten bedient – Slots mit nur noch
wenigen gepufferten Daten zuerst. Ohne die Pufferung und das getaktete Lesen
könnte die Datenrate beim Auslesen den Bedarf an Daten z.T. nicht decken.
Alle Audiodaten eines Slots sind mit Informationen zu deren Wiedergabezeitpunkt innerhalb der Audioszene gekennzeichnet. Ist einem Slot für eine bestimmte
Wiedergabezeit keine Audiodatei zugeordnet, enthält dessen Puffer keine Daten.
Stattdessen werden schon die nächsten benötigten Daten gelesen und mit einer
Wiedergabezeit versehen. Bis diese erreicht wird, werden für die Übertragung an
die Renderer leere Samples generiert, welche Stille repräsentieren.
4.6.2 Performance
Alle Tests zielen darauf hinaus, die Zeiten für das Auslesen einer bestimmten Anzahl von Audiodaten zu untersuchen. So kann gesehen werden, ob die Echtzeitanforderungen durch das untersuchte System, oder eine bestimmte Konfiguration,
erfüllt werden können.
Untersucht wurde im ersten Test das Auslesen von Audiodaten für 32 parallel aktiven Audioquellen. Dabei wurden ca. 100.000 Audiosamples pro Quelle
gelesen, aufgeteilt auf 200 Abfragen je 512 Samples. Die Ergebnisse sind in Diagramm 4.2 zu sehen. Die entstehende Verteilung bestätigte sich in unterschiedlichen Tests. Zu sehen sind auf der x-Achse die 200 Abfragen à 32×512 Samples,
auf der y-Achse die benötigte Zeit je Abfrage in Millisekunden.
Das Ergebnis: Die durchschnittliche Lesezeit für 32×512 Samples beträgt
Inv.-Nr.: 2005-06-01/071/IN99/2254
100
KAPITEL 4. AUDIODATEN
Abbildung 4.2: 200 Abfragen mit je 512 Samples und 32 Audioquellen
10.9 ms. Eindeutig zu sehen ist, dass dabei ein Großteil der Werte bei 2-3 ms,
und damit weit unter dem Soll von 10 ms, liegt. Jedoch sorgen die starken Ausreißer – bis zu über 600 ms – für eine relevante Verschlechterung der Lesezeit.
Aus der Verteilung wird auch klar, dass nur die Nutzung eines großen Puffers
die geforderten Lesezeiten sicherstellen kann. In der Zeit der schnellen Lesezeiten
ergibt sich genug Spielraum, um die schlechten Ergebnisse auszugleichen. Deutlich wird anhand der Zeiten jedoch auch, dass offensichtlich kein Platz nach oben
besteht. Das heißt, eine Erweiterung auf mehr als 32 gleichzeitig aktiven Quellen
scheint vom System nicht bewältigbar.
Somit erklärt sich auch der Bedarf nach einer neuen Speicherlösung. Untermauert wird dies durch einen Test mit 64 Quellen. Die Abbildung 4.3 auf der
nächsten Seite zeigt erneut den erzielten Verlauf. Mit einer Durchschnittszeit von
25 ms und Ausreißern von bis zu 1.3 Sekunden für das Lesen von nun 64×512
Samples ist keine Echtzeitfähigkeit mehr gewährleistet. Skalierbarkeit ist dementsprechend nicht mehr gegeben.
Um die Tauglichkeit der alternativen Lösungen Berkeley DB und integrierte
Datei zu untersuchen, werden diese in den nächsten Abschnitten mittels ähnlicher
Testszenarien untersucht.
4.7 Verwaltung mittels Berkeley DB
In diesem Abschnitt wird die Verwendbarkeit des Berkeley Datenbanksystems für
die gestellten Anforderungen untersucht. Speziell Tests zur Leseperformance solInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
101
Abbildung 4.3: 200 Abfragen mit je 512 Samples und 64 Audioquellen
len zeigen, ob die geforderten Echtzeitanforderungen eingehalten werden können.
Zuvor folgen zur Einführung ein paar Worte über das BDB Datenbankkonzept.
Grundsätzlich enthält jede Berkeley Datenbank Datensätze, wobei logisch gesehen jeder Datensatz einen einzelnen Eintrag in der Datenbank repräsentiert. Jeder
Datensatz besteht aus zwei Teilen: einem Schlüssel sowie den eigentlichen Daten.
Der Schlüssel identifiziert einen Datensatz. Durch diese Schlüssel-/Daten-Paare
kann man sich die Datenbank als zweispaltige Tabelle vorstellen. Dabei können
Schlüssel als auch Daten beliebiger Art und Komplexität sein.
4.7.1 Konfigurationsmöglichkeiten für BDB-Tests
Für die Tests mit Berkeley DB gibt es eine Reihe von Faktoren, die zu beachten sind. Es geht um verschiedene Konfigurationsmöglichkeiten, welche die Geschwindigkeit des Datenzugriffs und somit der Auslieferung der Audiodaten aus
der Datenbank beeinflussen können. Bevor die Tests beginnen, werden hier die
Faktoren angesprochen, welche in Zusammenhang mit der Performance stehen.
4.7.1.1 Art des Datensatz-Schlüssels
Der Zugriff auf die Datensätze geschieht über Schlüsselwerte. Diese müssen sinnvoll gewählt werden, um die benötigten Daten schnell zu ermitteln. In Kombination mit der richtigen Zugriffsmethode (4.7.1.3) stellen Schlüssel einen geschwindigkeitsrelevanten Faktor dar.
Da alle Audiodaten einen Zeitbezug haben (in Form des Wiedergabezeitpunktes), ist es sinnvoll, diesen in den Schlüsseln zu verwenden. So könnte ein Zeitstempel-Wert den Wiedergabezeitpunkt der Daten eines Datensatzes angeben und
Inv.-Nr.: 2005-06-01/071/IN99/2254
102
KAPITEL 4. AUDIODATEN
als Schlüssel verwendet werden.
Ein Faktor, welcher bei der Wahl eines Schlüssels zu beachten ist, ist die parallele Aktivität verschiedener Audioquellen. Dies bewirkt, dass ein einfacher Zeitwert nicht mehr zur Identifikation ausreicht. Sind 32 Audioquellen gleichzeitig
aktiv, müssen zum entsprechenden Zeitwert 32×512 Samples ausgelesen werden.
Welches Sample zu welcher Quelle gehört ist aus einem Zeitwert dabei nicht erkennbar.
Ein komplexerer Schlüssel ist daher nötig, um gleichzeitig aktive Quellen unterscheiden zu können. In den Tests wird davon ausgegangen, dass dafür eine
geeignete Lösung gefunden wird. Eine Möglichkeit wäre, alle Samples von parallelen Quellen für einen Zeitwert t unter aufeinander folgenden Schlüsseln abzulegen. Anschließend kämen alle Samples der Quellen für den Zeitwert t+1 und so
weiter fort. Dabei muss der Überblick behalten werden, wie viele Quellen gleichzeitig aktiv sind.
Denkbar ist auch eine Erweiterung des Zeitwertes um die Kanalnummer, wobei eine Sortierung der Werte zuerst nach Zeit und anschließend nach dieser Nummer erfolgt. Somit werden Samples aller Audioquellen entsprechend ihrer Abspielreihenfolge abgespeichert. Eine weitere Möglichkeit ist die Einführung einer
extra Datenstruktur für den Schlüssel.
Auswahl für die Testszenarien In den Tests wird der einfachste Fall, mit Zeitstempeln als Schlüssel, angenommen. Dafür wurden chronologisch aufeinander
folgende Integer-Werte verwendet, um Zeitstempel-Werte zu simulieren.
Da sich Zeistempel auch in Form von Zeichenketten speichern lassen, werden
in gegenüberstellenden Tests beide Formen der Speicherung getestet – in Form
von Integern und Zeichenketten.
4.7.1.2 Datensatzgröße
Jeder Datensatz in einer BDB Datenbank enthält eine bestimmte Menge von Daten – für IOSONO wären dies eine bestimmte Anzahl an Samples – und somit eine
bestimmte Größe. Die Frage ist, wie viele Samples für die effizienteste Datensatzgröße zu wählen sind. Dafür werden verschiedene Möglichkeiten in Erwägung
gezogen.
Variante 1 Eine Orientierung erfolgt hierfür an der aktuellen IOSONO-Implementierung. Dort werden bei einer Abfrage der Audiodaten Datenmengen für
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
103
4.096-8.192 Samples pro Audiodatei entnommen und gepuffert. Angelehnt daran wird diese Datenmenge als Grundlage eines Testfalls für BDB genommen: jeder Datensatz erhält Daten für 4.096 Samples. Als Schlüssel werden Zeitstempelbezogene Werte verwendet, welche den Wiedergabezeitpunkt der entsprechenden
Samples angeben.
Zu untersuchen ist jedoch, ob 4.096 Samples pro Datensatz (S/DS) auch tatsächlich die schnellste Variante darstellen. Für eine Vergleichsmöglichkeit werden
weitere Werte herangezogen:
• Daten für 512 Samples pro Datensatz, da dies die Datenmenge pro Übertragung an den Renderer darstellt
• 128 Samples, um zu sehen, ob das häufige Lesen kleiner Datenmengen effizienter ist als der umgekehrte Weg
Variante 2 Eine weitere Möglichkeit ist ein komplett anderer Ansatz, die Audiodaten zu verteilen. Anstatt jedem Datensatz nur einen Ausschnitt an Audiodaten
einer WAV-Datei zuzuordnen, kann auch der komplette Audioinhalt einer oder
mehrerer WAV-Dateien (referenziert von einer gemeinsamen Audioquelle) einem
Datensatz zugeordnet werden. Als Schlüssel wird dabei der jeweils eindeutige
Name der Audioquelle gewählt, alternativ ist auch ein Zeitstempel-Wert denkbar.
Da bei dieser Datenanordnung der Zugriff auf die Daten zu einem bestimmten
Abspielzeitpunkt nicht mehr direkt über den Schlüssel möglich ist, muss die Abfrage etwas differenzierter geschehen. Dafür wird nur ein Teil der im Datensatz
abgelegten Daten abgefragt, entsprechend der aktuell benötigten Datenmenge. Ein
derartiges Verhalten ist mittels von BDB zur Verfügung gestellten Abfragemethoden erreichbar.
Das Ergebnis der Tests beider Möglichkeiten wird zeigen, ob eine Datenbank
mit wenigen großen Datensätzen performanter ist als eine Datenbank mit vielen
kleineren Datensätzen.
4.7.1.3 BDB Zugriffsmethoden
BDB bietet für die Datenverwaltung verschiedene Zugriffsmethoden an. Dies sind
BTree, Hash, Recno und Queue. Jede Methode bietet Vor- und Nachteile entsprechend der Art der zu speichernden Daten und der Art des zu erwartenden Zugriffs.
Inv.-Nr.: 2005-06-01/071/IN99/2254
104
KAPITEL 4. AUDIODATEN
• BTree Bei der Zugriffsmethode BTree werden die Daten in einer sortierten,
balancierten Baumstruktur abgespeichert. Ein Vorteil dieser Zugriffsmethode ist, dass mehrere Datensätze den gleichen Schlüssel haben können.
• Hash Daten werden als erweiterter linearer Hash abgelegt. Duplikate, d.h.
unter einem Schlüssel befinden sich mehrere Datensätze, sind wie auch
beim BTree erlaubt.
• Queue Die Daten werden in Form einer Liste als Datensätze mit fester Länge abgespeichert. Das Design bevorzugt schnelle Einfügeoperationen am
Ende der Liste. Zudem gibt es spezielle Operationen für Retrieval und Löschen vom Kopf. Die Queue ermöglicht als einzige Zugriffsmethode Sperren auf Datensatzebene.
• Recno Datensätze mit fester oder variabler Länge sind erlaubt. Zur Identifikation werden logische Datensatznummern als Schlüssel verwendet.
Auswahl einer geeigneten Zugriffsmethode Zu den verschiedenen Zugriffsmethoden gibt es einige Regeln, die zur Auswahl zwischen diesen herangezogen werden können. Die richtige Zugriffsmethode ist mitentscheidend über die
Performancecharakteristika der zu implementierenden Datenbankumgebung im
IOSONO-System.
Die Zugriffsmethode richtet sich stark nach Größen wie Datentyp und Inhalt
der Schlüssel als auch der Größe der Datensätze. Bezogen auf die vorgestellten
Arten des Schlüssels und Samples pro Datensatz lässt sich festhalten:
Werden den Datensätzen begrenzt Samples zugeordnet (wie z.B. je 4.096;
Datensatzgröße-Variante 1) und als Schlüssel Zeitstempel genutzt, empfiehlt sich
die Nutzung von Queue oder Recno. Der Grund ist, dass bei logischen Datensatznummern, und insbesondere Integer-Werten, diese die beste Wahl sind. Werden
dagegen ganze WAV-Dateien je Datensatz abgelegt (Datensatzgröße-Variante 2),
und die zugehörigen Schlüssel als beliebige Zeichenketten erstellt, sind BTree
oder Hash zu wählen. Diese sind erste Wahl bei beliebigen Schlüsseln.
Jedoch sind dies nur grundlegende Auswahlregeln. Bei detaillierterem Blick
auf die Einflussfaktoren gilt:
• BTree/Hash Ist die Größe von Datensätzen kleiner als der Cache, aber größer als dass nahezu alle Datensätze in den Cache passen, so sollte bei LokaInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
105
lität des Schlüsselzugriffs 2 der BTree gewählt werden.
Außer bei Vor- oder Rückspulen wird bei IOSONO Sample für Sample aus
der Datenbank benötigt, d.h. die Datensätze werden entsprechend ihrer Sortierreihenfolge abgerufen. Somit ist Lokalität gegeben, was auf den BTree
hindeutet. Andererseits sind die Datenmengen so groß, dass nur ein Teil der
ausgelesenen Daten in den Cache passt, und viele Zugriffe werden benötigt. Dies passt auf die Charakteristiken des Hash-Zugriffs, der dann von
der geringeren Anzahl an Verwaltungsdaten profitieren könnte.
• Queue/Recno Die Queue eignet sich besonders bei hohem Grad an konkurrierendem Zugriff, da Sperren auf Datensatzebene unterstützt werden.
Jedoch können nur Datensätze fester Größe verwendet werden, im Gegensatz zu Recno. Recno erlaubt zudem selbst festlegbare Schlüssel, was bei
Queue nicht möglich ist. Zudem können flache Textdateien als permanenter Speicher benutzt werden. Auf IOSONO bezogen ist eindeutig Recno zu
bevorzugen, da feingranulare Sperren nicht benötigt werden, dagegen eine
freie Schlüsselwahl zu präferieren ist.
Fazit Für die Tests werden BTree, Recno und Hash einer eingehenden Überprüfung unterzogen. Diese erfüllen für Variante 1 und 2 der Datensatzgrößen jeweils
einen Teil der an sie gestellten Anforderungen, und sind daher für die weiteren
Schritte relevant.
4.7.1.4 Datenzugriff
Neben der datenbankinternen Zugriffsmethode gilt es, die geeignete Art des Datenzugriffs zu wählen. Dazu stehen grundsätzlich, neben der einfachen Suche über
den Datensatzschlüssel, Cursor und Bulk-Abfragen zur Verfügung. Hier stellt sich
die Frage, mit welcher Methode die schnellste Lesbarkeit der später eingepflegten
Audiodaten erreicht wird.
Cursor Cursor erlauben u.a. schnelles Durchlaufen der Datensätze einer Datenbank. Bezüglich allen Zugriffsmethode gilt die Regel, dass der Zugriff über
Cursor das Problem mit großen Datensätzen lindert.
2
Eine Lokalität des Schlüsselzugriffs kann dazu beitragen, schnellere Reaktionszeiten bei Zugriffen auf benachbarte Schlüssel (und somit Datensätze) zu erhalten. Diese Lokalität liegt z.B.
vor, wenn zwei benachbarte Schlüssel die Werte „aaaaa“ und „aaaab“ haben, d.h. aufsteigend sortiert sind.
Inv.-Nr.: 2005-06-01/071/IN99/2254
106
KAPITEL 4. AUDIODATEN
Bulk-Abfragen Beim Auslesen einer großen Anzahl von Datensätzen aus einer
Datenbank kann die Anzahl an Funktionsaufrufen die Performance stark beeinflussen. In manchen Fällen kann dies durch Bulk-Abfragen verbessert werden.
Dabei werden mehrerer Datensätze mit einem einzigen Funktionsaufruf aus der
Datenbank abgefragt. Anschließend werden die abgefragten Datensätze aus der
erhaltenen Struktur extrahiert.
Indexe Keine Wahl bei der Organisation der Datenstruktur spielen Indexe. Diese sind in Berkeley DB nicht explizit setzbar. Der Zugriff erfolgt allein über den
Schlüssel eines Datensatzes. Somit sind Indizierungen von Komponenten der Datenbank weder möglich noch nötig.
4.7.1.5 Format der gespeicherten Daten
Offen ist auch die Frage, in welcher Form die Daten abgespeichert werden. Zwei
Alternativen scheinen sinnvoll: zum einen das Abspeichern von Samples in ihrer Repräsentation als Float-Werte, wie sie auch zum Renderer gesendet werden.
Zweite Möglichkeit ist das Abspeichern im WAV-Format, wie sie in den WAVDateien enthalten sind. Hier ist nach Auslesen der Daten eine Umwandlung ins
Float-Format nötig, um den Renderer zu bedienen.
Die Unterschiede durch die Wahl des Datenformates sollten im Datenvolumen sichtbar werden. Im WAV-Format sind pro Sample 16 bzw. 24 Bit nötig. Ein
Float benötigt im Normalfall 32 Bit, d.h. um 25-50% mehr Datenvolumen ist zu
erwarten. Damit bleibt zu klären, ob der Umwandlungsaufwand höher liegt als der
erhöhte Ausleseaufwand durch die vergrößerte Datenbank.
4.7.1.6 Seitengröße (Pagesize)
Dieser Parameter gibt die Größe der Seiten an, welche für die Datenbanken benutzt werden. Auch diese hat entscheidenden Einfluss auf die Performance und
wird durch diverse Faktoren beeinflusst (siehe [30], Abschnitt „Access Method
Configuration, Selecting a page size“).
Die Testdurchgänge wurden mit zwei verschiedenen Werten für die Seitengröße durchgeführt. Dies ist zum einen 4 kByte, was der Seitengröße des Dateisystems entspricht. Eine kleinere Größe wurde zwar untersucht, brachte durch die
starke Clusterung der Daten aber nur Geschwindigkeitseinbußen und wird daher
hier nicht weiter betrachtet. Zweiter Testwert ist 64 kByte. Die maximale SeitenInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
107
größe ist auf diesen Wert durch das Datenbanksystems restriktiert. Mit diesem und
dem Wert von 4 kByte wird getestet, welche Seitengröße geeignet ist.
4.7.2 Testszenarien und Ergebnisse
In diesem Abschnitt werden alle durchgeführten Testszenarien sowie deren Ergebnisse vorgestellt. Alle Tests liefen daraus hinauf, die Performance der Systemkonfiguration im jeweiligen Tests zu überprüfen. So wurde mit verschiedenen BDB-Konfigurationen sowie Datenverteilungsmöglichkeiten gearbeitet, um
die performanteste Lösung zu finden.
Die Grundlage der Tests bildeten diverse, von Berkeley DB mit Parametern
entsprechend der jeweiligen Konfiguration angelegten Datenbankdateien. Diese
waren mit Beispieldaten aus vorhandenen WAV-Dateien gefüllt und wurden in
den Tests entsprechend der Auslesecharakteristiken von IOSONO, d.h. in chronologischer Ordnung, ausgelesen. Die abgefragten Datenmengen unterschieden sich
entsprechend den Testszenarien.
Die ersten Tests wurden mit weniger Datenvolumen durchgeführt, um einen
Trend zu erkennen. Damit konnten die geeignetste Zugriffsmethode sowie Zugriffsart bestimmt werden. Auch ließ sich die Größe der entstehenden Datenbankdateien untersucht, um Konfigurationen mit zu großen Dateien auszuschließen.
Anschließend folgten Tests mit mehr Durchläufen und größerem Datenvolumen,
um eine Feinabstimmung durchführen zu können.
4.7.2.1 Erste Erkenntnisse
Getestet wurde mit Schlüsseln in Form von aufsteigend geordneten Zeitstempeln,
sowohl als Integer wie auch als String. Bei entsprechender Sortierung und Vergleichsfunktion 3 konnten keine Zeitunterschiede zwischen beiden Arten festgestellt werden. Auch unter Nutzung eines Cursors gab es keine messbaren Differenzen zwischen beiden Methoden. Daher wurden alle weiteren Tests mit IntegerWerten als Schlüssel durchgeführt.
Auch getestet wurde die Abfrage der Daten mittels eines so genannten BulkZugriffs. Waren Daten für 32 Quellen je 512 Samples pro Datensatz gespeichert,
sollte die Bulk-Abfrage die Daten aller 32 Datensätze mit einem Funktionsaufruf abfragen. Jedoch stellte sich heraus, dass die Ergebniszeiten schlechter wa3
Vergleichsfunktionen vergleichen Schlüssel von Datensätzen zur Sortierung und den Datenzugriff und können vom Nutzer festgelegt werden
Inv.-Nr.: 2005-06-01/071/IN99/2254
108
KAPITEL 4. AUDIODATEN
ren als beim Normalfall mit 32 Abfragen an die Datenbank. Also zeigt sich hier,
dass mehrere einzelne Funktionsaufrufe einen umfangreichen Aufruf übertreffen.
Bulk-Zugriffe werden somit in den vorgestellten Tests nicht weiter betrachtet.
Auch schlechte Ergebnisse lieferte der Versuch, Variante 2 aus „Datensatzgröße“ (4.7.1.2) durchzuführen. Wurden einem Datensatz die Inhalte ganzer WAVDateien zugeordnet und stets Teile dieser Daten abgefragt, erzielte dies konstant
schlechtere Werte als mit Variante 1. Daher wird im Weiteren nur die Umsetzung
mit kleineren Datensatzgrößen betrachtet.
4.7.2.2 Speicherbedarf
Vor der Durchführung der Lesetests wurden die durch das Füllen mit Daten entstehenden Datenbankdateien auf ihre Größe untersucht. Es ergaben sich entsprechend der Zugriffsmethode und weiteren Konfigurationsmöglichkeiten die unterschiedlichsten Dateigrößen. Dies liegt darin begründet, dass manche Zugriffsmethoden (wie BTree) mehr Verwaltungsinformationen speichern als andere. Aber
auch die Seitengröße in Kombination mit der Größe eines Datensatzes kann zu
erheblichen Mehrverbrauch an Speicherplatz führen, wenn Seiten nur zu kleinen
Teilen mit Daten belegt sind.
Bestimmte Speicherarten disqualifizierten sich so schon durch den entstehenden Speicherbedarf. Bei einer Vergrößerung der Ursprungsdatenmenge um fünfzig oder mehr Prozent ist kein sinnvoller Einsatz abzusehen, gerade wenn die
Messwerte nicht zum Positiven verändert wurden. Die Größe der entstehenden
Datenbankdateien hängt von diesen Faktoren ab:
• Zugriffsmethode
• Seitengröße
• Menge der Daten pro Schlüssel
• Art der gespeicherten Daten - Daten der WAV-Dateien oder umgewandelte
Samples
Entsprechend dieser Faktoren ergaben sich die unterschiedlichsten Dateigrößen, wie in Tabelle 4.1 auf der nächsten Seite zu sehen. Basis für das Füllen der
Datenbank waren sechs WAV-Dateien mit einer Gesamtgröße von 30.8 MByte. Zu
beachten ist, dass hierbei auch die Verwaltungsdaten der Dateien inkludiert sind.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
109
Zugriffsmethode Seitengröße Daten/Schlüssel Datenart
[kByte]
[kByte]
BTree
4
128
WAV
Float
4
4.096
WAV
Float
64
512
WAV
Float
64
4.096
WAV
Float
Hash
64
512
WAV
Float
Recno
64
512
WAV
Float
Größe
[MByte]
65,0
54,9
41,1
51,3
32,2
43,9
41,2
164,1
39,5
80,1
32,2
43,9
Tabelle 4.1: Datenbank-Größen
Dagegen stehen Verwaltungsinformationen, wie Schlüssel oder Baumstruktur, in
den Datenbankdateien.
Zu vergleichen sind nun die original 30.8 MByte mit den Größen der entstandenen Datenbankdateien. Man sieht, dass im Extremfall über 160 MByte an
Daten entstanden, was mehr als das fünffache der geringst möglichen Dateigröße
entspricht. Bei einem Datenbestand von mehreren Gigabyte für Audioszenen ist
dementsprechend mit solch einer Konfiguration nicht mehr arbeitbar.
Auch Probleme bereiteten diverse Konfigurationen beim Füllen mit Daten.
Entsprechende Laderoutinen waren so langsam, dass sie mangels Fortschritt abgebrochen und somit der Testfall aufgegeben wurde. Anscheinend leiden manche
Zugriffsmethoden mit bestimmten Konfigurationen unter starken Geschwindigkeitsproblemen beim Füllen der Datenbank. Insbesondere beim Hash war dieses
Phänomen verbreitet. Ein Beispiel ist der Fall Hash mit 4 kByte Seitengröße und
128 Samples pro Schlüssel.
4.7.2.3 Testreihe 1
Die Performancetests starten mit der ersten Testreihe, welcher folgende Konfiguration des verwendeten Testrechners zugrunde lag:
R Pentium
R M, 1.8GHz
• CPU: Intel
Inv.-Nr.: 2005-06-01/071/IN99/2254
110
KAPITEL 4. AUDIODATEN
128 Samples/DS 512 Samples/DS 4.096 Samples/DS
BTree
9,04
34,80
11,12
Hash
—
21,66
80,64
Recno
13,73
29,49
12,79
Tabelle 4.2: Durchschnittszeit (ms) bei einer Seitengröße von 4 kByte
• Arbeitsspeicher: 512 MByte RAM
• Festplatte: 12 ms Zugriffszeit, 100 MBps, 4200 rpm
• Betriebssystem: SUSE Linux 9.1
• Dateisystem: Ext3, Seitengröße 4 kByte
Auf diesem Rechner wurden die ersten Tests zum Bestimmen der Lesezeiten
für Audiodaten aus einer Berkeley DB Datenbank getestet.
Testdurchgang: Zugriffsmethoden und S/DS bei 4 kByte Seitengröße Der
erste Test wurde mit minimaler Seitengröße durchgeführt, was der Blockgröße
des Dateisystems entspricht. Dies waren 4 kByte. Simuliert wurde das Lesen von
32 parallel aktiven Audioquellen. Dabei wurden 2.500-mal je 512 Samples pro
Quelle gelesen. Es interessierten bei gegebener Seitengröße die schnellste Zugriffsmethode sowie die beste Menge an Daten pro Datensatz.
In Tabelle 4.2 sind die Ergebnisse für die drei Zugriffsmethoden BTree, Hash
und Recno für unterschiedliche Datenmengen pro Datensatz dargestellt – letztere wurden mit 128, 512 und 4.096 Samples je Schlüssel untersucht. Die Daten
wurden im WAV-Format in der Datenbank gespeichert. Zu sehen ist jeweils die
Durchschnittszeit für eine Abfrage, welche entsprechend den Randbedingungen
unter 10 ms bleiben muss.
Das Ergebnis zeigt: nur eine Konfiguration kann diese Anforderung erfüllen.
Als schnellste Variante zeigt sich eindeutig der BTree, von der Konfiguration mit
512 Samples pro Datensatz abgesehen. Der Hash zeigt sich bei 4.096 S/DS weit
abgeschlagen, und auch Recno kann nicht überzeugen. Der Versuch mit 128 S/DS
wurde für den Hash nicht durchgeführt, da das Füllen der Datenbank schon unverhältnismäßig viel Zeit in Anspruch nahm.
Die Datenmenge pro Datensatz erscheint bei einer Größe von 128 Samples
optimal. Da die WAV-Dateien mit 24 Bit aufgezeichnet wurden, entspricht dies
384 kByte Daten pro Datensatz.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
BTree
Hash
Recno
111
128 Samples/DS 512 Samples/DS 4.096 Samples/DS
7,35
7,16
9,38
42,00
13,50
19,16
7,39
7,24
10,60
Tabelle 4.3: Durchschnittszeit (ms) bei einer Seitengröße von 64 kByte
Eine Verteilung der Messwerte ist in Darstellung 4.4 erkennbar. Die x-Achse
stellt die Abfragen dar, die y-Achse die Zeit in Millisekunden, welche zur Bearbeitung der Abfrage benötigt wurde. Erkennbar ist das häufige Auftreten von sehr
langsamen Antwortzeiten. Zum Teil geschieht dies, auch wenn auf der Darstellung nicht erkennbar, in kurzen aufeinander folgenden Abfragen.
Testdurchgang: Zugriffsmethoden und S/DS bei 64 kByte Seitengröße Der
nächste Test erfolgte mit maximaler Seitengröße, die derzeit auf 64 kByte beschränkt ist. Alle weiteren Parameter blieben unverändert zum vorherigen Szenario. Anhand dieses Tests ist der Einfluss der Seitengröße auf die Performance
erkennbar. Es zeigt sich (Tabelle 4.3), dass die Werte gegenüber dem Test mit
geringer Seitengröße in allen Fällen verbessert sind.
Bei dieser Konfiguration zeigen BTree und Recno ähnliche Ergebnisse. Da
die besten Ergebnisse bei einer Konfiguration von 512 S/DS erreicht wurde, spielen die Werte für 4.096 S/DS keine weitere Rolle. Der Hash ist wiederum weit
abgeschlagen und kann letztendlich als ungeeignet gesehen werden.
Bei der Seitengröße von 64 kByte zeigen sich, im Gegensatz zur Konfiguration
mit 4 kByte, Datenmengen für 512 Samples pro Datensatz als optimale Lösung.
Dabei sind die besten Testwerte einer Abfrage für 512 Samples immerhin 1.6 ms
besser als im 4 kByte-Fall. Dieses Ergebnis geht auch mit der Dokumentation von
Abbildung 4.4: 32 Soundquellen, 1.000 Abfragen
Inv.-Nr.: 2005-06-01/071/IN99/2254
112
KAPITEL 4. AUDIODATEN
BDB konform. Danach sollte ab einer bestimmten Größe der Datensätze die Seitengröße größtmöglich gewählt werden. Mit den gegebenen ca. 1,5 kByte Daten
pro Datensatz scheint diese Größe erreicht zu sein.
Erstes Fazit Die ersten Tests zeigten die Tendenz, dass die maximale Seitengröße zu wählen ist, um gute Ergebnisse zu erzielen. Des Weiteren überzeugte der
BTree als Zugriffsmethode sowie eine Datenmenge von 512 Samples pro Datensatz.
Jedoch waren die Ergebnisse grundsätzlich nicht überzeugend. Für 512 Samples und 32 Audioquellen waren im Idealfall noch über 7 ms Lesezeit vonnöten.
Bei geforderten 10 ms bleibt nicht mehr viel Spielraum, um 64 oder mehr Audioquellen zuverlässig auszulesen.
Für die weiteren Tests wurde daher auf ein schnelleres Testsystem ausgewichen, wo bessere Ergebnisse erzielt werden konnten.
4.7.2.4 Testreihe 2
Die weiteren Tests wurden auf einem Testsystem mit mehr Arbeitsspeicher und
schnellerer Festplatte durchgeführt. So konnten schnellere Lesezeiten erreicht und
die Anforderungen besser erfüllt werden. Gleichzeitig konnte untersucht werden,
ob bei veränderter Hardware die ersten Tendenzen bestätigt werden können. Ein
Einfluss des verwendeten Dateisystems konnte durch die Verwendung von ReiserFS untersucht werden, im Unterschied zum bisher eingesetzten Ext3.
• CPU: Intel Pentium 4 3.00 GHz
• Arbeitsspeicher: 1 GB RAM
• Festplatte: 80 GB, 8.5 ms Zugriffszeit, 7200 rpm, 100 MBps
• Betriebssystem: SUSE Linux
• Dateisystem: ReiserFS
Testdurchgang: 64 Audioquellen Einstieg ist ein Vergleich der Zugriffsmethoden, basierend auf einem Test mit 64 aktiven Audioquellen. Gelesen wurden in
2.500 Abfragen jeweils 512 Samples pro Quelle, d.h. ca. 3,5 MByte je Quelle.
Die Seitengröße war, wie in allen folgenden Tests, auf 64 kByte festgesetzt. Ein
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
512 WAVs/DS,
64 kByte Seitengröße
113
BTree
Hash
Recno
7,25
25,80
7,23
Tabelle 4.4: Durchschnittszeit (ms) bei 64 Audioquellen
Abbildung 4.5: 64 Soundquellen und Lesen von 10.000x512 Samples
Ausschnitt der Ergebnisse, wiederum in Form der Durchschnittszeit für eine Abfrage, wird in Tabelle 4.4 gezeigt.
Die Ergebnisse zeigen auch bei dieser Rechnerkonfiguration das gleiche Bild
wie in der ersten Testreihe: der BTree bietet zusammen mit Recno die besten Ergebnisse. Die gemessenen Werte allein sind noch nicht allzu aussagekräftig. Neben den eigentlichen Lesezeiten ist gerade auch die Verteilung (Abbildung 4.5)
der Lesezeiten von Bedeutung. Sind alle Abfragen gleich schnell, ist dies optimal und die Ergebnisse so hinnehmbar, wie gemessen. Jedoch zeigt sich in der
Verteilung eine deutliche Diskrepanz zwischen einzelnen Antwortzeiten. Zudem
kommt es zu Häufungen von Ausreißern. Dies macht die Vorsorge gegen solche
Ausreißer mittels einer Pufferung extrem schwer.
Vergleich des Datenformats: Floats vs. WAV Auch eine Größe, die beachtet
werden muss: die Art der Datenspeicherung. Speichert man die Daten im WAVFormat (entsprechend den WAV-Dateien) oder aber Samples, welche im FloatFormat dargestellt sind? Die Frage stellt sich, da die Audiodaten ursprünglich
im WAV-Format gespeichert sind, in IOSONO dagegen als Float-Werte weiter
verarbeitet werden.
Um die effizientere Variante zu finden, wurde auch dies in entsprechenden
Tests untersucht. Dafür wurden jeweils die gleichen Daten in den jeweiligen Formaten verglichen. Die WAV-Dateien wurden mit 24 Bit aufgezeichnet, d.h. pro
Sample sind 3 kByte Daten vonnöten. Im Vergleich dazu ergeben Samples im
Inv.-Nr.: 2005-06-01/071/IN99/2254
114
KAPITEL 4. AUDIODATEN
Float
512 Samples/DS
8,30
4.096 Samples/DS 10,36
WAV
7,25
7,79
Tabelle 4.5: Durchschnittszeit (ms) im Vergleich: Float und WAV
4.096 Floats/DS, 4 kByte Seitengröße
512 WAVs/DS, 64 kByte Seitengröße
4.096 WAVs/DS, 4 kByte Seitengröße
Cursor
9,12
7,25
7,79
Kein Cursor
9,98
7,45
9,68
Tabelle 4.6: Durchschnittszeit (ms) im Vergleich: Cursorzugriff
Float-Format auf dem getesteten System eine Größe von 32 Bit (4 kByte) pro
Sample. Der Vergleich zeigt, ob es günstiger ist:
• geringere Datenmengen abzuspeichern und diese nach dem Auslesen in
Float-Werte zu konvertieren oder
• größere Datenmengen abzuspeichern und dabei die Konvertierungszeit zu
sparen
Es ist zu erwarten, dass die Speicherung im WAV-Format die bessere Wahl darstellt, da bei diesem Vergleich die Zugriffe auf den Externspeicher entscheidend
für die Performance sein sollten.
Tabelle 4.5 zeigt einen Ausschnitt aus den Ergebnissen, die beim Lesen von
je 512 Samples in 2.500 Abfragen erzielt wurden. Die Seitengröße wurde auf
64 kByte festgesetzt. Simuliert wurden 64 Audioquellen.
Resultat: das Abspeichern im WAV-Format zeigt wie erwartet die schnelleren
Antwortzeiten. Damit ist es effizienter, weniger Daten zu speichern und diese erst
im Nachhinein umzuwandeln, als den umgekehrten Weg zu gehen.
Einfluss eines Cursors Neben verwendeter Zugriffsmethode und gewählter Datenverteilung spielt auch die Art des Datenzugriffs eine Rolle bei der Performance. Diesbezüglich wird der Einfluss eines Cursors aufs Zugriffsverhalten untersucht. Dafür wurden Datenbanken sowohl mit als auch ohne Cursor abgefragt. Da
die Daten sukzessive ausgelesen werden, ist eine Geschwindigkeitssteigerung mit
Cursor zu erwarten, da dies dem Prinzip des Cursorzugriffs entgegenkommt.
Mit dem Beibehalten der Testdurchführung der letzten Versuche zeigen die
erzielten Ergebnisse (Tabelle 4.6), dass ein cursorunterstützter Zugriff jenen ohne
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
512 Floats/DS, 64k Seitengröße
4096 Floats/DS, 4k Seitengröße
115
64 kByte Cache
8,22
9,12
256 MByte Cache
8,56
10,87
Tabelle 4.7: Durchschnittszeit (ms) abhängig von der Cachegröße
Cursor übertrifft. Somit ist, wie schon erahnt, ein Cursor einzusetzen, um optimale
Performance zu erzielen.
Auswirkung der Cachegröße Ziel dieses Versuches ist es, den Einfluss der Cachegröße auf das gegebene Datenbankszenario zu testen. Dies soll zeigen, ob der
Cache einen positiven Einfluss auf das Auslesen von Daten hat. Jedoch wird schon
jetzt kein bzw. kaum Einfluss erwartet, da die von BDB implementierte Cachestrategie ein Least Recently Used4 (LRU) darstellt. Dies optimiert den Zugriff auf
schonmals gelesene Daten, da die häufigsten Zugriffe im Cache gehalten werden.
Da in IOSONO Daten chronologisch, und zumeist nur einmalig benötigt werden,
ist kein Erfolg dieser Cachestrategie zu erwarten.
Um die Cachebedeutung zu erkennen, wurden sowohl die minimalste, als auch
eine relativ große Cachegröße gewählt, um Tendenz und Ergebnis zu ermitteln.
Die Tests wurden mit der Zugriffsmethode BTree durchgeführt, und wiederum in
2.500 Abfragen Daten für je 512 Samples gelesen.
Die Tabelle 4.7 zeigt, dass:
a) die Cachegröße, wenn auch abhängig von z.B. Seitengröße und Anzahl Daten pro Datensatz, die Performance nicht positiv beeinflussen kann sowie
b) eine große Cachegröße noch schlechtere Ergebnisse bedeutete als eine kleine
Somit brachten Änderungen der Cachegröße keine spürbare Geschwindigkeitssteigerung.
Zugriffsmethode Schon in den vorherigen Testreihen hat sich der BTree als
beste Zugriffsmethode herausgestellt. Zur Vervollständigung wird nochmals die
schnellste Zugriffsmethode mittels eines weiteren Tests bestimmt. Dafür sind zwei
verschiedene Konfigurationen angelegt. Zum Test stand eine Datenbank mit Daten
4
Bei LRU werden lange nicht benutzte Einträge verdrängt, wenn der dem Cache zur Verfügung
stehende Speicherplatz nicht mehr ausreicht
Inv.-Nr.: 2005-06-01/071/IN99/2254
116
KAPITEL 4. AUDIODATEN
512 S/DS
BTree
7,15
Hash
13,50
Recno
7,24
4.096 S/DS
9,38
19,16
10,60
Tabelle 4.8: Vergleich der Zugriffsmethoden, abhängig von S/DS
für 512 Samples pro Datensatz sowie mit Daten für 4.096 Samples pro Datensatz.
Die Durchschnittszeiten bei 2.500 Abfragen sind in Tabelle 4.8 aufgeführt.
Der BTree als Zugriffsmethode zeigt die besten Ergebnisse. Zwar kann Recno
teilweise mithalten, jedoch ist dort die Einschränkung bzgl. der Schlüsselwahl negativ einzubeziehen (siehe 4.7.1.3). Der Hash jedoch ist keineswegs in der Lage,
mit den anderen Zugriffsmethoden mitzuhalten. Auch zeigt sich erneut, dass Daten für 512 Samples die geeignetste Option darstellen.
Vorläufiges Fazit In diversen weiteren Tests mit anderen Datenmengen, Seitengrößen und Cachegrößen konnten keine besseren Ergebnisse erzielt werden als
die hier vorgestellten. Die aufgezeigten Tendenzen wurden dagegen bestätigt.
4.7.3 Auswertung der Ergebnisse
Dieser Abschnitt fasst die Erkenntnisse zusammen, die in den durchgeführten
Testreihen erlangt wurden. Die daraus entstandene beste Konfiguration von BDB
ist im Folgenden aufgezeigt.
4.7.3.1 Beste Konfiguration
• Zugriffsmethode: BTree. Auch unter Benutzung von Integern als Schlüssel zeigt die Recno-Methode keine Vorteile. Der Hash brachte ebenfalls
schlechtere Ergebnisse. Somit kosten die erweiterten Verwaltungsinformationen des BTree offenbar weniger Geschwindigkeit, als die chronologischen Schlüssel, welche Lokalität des Schlüsselzugriffs ermöglichen, einbringen.
• Ein Datensatz enthält Daten für 512 Samples. Weitere Möglichkeiten wie
128 oder 4.096 Samples pro Schlüssel resultierten nicht in verbesserten oder
langsameren Antwortzeiten.
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
117
• Seitengröße ist 64 kByte. Die Tests zeigten, dass die maximal mögliche Seitengröße von 64 kByte die besten Ergebnisse erzielte.
• Cachegröße ist unbedeutend. Unter normalen Umständen ist die Cachegröße ein bestimmender Faktor beim Einsatz eines Datenbanksystems. In dem
hier benötigten Szenario jedoch, das meistens einem Kaltstart der Datenbank und einem nur einmaligen Lesen eines Datensatzes entspricht, spielt
der Cache keine Rolle. Dieser enthält meistens nur Daten, welche während
des nächsten Aufrufs nicht benötigt werden. Somit hatte die Cachegröße
keinen Einfluss auf die Testergebnisse und kann als unbedeutend eingestuft
werden.
• Für den Datenzugriff wird ein Cursor benutzt. Der Umstand, dass die Daten
in chronologischer Folge abgefragt werden, unterstützt die Funktionsweise
eines Cursors, welcher über alle Datensätze einer Datenbank iteriert. Somit
ist es keine Überraschung, dass ein Cursorzugriff den Standardzugriff geschlagen hat. Ein Bulk-Zugriff wiederum zeigte keinerlei Vorteile. Eher das
Gegenteil, ein verlangsamter Zugriff, war das Ergebnis.
4.7.3.2 Fazit
Das Ergebnis der Untersuchungen ist auch mit der besten Konfiguration folgendes: mit Berkeley DB als Verwaltungssystem für die Audiodaten sind die Echtzeitanforderungen nicht immer erfüllbar. Während die durchschnittliche Zugriffszeit den Anforderungen entspricht, treten z.T. gebündelt starke Ausreißer auf, welche selbst durch Puffer kaum ausgeglichen werden können. Die Ausreißer gehen
in den Bereich von über 100 ms, und sind teilweise von Abfragen mit 20, 30 oder
mehr ms umgeben. An solchen Stellen wäre selbst mit großem Puffer die Echtzeitrealisierung unsicher, da der Puffer zwischen den Ausreißern nicht genügend
Füllzeit hat. Dazu sind die Antwortzeiten mit niedrigen Werten zu selten.
Daher muss die Feststellung sein, dass Berkeley DB für die Verwaltung der
Audiodaten nicht geeignet ist. Schlussfolgerung ist damit, dass eine alternative
Speicherungsform gefunden werden muss. Darauf wird im nächsten Abschnitt
näher eingegangen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
118
KAPITEL 4. AUDIODATEN
Abbildung 4.6: 64 Soundquellen, 10.000x512 Samples gelesen
4.8 Verwaltung über integrierte Audiodatei
Dieser Abschnitt widmet sich der zweiten angedachten Möglichkeit zur Verwaltung der Audiodaten: in Form einer großen Datei. Nachdem das Layout derselben
entworfen wurde, sind ebenfalls diverse Tests durchgeführt worden. Diese zeigen
im Vergleich zu BDB sowie zur aktuellen Systemimplementation, welche Performance die Dateilösung bieten kann.
Ansatz hierfür ist eine Datei, in welcher alle Daten für die Audioausgabe einer
Szene abgelegt werden. Zu beachten sind dabei sowohl zeitlich korrekte Reihenfolge der Datenablage von Audiosamples, als auch Einordnung anhand der zugehörigen Quelle – die Parallelität von Quellen spielt wiederum eine Rolle. Nur so
kann eine korrekte Audioausgabe mit Zeit- und Kanalbezug erfolgen.
Für die Testdurchführung wurde eine Datei erzeugt und mit Daten für Samples
aus diversen Audiodateien gefüllt. Anschließend wurde eine konstante Anzahl an
Samples ausgelesen. Simuliert wurde dabei das Auslesen von Daten für 32 bzw.
64 gleichzeitig aktive Quellen. Damit wurden jeweils Daten für 32×512 Samples
bzw. 64×512 Samples pro Abfrage ausgelesen. Dies wurde mit 1.000 und 10.000
Abfragen an Dateien bis zu ca. 1,5 GB Größe untersucht.
4.8.1 Testergebnisse
Das Diagramm 4.6 zeigt die erzielten Testergebnisse für 64 Quellen und 10.000
Abfragen. Die Tests wurden auf dem gleichen Rechner durchgeführt wie Testreihe
2 bei Berkeley DB (siehe 4.7.2.4). Bei einer Gesamtantwortzeit von 53 s ergibt
sich eine Lesezeit von 5,3 ms pro 512 Samples, was die geforderten 10 ms deutlich
unterbietet. Zudem ist die maximale Antwortzeit mit 76 ms nur halb so groß wie
die 150 ms der Datenbanklösung.
Sofort erkennbar ist, dass die Verteilung der Lesezeiten nicht so zufällig erInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
119
scheint wie bei der Datenbanklösung. Die Ergebnisse sind dabei innerhalb der
Anforderungen. Ein Puffer in vernünftiger Größe kann die Ausreißer gut ausgleichen. Insbesondere, da zwischen zwei Ausreißern Zeit zum Neupuffern vorhanden
ist.
Zum Vergleich werden die Ergebnisse dieses Tests denen von Berkeley DB
sowie der aktuellen IOSONO-Implementierung gegenübergestellt (Tabelle 4.9).
Eindeutig erkennbar sind, gerade bei den Tests mit 64 Audioquellen, die besten
Ergebnisse auf Seiten der integrierten Datei.
4.8.1.1 Evaluierung
Die Dateilösung lässt weniger Spielraum bei Konfigurationen als Berkeley DB.
Jedoch zeigten sich in der gewählten Anordnung der Daten Leseergebnisse, welche die von BDB als auch die des aktuellen Systems deutlich schlagen. Dies war
die Voraussetzung, um eine Lösung zur Speicherung der Audiodaten als erfolgreich anzusehen. Die Dateilösung hat diese Voraussetzung erfüllt und wird daher
in Zukunft die Speicherung der Audiodaten für IOSONO übernehmen.
Somit wird im Weiteren die Umsetzung der Integration der neuen Speicherung
in das IOSONO-System erläutert. Nach einer detaillierten Vorstellung der neuen
Datenstruktur wird kurz auf die Erzeugung dieser Struktur eingegangen.
4.8.2 Die Datenstruktur
Dieser Abschnitt behandelt die zu entwickelnde Datenstruktur der Datendatei.
Wie sich gezeigt hat, sollten die Daten für optimale Performance in der Auslese- und Abspielreihenfolge gespeichert werden. Die Daten werden im WAVFormat abgespeichert, d.h. so, wie sie auch in den originalen WAV-Dateien vorliegen. Dabei werden die Daten in der Anordnung gespeichert, wie sie zur Abspielzeit benötigt werden. So kann die Datei im Normalfall chronologisch, ohne
Durchschnittszeit
Maximum
32 Quellen 64 Quellen 32 Quellen 64 Quellen
IOSONO Aktuell
10,9
25,1
628,2
1.375,0
Berkeley DB
3,7
7,2
75,7
150,6
Datei neu
2,5
5,3
78,0
76,4
Tabelle 4.9: Zeitaufwand (ms) für verschiedene Implementierungen
Inv.-Nr.: 2005-06-01/071/IN99/2254
120
KAPITEL 4. AUDIODATEN
Abbildung 4.7: Dateilayout
Sprünge, ausgelesen werden. Dies ist wichtig für die Performance, um unnötige Bewegungen innerhalb der Datei und auch auf der Festplatte zu vermeiden.
Das chronologische Auslesen entspricht dem Standardverhalten des IOSONOSystems, wo die normale Wiedergabe der Regelfall ist.
Bei der Erarbeitung der Struktur ist die Abfragecharakteristik der Daten zu
beachten. Was tun wenn keine Daten vorliegen? Entweder wie „richtige“ Daten
komplett abspeichern – dies geht einher mit unnötigem Datenaufkommen. Zweite,
und zu bevorzugende Variante: Leerdaten nicht abspeichern und stattdessen den
zugehörigen Bereich als leer markieren.
Weiterhin ist zu beachten, dass oftmals nur ein Teil der Gesamtzahl von Kanälen aktiv ist. In diesem Fall macht es keinen Sinn, Daten für die inaktiven Kanäle
abzuspeichern. Daher scheint es sinnvoll, sich für die Szene zu vermerken, wann
welche Slots aktiv sind. Dementsprechend werden nur zu aktiven Slots Daten abgespeichert.
Um diese und weitere benötigte Verwaltungsinformationen zu sichern wird
die Datei in zwei Bereiche eingeteilt: die Verwaltungsdaten sowie die eigentlichen
Audiodaten. Die Aufteilung wird in Abbildung 4.7 dargestellt.
Für die Verwaltung werden spezielle Dateiheader eingeführt. Entwickelt werden Formate für einen Haupt- und mehrere Teilheader pro Datei. Der Inhalt dieser
Header gestaltet sich wie folgt:
Hauptheader
• Maximale Anzahl an Kanälen
• Anzahl an Bits pro Sample
Die Informationen des Hauptheaders gelten für die komplette Datei. Mit der
Anzahl an Bits pro Sample wird beim Auslesen erkannt, wie viele Daten für ein
Inv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
121
Sample ausgelesen werden. Dies wird im Normalfall eine Größe von 24 Bit sein,
was jedoch variieren kann. Die maximale Anzahl an Kanälen zeigt, wie viele
Kanäle maximal parallel aktiv sein können. Maximal daher, da nicht immer alle Kanäle gleichzeitig aktiv sein werden. Über die Aktivität der jeweiligen Kanäle
in Abhängigkeit von der Zeit enthalten die Teilheader weitere Informationen. Der
Maximalwert wird jedoch in der Anwendung benötigt, um die entsprechenden
Datenstrukturen zur Aufnahme der Audiodaten passend dimensionieren zu könne.
Teilheader
• Aufzählung der aktiven Slots
• Offset der zugehörigen Datensektion
• Länge der Datensektion
• Info über Leerdaten
Jeder Teilheader verweist auf einen zugehörigen Datenbereich innerhalb der
Datei. Dafür wird der Offset-Wert genutzt, welcher die Position des Bereiches in
Bytes angibt. Mit der Länge der Datensektion wird angegeben, für welchen Datenbereich der Header Informationen enthält. Die Zahl der aktiven Kanäle gibt an,
wie viele der im Hauptheader festgelegten Kanäle zum Gültigkeitszeitpunkt des
Headers aktiv sind. Mit der Info über Leerdaten kann man Zeitpunkte definieren,
in denen für bestimmte Kanäle keine Daten verfügbar sind.
Die Header werden vor Beginn des Abspielvorgangs ausgelesen und die enthaltenen Informationen vermerkt. So ist jederzeit schneller Zugriff auf diese Daten möglich. Dies ist eine Voraussetzung, um jederzeit schnell an eine gewünschte
Abspielposition zu navigieren.
4.8.3 Erzeugung
Die Erzeugung der Audiodatei kann vorerst über die vorhandene Systemimplementierung ermöglicht werden. Dort werden während des Abspielens einer Szene
alle beteiligten Audiodaten ausgelesen und weiterverarbeitet. Dies ist der Einstiegspunkt für die Dateierzeugung. Anstatt die ausgelesenen Daten an die folgenden Systemkomponenten weiterzuleiten, werden diese an ein neu zu implementierendes Interface gesendet. Dieses nimmt die einkommenden Daten und wandelt
Inv.-Nr.: 2005-06-01/071/IN99/2254
122
KAPITEL 4. AUDIODATEN
Abbildung 4.8: Dateierzeugung
diese so um, dass sie in das Dateiformat passen. So werden diese Daten in die
Datei geschrieben. Mittels des vorhandenen Wissens aus der Szenenbeschreibung
und dieser Daten kann zudem die Sektion mit den Steuerinformationen der Datei
erzeugt werden.
Das Aufteilen der Datenbereiche der Datei ergibt sich anhand der aktiven
Kanäle laut Szenenbeschreibung. Datenbereiche definieren sich aufgrund der Änderung in den aktiven Kanälen. Werden zu einem Zeitpunkt Kanälen inaktiv oder
andere aktiv, beginnt ein neuer Datenbereich mit Audiodaten für die zum entsprechenden Zeitpunkt aktiven Kanäle. Nach diesem Prinzip gliedert sich die Datei in
mehr oder weniger viele logische Teilbereiche, wie in Abbildung 4.8 gezeigt. Dort
sind im oberen Bereich Kanäle dargestellt, welche in bestimmten Intervallen (ausgefüllt dargestellt) aktiv sind, d.h. Audiodaten enthalten und wiedergeben. Nach
der Erstellung des Dateilayouts ergeben sich daraus sechs Datenbereiche, jeder
mit einer individuellen Konfiguration an aktiven Kanälen.
Langfristig steht das Ziel, die Erzeugung der Datei an das Prinzip der Ausgabeschedules anzugliedern. Wenn anhand dieser die Datenverteilung berechnet
werden kann, ist über dieses Wissen die Dateierzeugung regelbar.
4.8.4 Integration
Die Integration der neuen Dateilösung erfordert keine großen Änderungen der
Leseschnittstelle. Wie schon in 4.2 erläutert, sind die Klassen DiskThread und
DiskThreadScheduler anzupassen. Das in diesen implementierte anforderungsspezifische Auslesen aus einem Pool von Dateien entfällt. Dafür wird chronoInv.-Nr.: 2005-06-01/071/IN99/2254
KAPITEL 4. AUDIODATEN
123
logisch aus nur noch einer Datei ausgelesen.
Die gelesenen Daten werden entsprechend der Informationen im Dateiheader
auf die verschiedenen Slots verteilt, über welche die Daten zum Renderer übertragen werden. Das Slot-Konzept (4.6.1) wird somit nicht angetastet, wodurch alle
weiteren Aktionen wie bisher durchgeführt werden können.
4.8.5 Evaluierung
Die Wahl einer Datei für die Speicherung der Audiodaten bietet, wie durch die
Tests gezeigt, die beste Performance für das IOSONO-System. Jedoch stellt sie
praktisch eine statische Lösung, mittels Vorrendern der Audiodaten, dar. Ein Vorteil des IOSONO-Systems, die Veränderung von Parametern zur Abspielzeit, fällt
damit aus. Die Datei muss bei jeder Änderung neu erstellt werden. Um den dafür notwendigen Aufwand zu verringern, ist eine Aufteilung der Datei in kleinere
logische Bestandteile möglich. Dann müssen nur die betroffenen Bestandteile verändert und neu berechnet werden.
Eine Aufteilung der Datei kann weiterhin nötig sein, wenn die Grenzen des
Dateisystems erreicht sind. Da z.T. die obere Grenze für Dateien bei 4 GB liegt,
muss auch die erzeugte Datei diese einhalten. Gelingt dies nicht, muss der Dateiinhalt auf mehrere Dateien aufgeteilt werden. Hier besteht die Wahl zwischen zwei
Vorgehensweisen. Entweder, man gibt jeder Datei die entsprechenden Header bei,
oder nur die erste Datei erhält alle Header und die weiteren Dateien enthalten nur
Audiodaten.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Kapitel 5
Fazit und Ausblick
Diese Arbeit beschäftigte sich mit der Verwaltung spatio-temporaler Daten für die
Wellenfeldsynthese. Eingeteilt in die Datenarten Meta- und Audiodaten, wurden
Lösungen und Ansätze für grundlegende Fragen der Datenverwaltung gefunden.
Die Metadaten sind nun in ein komfortables Datenverwaltungssystem integriert. Dies ermöglicht es mehreren Benutzern, konsistent Daten zu speichern und
zu verwalten. Jedoch kann immer nur ein Nutzer gleichzeitig mit denselben Daten
arbeiten, um diese konsistent zu halten.
Daher bleibt ein umfangreiches Thema noch offen: die Mehrbenutzerunterstützung. Diese ist entsprechend zu integrieren. Eine denkbare Lösung ist die Installation eines Client-Server Systems, welches den Nutzern gegenseitige Änderungsverfolgung und simultanes Arbeiten an gleichen Daten ermöglichen kann.
Im Sinne dieser Entwicklung sind auch lange Transaktionen für eine Mehrbenutzerumgebung zu implementieren, da diese im Moment nur für einen Nutzer
mittels des Versionierungssystems umgesetzt sind. Auch für mehrere Clients lässt
sich das Versionierungssystem als Grundlage nutzen, wenn es z.B. um Arbeitsbereiche erweitert wird. Die genaue Umsetzung ist eine der offenen Fragen.
Weiterhin zu lösen ist die Thematik der Konsistenz von Meta- und Audiodaten. Dies betrifft zum einen die Überwachung der physischen Speicherung der
Audiodaten. So ist mittels Referenzkontrolle über Löschung oder Erhaltung referenzierter Audiodaten zu entscheiden. Tiefer greift die Konsistenzkontrolle der
aufgestellten Szenen in Verbindung mit den referenzierten Daten. Die Ausgabereihenfolge von Audiodaten für Audioszenen ist in bestimmten Bedingungen zu
fassen. Ein Ausgabeschedule sorgt für die korrekte Bereitstellung der Daten, während diese Bedingungen mittels geeigneter Algorithmen auf Konsistenz zu überprüfen sind. Ansätze hierfür bietet die Diplomarbeit von Thomas Schröder [29].
Inv.-Nr.: 2005-06-01/071/IN99/2254
126
KAPITEL 5. FAZIT UND AUSBLICK
Die dort vorgestellten Konzepte sind über geeignete Mittel in das Datenverwaltungssytem der Metadaten zu integrieren.
Auf Seiten der Audiodaten wurde anhand von umfangreichen Tests eine Speicherung der Daten in einer Datenbank verworfen. Die erzielten Ergebnisse hielten
den Anforderungen nicht stand. Stattdessen wurde ein Modell zur Speicherung der
Audiodaten in komplexen Dateien entwickelt. Es gilt, dieses umzusetzen sowie im
realen Einsatz auf seine Leistungsfähigkeit zu überprüfen. Auch gilt es, neben der
Wiedergabe eine funktionierende Lösung für den Aufnahmeprozess der Dateien
zu entwerfen. Großer Aufwand zum Neu-Rendern der Datei bei Änderungen ist
zu vermeiden. Auch kann über eine Lösung zum Rendern der Datei während des
Aufnahmeprozesses der Audiodaten nachgedacht werden.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Anhang A
XQuery-Funktionen
A.1 Funktion zum Abfragen einer bestimmten Dokument-Version
declare function local:myFunc($el as item(),
$time as xs:integer) as item()*
{
typeswitch($el)
case document-node() return
document {
for $r in $el/child::element()
return local:myFunc($r, $time)
}
case element() return
if( not(empty($el/xmtsaw:timestamp)) and
( every $vt in $el/xmtsaw:timestamp satisfies
( $vt/@vtBegin > $time or
$vt/@vtEnd <= $time )))
then ()
else
element {node-name($el)}
{
for $a in $el/@* return
attribute {node-name($a)} {data($a)},
if( empty($el/*) )
Inv.-Nr.: 2005-06-01/071/IN99/2254
128
ANHANG A. XQUERY-FUNKTIONEN
then ()
else
(
for $ta in $el/xmtsaw:timeVaryingAttribute
where ( $ta/@vtBegin <= $time and
( empty($ta/@vtEnd) or
$ta/@vtEnd > $time ))
return
attribute {$ta/@name} {$ta/@value},
for $s in $el/child::node()
where( local-name-from-QName(
node-name($s))
!= \"timestamp\"
and local-name-from-QName(
node-name($s))
!= \"timeVaryingAttribute\")
return local:myFunc($s, $time)
)
}
default return $el
};
for $a in doc("dbxml:/containerName/docId")/*
return local:myFunc($a, version);
Quelltext A.0: Abfrage eines Dokumentes
A.2 Funktionen zur Bestimmung von Versionsdifferenzen
declare function local:getId($el as element() )
as xs:string*
{
let $n:= name($el)
return if( $n = "body" or
Inv.-Nr.: 2005-06-01/071/IN99/2254
ANHANG A. XQUERY-FUNKTIONEN
$n
$n
$n
$n
=
=
=
=
129
"head" or
"timecode" or
"spamixCfg" or
"topLayout")
then ()
else if( not( empty($el/@dbNodeId)) )
then
"dbNodeId"
else if( $n = "region" )
then
"regionName"
else if( $n = "additionalSrc" )
then
"src"
else if( $n = "spamixSrc" )
then
"ref"
else if( $n = "audio" )
then
"id"
else
"id"
};
Quelltext A.1: Bestimmung des als PID funktionierenden Attributes zum
Element
declare function local:getIdVal($el as element() )
as xs:string*
{
let $n:= name($el)
return if( $n = "body" or
$n = "head" or
$n = "timecode" or
$n = "spamixCfg" or
$n = "topLayout")
then ()
Inv.-Nr.: 2005-06-01/071/IN99/2254
130
ANHANG A. XQUERY-FUNKTIONEN
else if( not( empty($el/@dbNodeId)) )
then
string($el/@dbNodeId)
else if( $n = "region" )
then
string($el/@regionName)
else if( $n = "additionalSrc" )
then
string($el/@src)
else if( $n = "spamixSrc" )
then
string($el/@ref)
else if( $n = "audio" )
then
string($el/@id)
else
string($el/@id)
};
Quelltext A.2: Bestimmung des Wertes des PID-Attributes zu gegebenem
Element
declare function local:getEl($parent as element()*,
$el as element() ) as element()*
{
let $n:= name($el)
for $x in $parent/*[name() = $n] return
if( $n = "body" or
$n = "head" or
$n = "layer" or
$n = "timecode" or
$n = "spamixCfg" or
$n = "topLayout" )
then
$x
else if( count($el/@dbNodeId) != 0 and
count($x/@dbNodeId) != 0 and
Inv.-Nr.: 2005-06-01/071/IN99/2254
ANHANG A. XQUERY-FUNKTIONEN
131
string($x/@dbNodeId) =
string($el/@dbNodeId))
then
$x
else if( $n = "region" and
string($x/@regionName) =
string($el/@regionName) )
then
$x
else if( $n = "additionalSrc" and
string($x/@src) = string($el/@src) )
then
$x
else if( $n = "spamixSrc" and
string($x/@ref) = string($el/@ref) )
then
$x
else if( $n = "audio" and
count($x/@id) != 0 and
count($el/@id) != 0 and
string($x/@id) = string($el/@id) )
then
$x
else if( count($el/@id) != 0 and
count($x/@id) != 0 and
string($x/@id) = string($el/@id) )
then
$x"
else ()
}
Quelltext A.3: Ermittelt für Eltern-Element das Kind mit gleichem PID-Wert wie
gegebenes Vergleichselement
declare function local:getAttributes(
$oldEl as element()*, $el as element(),
$path as xs:string) as element()
Inv.-Nr.: 2005-06-01/071/IN99/2254
132
ANHANG A. XQUERY-FUNKTIONEN
{
let $a:= ""
return insert-before(
for $x in $el/@*
let $oldAttr := $oldEl/@*[name()=name($x)]
return if( count($oldAttr)=0 )
then
<newAttrib>
<path>{$path}</path>
<name>{name($x)}</name>
<value>{data($x)}</value>
</newAttrib>
else if( data($oldAttr) != data($x) )
then
<changed>
<path>{$path}</path>
<name>{name($x)}</name>
<oldVal>{data($oldAttr)}</oldVal>
<newVal>{data($x)}</newVal>
</changed>
else ()
, 0,
for $x in $oldEl/@*
return
if( count($el/@*[name() = name($x)]) = 0 )
then
<deletedAttrib>
<path>{$path}</path>
<name>{name($x)}</name>
<value>{data($x)}</value>
</deletedAttrib>
else ()
)
};
Quelltext A.4: Liste aller neuen, veränderten und gelöschten Attribute zu
gegebenem Element bestimmen
Inv.-Nr.: 2005-06-01/071/IN99/2254
ANHANG A. XQUERY-FUNKTIONEN
133
declare function local:myFunc($el as element(),
$elOld as element()*, $p as xs:string) as element()*
{
for $c in $el/*
let $old := local:getEl($elOld, $c),
$loc := if(empty(local:getId($c)))
then
concat($p, "/xmtsaw:", name($c))
else
concat($p, "/xmtsaw:", name($c), "[@",
local:getId($c), "=",
local:getIdVal($c), "]")
return
if( name($c) = "timestamp" or
name($c) = "timeVaryingAttribute")
then ()
else
if( count( $old)=0 )
then
<new>
<location>{$p}</location>
<path>{$loc}</path>
<content>{$c}</content>
</new>
else
insert-before(<element>{$loc}</element>, 0,
insert-before(
local:getAttributes($old, $c, $loc),
0, local:myFunc($c, $old, $loc) ))
};
for $a in doc("dbxml:/containerName/new_doc")/*
let $b := doc("dbxml:/containerName/current_doc")/
return local:myFunc($a, $b, "")
Quelltext A.5: Bestimmung der Differenzen zwischen zwei XML-Dokumenten
Inv.-Nr.: 2005-06-01/071/IN99/2254
Literaturverzeichnis
[1] CVS. https://www.cvshome.org/.
[2] Cyclic RCS page. https://www.cvshome.org/cyclic/cyclic-pages/rcs.html.
[3] Cyclic SCCS page. https://www.cvshome.org/cyclic/cyclic-pages/sccs.html.
[4] Toshiyuki Amagasa, Masatoshi Yoshikawa, und Shunsuke Uemura. A Data
Model for Temporal XML Documents. In DEXA ’00: Proceedings of the
11th International Conference on Database and Expert Systems Applications, Seiten 334–344, London, UK, 2000. Springer-Verlag.
[5] Peter Batty und Richard G. Newell. Technical Paper 8: GIS Databases are
Different. Dez 1998.
[6] Bill Beauregard. Oracle Database 10g Workspace Manager Overview.
Oracle Corporation, Nov 2003.
[7] Sandra Brix, Frank Melchior, Thomas Roder, Stefan Wabnik, und Christian
Riegel. Authoring Systems for Wave Field Synthesis Content Production. In
115th Audio Engineering Society Convention, New York, Okt 2003. Audio
Engineering Society.
[8] S. Chien, V. Tsotras, und C. Zaniolo. A Comparative Study of Version Management Schemes for XML Documents, 2000.
[9] Faiz Currim, Sabah Currim, Curtis E. Dyreson, und Richard T. Snodgrass. A
Tale of Two Schemas: Creating a Temporal XML Schema from a Snapshot
Schema with tXSchema. In EDBT, Seiten 348–365, 2004.
[10] Curtis E. Dyreson. Observing Transaction-Time Semantics with TTXPath.
In WISE (1), Seiten 193–202, 2001.
Inv.-Nr.: 2005-06-01/071/IN99/2254
LITERATURVERZEICHNIS
135
[11] Fraunhofer Institut Digitale Medientechnologie. Klangfeldsynthese, Jan
2004. www.idmt.fraunhofer.de/presse/textarchiv/produktinformation/ IOSONObasicdeutsch.pdf.
[12] D. Gao und R. T. Snodgrass. Syntax, Semantics, and Query Evaluation of
the tXQuery Temporal XML Query Language, Mär 2004.
[13] John Robert Gardner und Zarella L. Rendon. XSLT & XPath - A Guide to
XML Transformations. Prentice Hall PTR, New Jersey, USA, 2002.
[14] F. Grandi und F. Mandreoli. The Valid Web: it’s Time to Go, 1999.
[15] Luis Gravano, Panagiotis G. Ipeirotis, H. V. Jagadish, Nick Koudas, S. Muthukrishnan, und Divesh Srivastava. Approximate String Joins in a Database
(Almost) for Free. In VLDB 2001, Seiten 491–500, 2001.
[16] Stephan Grimm. Unscharfer Vergleich von Produktnamen auf StringBasis unter Zuhilfenahme von Kontextinformationen im Rahmen eines
eCommerce-Projektes. Diplomarbeit, Fachhochschule Karlsruhe, . .
[17] Andreas Heuer und Gunter Saake. Datenbanken – Konzepte und Sprachen,
Kapitel 12.1. MITP-Verlag, Bonn, 2000.
[18] Thomas Höss und Tobias Rieck. WAV-Audio-Format. Projekt im Fach Multimedia, Jul 2000.
[19] Volker Janzen. XML und Zeit - Ein vergleichender Überblick. Feb 2004.
[20] Markus Kalb, Kerstin Schneider, und Günther Specht. T-XPath: ein zeitliches Modell für XML-Datenbanken. In BTW, Seiten 157–166, 2003.
[21] Wolfgang Lehner und Harald Schöning. XQuery – Grundlagen und fortgeschrittene Methoden. dpunkt.verlag GmbH, Heidelberg, 2004.
[22] Amelie Marian, Serge Abiteboul, Gregory Cobena, und Laurent Mignet.
Change-centric management of versions in an XML warehouse. In The
VLDB Journal, Seiten 581–590, 2001.
[23] Didier Martin, Mark Biberck, und Michael Kay. XML Professionell, Seiten
82–84. MITP-Verlag, Bonn, 2000.
[24] Frank Melchior. Untersuchung der Einsatzmöglichkeiten der Wellenfeldsynthese im Kino. Diplomarbeit, Technische Universität Ilmenau, Aug 2003.
Inv.-Nr.: 2005-06-01/071/IN99/2254
136
LITERATURVERZEICHNIS
[25] Katrin Münnich. Untersuchung und Implementierung von Speicher- und
Übertragungsformaten für Mischwerkzeuge der Wellenfeldsynthese. Diplomarbeit, Technische Universität Ilmenau, Sep 2003.
[26] Michael A. Olson, Keith Bostic, und Margo Seltzer. Berkeley DB. Sleepycat
Software, Inc.
[27] Gunter Saake, Ingo Schmidt, und Can Türker. Objektdatenbanken. International Thomson Publishing, 1997.
[28] Steve Sarette. Getting Started with Berkeley DB XML for C++. Sleepycat
Software, Inc., Jan 2005.
[29] Thomas Schröder. Effiziente Überprüfung von Ausgabebedingungen in einem Multimedia-Datenbanksystem. Diplomarbeit, Technische Universität
Ilmenau, Mai 2005.
[30] Sleepycat Software, Inc. Berkeley DB Reference Guide, Jan 2005.
[31] Paul A. Tipler. Physik, Seiten 1027–1028. Spektrum Akademischer Verlag,
Heidelberg, 1994.
[32] W3C World Wide Web Consortium. Extensible Markup Language (XML),
1. Apr 2005. http://www.w3.org/XML.
[33] W3C World Wide Web Consortium. Synchronized Multimedia Integration Language (SMIL 2.1), 1. Feb 2005. http://www.w3.org/TR/2005/WDSMIL2-20050201/.
[34] W3C World Wide Web Consortium. XML Path Language (XPath) 2.0, 1.
Apr 2005. http://www.w3.org/TR/xpath20.
[35] W3C World Wide Web Consortium. XQuery 1.0: An XML Query Language,
1. Apr 2005. http://www.w3.org/TR/XQuery.
[36] Aaron Walsh und Mikael Bourges-Sevenier. MPEG-4 Jump Start, Kapitel 11. Prentice Hall, Dez 2001.
[37] web3D Consortium. X3D Documentation. http://www.web3d.org/x3d/.
[38] Justin Zobel und Philip W. Dart. Finding Approximate Matches in Large
Lexicons. Software - Practice and Experience, 25(3):331–345, 1995.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Abbildungsverzeichnis
2.1
2.2
2.3
Wellenüberlagerung bei Kugelquelle . . . . . . . . . . . . . . . . 15
Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Abspielvorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
Systemarchitektur, Teilsystem Metadaten . . . . . . . . .
Verwaltungsstruktur für XMT-SAW Dokumente . . . . . .
Ausschnitt aus der Struktur eines XMT-SAW Dokuments .
XML-Struktur der Versionsdaten in Form von Deltas . . .
Versioniertes XML-Dokument mit Zeitstempeln, Version 1
XML-Dokument in Version 2 . . . . . . . . . . . . . . . .
Retrieval mittels Zeitstempeln und Deltas . . . . . . . . .
Tabellenlayout der N-Gramme . . . . . . . . . . . . . . .
Oberfläche des Suchdialogs . . . . . . . . . . . . . . . . .
Klassenstruktur der implementierten Metadatenverwaltung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
51
61
62
65
65
70
81
82
90
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Systemarchitektur, Teilsystem Audiodaten . . . . . . .
200 Abfragen mit je 512 Samples und 32 Audioquellen
200 Abfragen mit je 512 Samples und 64 Audioquellen
32 Soundquellen, 1.000 Abfragen . . . . . . . . . . .
64 Soundquellen und Lesen von 10.000x512 Samples .
64 Soundquellen, 10.000x512 Samples gelesen . . . .
Dateilayout . . . . . . . . . . . . . . . . . . . . . . .
Dateierzeugung . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
100
101
111
113
118
120
122
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Tabellenverzeichnis
3.1
3.2
3.3
3.4
Native XML-Datenbanken . . . . . .
ID-geeignete Attribute . . . . . . . .
Overhead der Versionierungsverfahren
Speicherzeiten . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
. 56
. 67
. 69
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Datenbank-Größen . . . . . . . . . . . . . . . . . . . . .
Durchschnittszeit (ms) bei einer Seitengröße von 4 kByte .
Durchschnittszeit (ms) bei einer Seitengröße von 64 kByte
Durchschnittszeit (ms) bei 64 Audioquellen . . . . . . . .
Durchschnittszeit (ms) im Vergleich: Float und WAV . . .
Durchschnittszeit (ms) im Vergleich: Cursorzugriff . . . .
Durchschnittszeit (ms) abhängig von der Cachegröße . . .
Vergleich der Zugriffsmethoden, abhängig von S/DS . . .
Zeitaufwand (ms) für verschiedene Implementierungen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inv.-Nr.: 2005-06-01/071/IN99/2254
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
110
111
113
114
114
115
116
119
Quelltextverzeichnis
2.0
3.0
3.1
3.2
3.3
3.4
3.5
Ausschnitt eines XMT-SAW Dokumentes
XML-Dokument mit Semantik im Layout
XML-Dokument ohne semantisches Layout
Differenzbestimmung zweier XML-Dokumente
History-Struktur bei Delta-Versionierung
Algorithmus der Ähnlichkeitssuche
Bestimmung von QGrams
22
41
42
58
63
78
84
A.0
A.1
A.2
A.3
Abfrage eines Dokumentes
128
Bestimmung des als PID funktionierenden Attributes zum Element
129
Bestimmung des Wertes des PID-Attributes zu gegebenem Element
130
Ermittelt für Eltern-Element das Kind mit gleichem PID-Wert wie gegebenes
Vergleichselement
131
A.4 Liste aller neuen, veränderten und gelöschten Attribute zu gegebenem Element bestimmen
132
A.5 Bestimmung der Differenzen zwischen zwei XML-Dokumenten
133
Inv.-Nr.: 2005-06-01/071/IN99/2254
Abkürzungsverzeichnis
ACID
ALSA
API
BDB
BLOB
CVS
DB
DBMS
DBS
DOM
DTD
MPEG
OODBMS
RCS
RDBMS
SAX
SCCS
SMIL
SQL
W3C
WFS
X3D
XML
XMT
Atomicity Consistency Isolation Durability
Advanced Linux Sound Architecture
Application Programming Interface
Berkeley DB
Binary Large Object
Concurrent Versioning System
Datenbank
Datenbank-Management-System
Datenbanksystem
Document Object Model
Document Type Definition
Moving Picture Experts Group
Objektorientiertes DBMS
Revision Control System
Relationales DBMS
Simple API for XML
Source Code Control System
Synchronized Multimedia Integration Language
Structured Query Language
World Wide Web Consortium
Wellenfeldsynthese
Extensible 3D Graphics
eXtensible Markup Language
eXtensible MPEG-4 Textual Format
Inv.-Nr.: 2005-06-01/071/IN99/2254
Thesen
• Das IOSONO-System stellt bezüglich der Verwaltung der benötigten Daten diverse Anforderungen, welche mit der aktuellen Implementierung nur
unzureichend erfüllt werden können. Die Speicherung der Metadaten bietet
keine Verwaltungsdienste, und die Audiodaten bringen in ihrer Speicherform das System an seine Performancegrenzen.
• Das Datenbankmanagementsystem Berkeley DB XML ist dazu geeignet,
die Metadaten von IOSONO komfortabel und integriert zu verwalten. Es
bietet leichte Erweiter- und Anpassbarkeit der Funktionalitäten.
• Auf Grundlage des in dieser Arbeit vorgestellten und implementierten Verwaltungssystems lässt sich ein komplexes Multiuser-System aufbauen. Dazu können die schon umgesetzten Komponenten einfach angepasst und erweitert werden.
• Die aktuelle Speicherung der Audiodaten liefert keine ausreichende Performance, um die Anzahl an aktiven Audioquellen merklich zu erhöhen. Bei
32 Quellen ist die Grenze schon erreicht, mit 64 Quellen beginnt das System
zu stocken.
• Die Speicherung der Audiodaten mittels des Datenbanksystems Berkeley
DB bietet keine Möglichkeiten, die Echtzeitanforderungen des IOSONOSystems zu erfüllen. Berkeley DB ist daher für den Einsatz in dieser Umgebung nicht geeignet.
• Mit der Ablage der Audiodaten in Form einer optimierten Dateilösung lässt
sich die IOSONO-Performance relevant steigern. Auf diesem Ansatz kann
in Zukunft aufgesetzt werden, um die Leistungsfähigkeit des Systems zu
erhöhen.
Inv.-Nr.: 2005-06-01/071/IN99/2254
Eigenständigkeitserklärung
Hiermit versichere ich, dass ich vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen, die anderen
Werken dem Wortlaut oder dem Sinn nach entnommen wurden, habe ich in jedem
einzelnen Fall durch die Angabe der Quelle, auch der benutzten Sekundärliteratur,
als Entlehnung kenntlich gemacht.
Ilmenau, den 30. Mai 2005
Hendrik Rusch
Inv.-Nr.: 2005-06-01/071/IN99/2254