Multimedia in Datenbanken: Image und Video - Marvin

Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Multimedia in Datenbanken:
Image und Video
Jörg Harr und Marvin Hoffmann
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
1
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Inhaltsverzeichnis
1 Einführung
1.1 Motivation
1.2 Zielsetzung
3
3
4
2 Architektur von Multimedia-Anwendungen
2.1 Client-Server Architektur
6
7
3 Oracle interMedia
3.1 Objekttypen
3.1.1 ORDImage
3.1.2 ORDVideo
3.1.3 ORDDoc
9
10
11
13
13
4 Performance
4.1 System Global Area (SGA)
4.2 Tablespace und Tabelle
15
16
17
5 Praxis
5.1 Architektur
5.2 Umsetzung
5.3 Probleme
19
19
20
26
6 Fazit
28
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
2
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
1 Einführung
Im Rahmen der Vorlesung “Persistenz Management” entstand diese Arbeit zum Thema
Multimedia in Datenbanken. Schwerpunktmäßig beschäftigt sie sich mit all den
wichtigen Begriffen die in diesem ersten Satz gefallen sind. Wieso Persistenz
Management? Wie passen (Oracle) Datenbanken und multimediale Inhalte zusammen?
Auf diese und viele weitere Fragen, die sich aus diesen ableiten, versucht diese Arbeit
Antworten zu geben.
In Kapitel 5 wird schließlich von den technischen Grundlagen zu einem konkreten
Projekt übergegangen. Was dem Leser zuvor anhand von Theorie vermittelt wurde,
erhält dadurch einen praktischen, anschaulichen Rahmen, sodass das frisch Gelernte,
was zunächst vielleicht etwas abstrakt wirkt, deutlich greifbarer wird. Bei dem Projekt
handelt es sich um eine Bilder-Galerie, welche mit PHP, HTML und Java-Script
umgesetzt wurde. Die Bilder wurden ganz im Sinne der Thematik in einer Oracle
Datenbank abgelegt. Mehr dazu im entsprechenden Kapitel.
1.1 Motivation
Es gab viele Gründe sich mit dieser Thematik zu befassen.
Dass das Internet allgegenwärtig und aus dem Alltag der meisten Menschen nicht mehr
wegzudenken ist, darüber dürfte es wenig Diskussionsbedarf geben. Betrachtet man
exemplarisch einige große Player des Internets, so wird auch relativ schnell klar, dass
es neben sozialen Aspekten hauptsächlich multimediale Inhalte sind die Webseiten wie
Facebook, Google, YouTube, Flickr, oder viele weitere Größen so beliebt machen.
Diese multimedialen Inhalte verursachen dort nicht nur riesige Menge an Daten,
sondern stellen in den meisten Fällen noch weitere Anforderungen. Oft müssen Bilder
oder Videos in verschiedenen Qualitätsstufen oder Größen bereit gestellt werden. Sei
es eine Thumbnail-Vorschau eines Bildes, wie in der Galerie des Projektes nötig, oder
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
3
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Varianten für verschiedene Bildschirmauflösungen auf Webseiten die Hintergrundbilder
anbieten. Auch das Management dieser großen Datenmengen ist nicht trivial.
All diese Gedanken waren eigentlich schon Anlass genug, sich mit der Kombination aus
Datenbanken und Multimedia auseinanderzusetzen. Darüber hinaus gab es jedoch
noch einen weiteren Grund.
Den Autoren war es wichtig einmal einen Weg zu bestreiten, den Sie bisher noch nicht
gegangen waren. Dateien, seien es Bilder oder Videos, waren bisher immer direkt im
Dateisystem abgelegt und es wurde ausschließlich eine Referenz in der Datenbank
gespeichert. Diese Vorgehensweiße hat jedoch ihre Nachteile. Was tun beim Umzug
von Dateien? Wie kann man effizient ein Backup durchführen, geschweige denn
zurückspielen und gewähren, dass noch alle Referenzen ihr Ziel finden? Was tun wenn
sich Ordnerstrukturen oder IP-Adressen ändern?
1.2 Zielsetzung
An die Thematik wurde aus zweierlei Perspektiven herangegangen. Zum einen sollte
grundlegendes Wissen vermittelt werden, zum anderen sollte diese Theorie darüber
hinaus in der Praxis in einem greifbaren Projekt umgesetzt werden.
Das Ziel in Sachen Theorie sah so aus, dass ein Verständnis dafür geschaffen werden
sollte,
was
Vor-
und
was
Nachteile
beim
Einsatz
von
Datenbanken
als
Persistenzschicht sind und woraus sich diese ergeben. Darüber hinaus war es wichtig,
sich mit dem interMedia Modul von Oracle auseinanderzusetzen, um dessen
Möglichkeiten zu kennen. Welche Funktionen stellt es bereit? Wie können diese sinnvoll
eingesetzt und kombiniert werden?
Neben den Anforderungen an das Erlernen der Theorie, gab es auch eine eigene
Erwartungshaltung an das Projekt und seine Umsetzung. Oracle war seitens der
Vorlesung als Technologie gesetzt und da das Thema “Multimedia” lautete, war auch
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
4
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
klar, dass das interMedia Modul zum Einsatz kommen würde. Als Spezialisierung wurde
wie bereits erwähnt das Thema Bilder/Videos gewählt. Es lag daher nahe, eine
Bildergalerie zu entwickeln und diese um interessante und sinnvolle Funktionen zu
erweitern. Konkret sollten verschiedene Versionen von Bildern bereitgestellt werden,
EXIF-Meta-Daten ausgelesen werden und das Ganze mit einer ansprechenden
Oberfläche dargestellt werden. Sämtliche Bildbearbeitungsschritte sollten dabei von der
Datenbank übernommen werden. Mit dieser Fülle an Anforderungen konnte somit ein
breites Spektrum an theoretischen Zielen direkt praktisch umgesetzt werden.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
5
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
2 Architektur von Multimedia-Anwendungen
Schwerpunktmäßig beschäftigt sich dieses Kapitel mit einer so genannten Three-TierArchitecture1 und im Speziellen mit einer Client-Server Anwendung, welche innerhalb
des Persitenz-Layers auf Oracle setzt. Dadurch wird der Bezug zu den im weiteren
Verlauf noch folgenden Komponenten der Oracle Familie hergestellt und dennoch auch
allgemein gültiges Technologieverständnis vermittelt.
Sobald man sich bei der Software-Entwicklung mit Architektur beschäftigt, stellt häufig
bereits die Terminologie das erste große Problem dar. Verwendet man das Wort der
Three-Tier-Architecture, dann wissen die meisten am Tisch sofort was gemeint ist. Auch
bei der deutschen Beschreibung als Drei-Schichten-Architektur herrscht hoffentlich
noch ein gemeinsamer Konsens. Sobald man aber im Detail dann von dem Persistenz
Layer spricht, kann es unter Umständen zu unterschiedlichen Auffassungen kommen.
Denn andere würden exakt diese Schicht eher als Data-Server-Tier bezeichnen und so
ist es dringend zu empfehlen, exakt zu spezifizieren, was man mit dem jeweils
verwendeten Begriff verbindet. Aber ist das eigentlich nötig? Während ein
Anwendungsentwickler
den
Persistenz
Layer
vielleicht
ausschließlich
als
Datenhaltungsschicht versteht, kann ein ein Entwickler, welcher sich stärker an der
Datenbank orientiert, einer ganz anderen Auffassung sein. Letzterer würde eventuell
eher die Begrifflichkeiten von Client Tier, Application Server Tier und Data Server Tier
verwenden wollen (siehe Abbildung 1) und die Persistenz lediglich als einen Teil der
Data Server Tier ansehen. Hierbei kann die Data Server Tier ebenso manipulative
Funktionalitäten beinhalten und nicht ausschließlich zur Datenhaltung eingesetzt
werden. Und genau das ist hierbei der springende Punkt. Verwendet man die innerhalb
dieser Ausarbeitung beschriebenen Technologien, wird zum Beispiel die Größe eines
Bildes innerhalb dieser Schicht (Data Server Tier) verändert und nicht etwa durch ein
Script innerhalb des Webservers.
1
http://www.linuxjournal.com/article/3508
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
6
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Abbildung1: Allgemeine Three-Tier-Architecture
2.1 Client-Server Architektur
Wie in Abbildung 1 zu erkennen, stellt die Data Server Tier die unterste Ebene
innerhalb der hier beschriebenen Architektur für multimediale Anwendungen dar. Die
Datenbank bietet, dargestellt durch den Media parser und einen Media processor,
Möglichkeiten um etwa an die Meta-Informationen des jeweiligen Formates zu gelangen
als auch Funktionen zur Manipulation der Daten. Das Verändern der Größe eines
Bildes wurde als Beispiel hierfür bereits genannt. Ebenso auf dieser Ebene angeordnet
sind sogenannten Special Indexers und Delivery Servers. Special Indexer hat nicht
etwa mit dem Index einer Datenbank Tabelle zu tun. Hiermit ist Software von
Drittanbietern
gemeint,
welche
es
beispielsweise
ermöglicht
Sprache-zu-Text
verarbeiten zu können. Diese Art der Medienverarbeitung soll im weiteren Verlauf aber
keine Rolle spielen. Ebenso wenig wie der Einsatz von Delivery Servers. Auch hier
kommt Software von Drittanbietern zum Einsatz, um zum Beispiel das Streamen von
Videomaterial zu ermöglichen. Reines Speichern und Ausliefern von Video ist auch mit
Oracle direkt möglich, das Streamen stellt allerdings ein Spezialfall dar, da die Benutzer
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
7
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
ein Video nicht erst vollständig downloaden möchten um es ansehen zu können. Hierzu
später mehr.
Während in Abbildung 1 der Application Server seine Position in der Application Server
Tier wiederfindet, gibt es auch eine alternative Variante die speziell bei Datenbank
naher Entwicklung eingesetzt werden kann. Dabei wird nicht mittels JavaServerPages
(JSP)1 und den interMedia class libraries auf der Application Server Tier auf die Daten
innerhalb der Datenbank zugegriffen, sondern mit Hilfe von PL/SQL und dessen
direktem Zugriff auf die innerhalb der Datenbank verfügbaren interMedia Funktionen.
Verzichtet man also auf den Application Server, wird dennoch eine Komponente
benötigt, die für die Anzeige der Daten beim Client zuständig ist. Diese Daten müssen
eventuell auch für das jeweilige Medium, wie Smartphone, Tablet oder Computer,
anpasst werden. Die Application Server Tier wird also dennoch benötigt und auch der
angebotene Oracle HTTP Server powered by Apache, befindet sich genau genommen
auf dieser Ebene. Lediglich die Logik befindet sich, repräsentiert durch PL/SQL,
innerhalb des Datenbank Servers.
Eine direkte Empfehlung für den Einsatz einer bestimmten Variante für alle
Anwendungszwecke fällt den Autoren jedoch, wie zu erwarten, schwer. Den einen
goldenen Weg gibt es auch innerhalb dieses Bereiches leider nicht. Letztlich ist es eine
Frage der Skalierung. Sicherlich ist der Einsatz von PL/SQL zum Umgang mit Inhalten
der Datenbank und der damit verbundenen Möglichkeiten durch interMedia für sich
genommen sehr effektiv. Programmiersprachen wie
PHP bieten allerdings ebenso
Möglichkeiten um mit Multimedia-Inhalten umzugehen und die Webserver, auf denen
die PHP Scripte ausgeführt werden, lassen sich einfacher skalieren als ein
Datenbanksystem, welches beispielsweise neben der Änderung von Bildformaten auch
noch die sehr wichtige Aufgabe der Datenspeicherung besitzt. Skalierung kann also
gerade bei der Konzeption einer Architektur enorm wichtig sein und sollte deshalb
weitreichend beachtet werden.
1
JSP - JavaServerPages
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
8
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
3 Oracle interMedia
Als Oracle interMedia bezeichnet man eine Funktionalität speziell von Oracle
Datenbanken, welche es ermöglicht multimediale Inhalte innerhalb einer Oracle
Datenbank Umgebung zu verwalten. Der Begriff der Verwaltung wurde an dieser Stelle
bewusst gewählt, da die Möglichkeiten durch Oracle interMedia weit über die reine
Datenspeicherung hinaus gehen. Mit Hilfe spezieller Objekttypen, wie beispielsweise
ORDImage, ORDAudio, ORDDoc und ORDVideo, erhält man weiterreichende
Möglichkeiten Datein abzulegen, Datein zu manipulieren oder die mit der Datei
verbundenen Meta-Informationen automatisch zu extrahieren.
Neben der klassischen Variante die Datein selbst, wie auch die dazugehörigen MetaInformationen in der Oracle Datenbank abzulegen, bietet Oracle interMedia auch die
Möglichkeit hier eine Trennung vorzunehmen. Dabei werden die Meta-Informationen in
der Oracle Datenbank direkt gespeichert und indexiert, die tatsächlichen Inhalte wie
etwa Bilder werden allerdings nur referenziert und außerhalb (siehe Abbildung 2) der
Datenbank abgelegt.
Abbildung 2: Beispiel für referenzierte externe Daten
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
9
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Des weiteren sollte erwähnt werden, dass Oracle interMedia zur Verarbeitung von
Bildern auf Java Advanced Imaging (JAI)1 setzt und somit nahezu den selben
Spielraum bietet, wie eine klassische Java Anwendungen. Oracle selbst sagt, dass
interMedia sogar noch weiter geht und JAI um weitere Formate erweitert.
Entsprechende Schnittstellen zu Java und SQL sind selbstverständlich vorhanden.
3.1 Objekttypen
An dieser Stelle wollen wir uns die verfügbaren Objekttypen von Oracle interMedia noch
etwas näher ansehen. Alle bereits erwähnten Objekttypen, basieren auf dem selben
objektrelationalen Typ, nämlich ORDSource. Ein Objekt vom Typ ORDSource bietet
selbst auch Methoden zur Verarbeitung an, es wird aber von Oracle strengstens
empfohlen, diese Methoden nicht direkt aufzurufen, sondern nur durch die
entsprechenden Wrapper. Ein solcher Wrapper ist beispielsweise ORDImage. Da diese
Implementierung wissentlich auf Java basiert, stellt sich den Autoren allerdings die
Frage, weshalb die Methoden von ORDSource nicht als abstract deklariert wurden, um
so einen direkten Zugriff zu verhindern. ORDSource spielt ebenso eine Rolle bei der in
Abbildung 2 dargestellten Architektur-Variante. Ein ORDSource Objekt, als quasi
Basistyp für alle anderen Objekttypen, kann die reinen Media-Daten auf zwei Arten
speichern. Die erste Möglichkeit ist eine Datei als BLOB2 direkt in der Datenbank zu
persistieren. Das heißt die Datei, zum Beispiel ein Bild, wird direkt als Binär-Datei in der
Datenbank vorgehalten. Variante zwei ist das Speichern der Media-Daten als BFILE3.
Hierbei werden lediglich Pfad und Datei-Name in der Datenbank persistiert. Die Datei
selbst bleibt jedoch auf dem File-System. Diese Art der Speicherung bringt jedoch
einige Nachteile mit sich:
1
http://java.sun.com/javase/technologies/desktop/media/jai/
2
http://www.orafaq.com/wiki/BLOB
3
http://www.orafaq.com/wiki/BFILE
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
10
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
● Keine Transaktions-Kontrolle. Äußerst problematisch bei kritischen Abläufen.
● Erschwerte Datensicherung aufgrund der externen Komponente.
● Migrationen
jeglicher
Art
werden
erschwert,
weil
beispielsweise
bei
Veränderungen immer das Zusammenspiel zwischen externen Medien und der
Datenbank beachtet werden muss.
● Pflegeaufwand erhöht sich aufgrund der simplen Tatsache, dass eine weitere
Komponente, nämlich die des Fileservers, existiert.
Welche Art der Speicherung bevorzugt werden sollte, kann von Fall zu Fall
unterschiedlich sein.
Alle Oracle interMedia Objekttypen in ihrem vollen Umfang zu analysieren, kann nach
Meinung der Autoren nicht Sinn einer solchen Ausarbeitung sein. Deshalb folgt an
dieser Stelle ein Verweis auf die Oracle Entwickler Dokumentation1, in welcher einzelne
Methoden und deren Eigenschaften sehr gut dokumentiert wurden. Aufgrund der
praktischen Auseinandersetzung mit Objekten vom Typ ORDImage, was später noch
aufgearbeitet werden wird, erhält dieser dennoch eine besondere Aufmerksamkeit.
Anschließend folgt eine Beschreibung von ORDVideo, da hier eine etwas speziellere
Situation herrscht. Als ebenso wichtig wird die Vorstellung von ORDDoc erachtet.
3.1.1 ORDImage
Beginnend mit ORDImage, betrachten wir den Objekttyp der ausschließlich für
Bildmaterial verwendet wird. Unterstützt wird hierbei nahezu jedes gängige Bildformat.
Eine vollständige Liste aller unterstützen Bildformate konnten wir leider nicht ausfindig
machen, konnten aber ebenso wenig Formate finden, die bei unseren praktischen Tests
zu Fehler geführt hätten. Entsprechend gehen wir von einer vollständigen Unterstützung
aller bekannten und häufig eingesetzten Bildformate aus.
Nun wäre das reine Ablegen von Bildern innerhalb einer Datenbank in Binärform auch
problemlos ohne ORDImage möglich. Warum also diesen speziellen Objekttypen
1
http://docs.oracle.com/cd/B14117_01/appdev.101/b10829/index.htm#O
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
11
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
verwenden? Weil man vielerlei Methoden geschenkt bekommt, die man mit großer
Wahrscheinlichkeit früher oder später benötigen würde. Hierzu gehören:
● Einfache Möglichkeit die Größe zu verändern. Stichwort Vorschaubilder.
● Konvertierung bezüglich Format oder Kompression
● Transformation bezüglich Schärfe oder Orientierung
● Teile aus einem Bild herausschneiden und ablegen (um bei statisch aufgebauten
grafischen Benutzeroberflächen Fehler in der Darstellung zu vermeiden)
● Das Bild innerhalb der Datenstruktur kopieren, um anschließend auf die
angefertigte Kopie die jeweils benötigten Manipulationen ausführen zu können
● Bilder suchen
Eine Besonderheit dieses Datentyps ist der als letztes beschriebene Punkt, die Suche.
Damit ist allerdings nicht etwa die Suche nach einem Dateinamen gemeint, sondern
nach anderen abgelegten Bildern, welche in ihrer Ansicht Ähnlichkeiten aufweißen. Wie
etwa Bilder mit blauem Himmel. Ähnlichkeiten bezüglich der gespeicherten Attribute in
Form von Meta-Informationen1, lassen sich natürlich auch mit den anderen Objekttypen
realisieren. Hier nun allerdings ein Beispiel für die Ähnlichkeits-Suche:
1
-- Vergleich zweier Bilder auf Basis der Bildfarbe:
2
score:=ORDSYS.ORDImageSignature.evaluateScore(image_sig,
3
compare_sig,'color=1.0,texture=0,shape=0,location=0');
4
DBMS_OUTPUT.PUT_LINE('Score is ' || score);
Ebenso möchten wir am Beispiel dieses Objekttyps demonstrieren, wie man einen
solchen mit Hilfe von PL/SQL in die Datenbank einfügt. Ein vollständige Prozedur hierzu
befindet sich in Kapitel 5.2 Umsetzung (STORE_PICTURE).
1
INSERT INTO pictures (id, picture_original, description)
2
VALUES (picture_id.nextval, ORDSYS.ORDImage.init('http',
3
picture_url, picture_name), description);
1
Attribute eines Objekttypen speichern Meta-Daten mit Informationen über Größe, Art, Format etc.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
12
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Dies nur ein Ausschnitt einer Prozedur, der dazu dienen soll, einen besonderen Blick
auf die Methode init() zu werfen. Es ist nötig diese Methode initial aufzurufen, um
zunächst einen EMPTY_BLOB zu erzeugen, der alle Werte mit NULL initialisiert.
Anschließend hat man zwei Möglichkeiten:
1. ORDSYS.ORDImage.init('file', picture_path, picture_name)
2. ORDSYS.ORDImage.init('http', picture_url, picture_name)
Variante eins lädt sich das Bild in den Objekttyp mit Hilfe des angegebenen Dateipfades
(picture_path). Das Selbe geschieht bei Variante zwei, mit dem Unterschied, dass
man hier eine vollständige URL (picture_url) zur Bild-Datei angeben muss.
3.1.2 ORDVideo
Wie bereits angedeutet, gibt es beim ORDVideo Objekttyp eine etwas speziellere
Situation. Eine Oracle Datenbank tatsächlich zur Speicherung und Auslieferung für
Video-Material zu verwenden, ohne dabei auf Software von Drittanbietern zurück zu
greifen, ist schlicht nicht sinnvoll. Grund hierfür ist ein ganz Einfacher: Oracle interMedia
unterstütz kein Streaming und diese Form der Auslieferung ist gerade bei VideoMaterial unerlässlich. Ein möglicher Workaround sieht so aus, dass die eigentlichen
Daten auf spezialisierten Streaming Servern gespeichert werden können und von dort
kontinuierlich übertragen werden. Diese Daten werden in der Datenbank dann
ausschließlich referenziert. Microsoft Media Services1 und Real/Helix Server2 sind
hiervon zwei bekannte Vertreter, welche innerhalb dieser Ausarbeitung aber nicht näher
behandelt werden.
3.1.3. ORDDoc
Ebenso kurz erklärt werden sollte der Objekttyp ORDDoc. Dieser eignet sich besonders
dann, wenn nicht exakt spezifiziert werden kann um welchen Datentyp es sich bei der
1
http://technet.microsoft.com/de-de/library/cc753556%28v=ws.10%29.aspx
2
http://www.realnetworks.com/helix/download-streaming-media-products/
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
13
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
abzulegenden Datei handelt. ORDDoc ermöglicht es somit, auch heterogene Daten
innerhalb eines definierten Objekttypen zu speichern und mit Oracle interMedia zu
persistieren.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
14
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
4 Performance
In diesem vierten Kapitel geht es nun um das wichtige Thema “Performance”. Schon
beim Versuch dieses Wort ins Deutsche zu übersetzen, stellt sich eine wichtige Frage.
Was ist mit Performance eigentlich gemeint? Heißt Performance - also “Leistung” automatisch “Geschwindigkeit”? Und an welcher Stelle muss die Datenbank oder auch
die ganze Anwendung besonders performant sein? Diese Frage
sollte sich jeder
Stellen, der seine Anwendung, und im Zuge dessen auch seine Datenbank, optimieren
möchte. Die Performance einer Anwendung kann in vielen Bereichen wichtig sein. Zum
Beispiel gehören dazu:
● Antwortzeit (user response time)
● Dauer um Daten zu laden
● Benötigte Zeit um ein Backup zu erstellen
● Benötigte Zeit um ein System nach einem Fehler wieder betriebsbereit zu haben
Um hinsichtlich Performance effektiv Optimierungen vornehmen zu können, sollten vor
der tatsächlichen Optimierung daher Bedürfnisse erkannt und Ziele festgelegt werden.
Auf verschiedene Bedürfnisse kann mit Hilfe unterschiedlicher Lösungen reagiert
werden. Häufig beschrittene Wege zur Leistungssteigerung eines Systems sind:
● Erweiterung der Hardware
● Änderungen in der Infrastruktur (Datenbanksystem, Betriebssystem,
Anwendungsserver, ...)
● Änderungen an der Anwendung selbst
● Änderung von Prozessabläufen (Auslagerung des Backups in die Nacht, ...)
Im
Rahmen
dieser
Ausarbeitung
werden
vorrangig
Datenbankspezifische
Optimierungen angesprochen. Zusätzlich zum Datenbank-Fokus kommt noch der
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
15
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
multimediale Fokus hinzu. Es werden also ein paar grundsätzliche Hinweiße, im
Umgang mit multimedialen Datenbanken, aufgezeigt.
4.1 System Global Area (SGA)
Im ersten Schritt wird die System Global Area1 (fortan SGA genannt) betrachtet. Hier
gibt es einige Parameter an denen geschraubt werden kann, um die Leistungsfähigkeit
der Datenbank zu verbessern. Zunächst einmal gilt grundsätzlich folgende Faustformel.
Ist die Größe der SGA zu klein gewählt, so kann dies zu starker Input-/Output-Aktivität
führen. Wird die SGA zu groß gewählt, so kann es passieren, dass es zu intensivem
Paging und Swapping kommt. Hier gilt es also den optimalen Mittelweg zu finden.
Betreibt man eine interMedia-Anwendung, dann wird dazu geraten die SGA eher groß
zu wählen, da mit vergleichsweiße großen Dateien gearbeitet wird. Bilder oder gar
Videos haben in aller Regel natürlich deutlich größeren Speicherbedarf als rein
Textbasierte
Informationen.
Um
einem
erhöhten
Paging
und
Swapping
entgegenzuwirken ist es ratsam beim physikalischen Hauptspeicher des Servers nicht
all zu geizig zu sein. Grundsätzlich ist Hauptspeicher natürlich immer deutlich schneller
als normale Festplatten. Besonders schwer ins Gewicht fällt dieser Aspekt aber gerade
bei multimedialen Anwendungen, bei denen meist große Mengen an Daten vorgehalten
werden.
Die SGA ist in unterschiedliche Bereiche eingeteilt. Einer davon ist der Java Pool. Über
den Parameter java_pool_size lässt sich die Größe des Pools anpassen. Da
interMedia bei der Abarbeitung von Befehlen häufig auf Java zurückgreift, ist es sinnvoll
diesen Parameter zu erhöhen.
Um sinnvolle Werte für diesen und weitere Parameter zu finden, kann auf das
Automatic Workload Repository (AWR)2 zurückgegriffen werden. Dieses sammelt
1
http://www.dba-oracle.com/concepts/sga_system_global_area.htm
2
http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/AWR_transport/index.html
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
16
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Informationen die relevant sind um die Performance einer Datenbank zu verbessern.
Dazu gehören zum Beispiel wait events, verschiedene Zeitmodell-Statistiken sowie die
System- und Session-Statistiken, um nur einige wenige zu nennen. Die gesammelten
Informationen können dann mit Hilfe des Automatic Database Diagnostic Monitor
(ADDM)1 ausgewertet werden. Basierend auf den daraus gewonnen Erkenntnissen
können
anschließend
sinnvolle
Werte
für
diverse
Parameter,
wie
den
java_pool_size Parameter, gesetzt werden.
4.2 Tablespace und Table
Die nächsten Ebenen, auf denen weitere Hebel angesetzt werden können, sind der
Tablespace und die Tabelle selbst. Ähnlich wie bei der SGA gilt im Falle der
Multimedia-Datenbank auch “je größer desto besser”. Bereits initial sollte der
Tablespace möglichst groß gewählt werden. Eine Erweiterung des Tablespaces sollte
auch so selten wie möglich passieren, weshalb auch der NEXT Parameter des
Statements groß gewählt werden sollte. Ein Statement könnte in etwa so aussehen:
CREATE
TABLESPACE
RAWIMG
DATAFILE
‘images.tbs’
SIZE
40000M
AUTOEXTEND ON NEXT 5000M;
Je nach Anwendungsfall macht es unter Umständen durchaus Sinn, dass darauf
geachtet wird, dass die Bilder nicht gecacht werden, um den wertvollen Cache nicht zu
schnell zu füllen. Dies ist natürlich nur dann sinnvoll, wenn die Bilder nicht in ständigem
Zugriff sind. Durch das Einfügen des Schlüsselwortes NOCACHE in das CREATEStatement der Tabelle kann man dies erreichen.
Einen weiteren Performance-Gewinn kann man durch das Verteilen von Daten auf
mehrere Festplatten erzielen. Auch hierfür gibt es diverse Ansätze. Wer als DatenbankAdministrator möglichst alles selbst in die Hand nimmt, der kann zu Beginn mehrere
Tabelspaces auf unterschiedlichen physikalischen Festplatten erstellen. Beim Erstellen
1
http://www.oracle-base.com/articles/10g/AutomaticDatabaseDiagnosticMonitor10g.php
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
17
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
der Tabelle kann er dann dafür sorgen, dass die Bilder gleichmäßig über alle
gewünschten Tablespaces verteilt werden. Oracle bietet mit dem Automatic Storage
Management (ASM)1 jedoch auch eine Möglichkeit, dass eine solche Verteilung
automatisch durch das RDBMS2 geschieht. Der Datenbank-Administrator muss dabei
lediglich dem ASM mitteilen, welche physikalischen Festplatten genutzt werden sollen.
Das Automatic Storage Managment sorgt anschließend dafür, dass sämtliche I/OOperationen sorgfälltig über diese Festplatten-Gruppe hinweg verteilt werden.
1
http://www.dba-oracle.com/art_so_disk_tuning_1.htm
2
http://www.itwissen.info/definition/lexikon/relational-database-management-system-RDBMSRelationalesDatenbank-Managementsystem.html
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
18
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
5 Praxis
Nachdem nun durch die Vermittlung von Theorie eine gemeinsame Wissensbasis
geschaffen wurde, wird nun der praktische Teil der Arbeit vorgestellt. Bereits in der
Einleitung gab es ein paar Worte zu dem Projekt zu lesen. In diesem Kapitel wird nun
zunächst die Architektur der Anwendung vorgestellt, bevor der beschrittene Weg zur
Umsetzung des Projekts dargelegt wird. In einem abschließenden Unterkapitel wird
dann noch auf die Probleme eingegangen, mit denen die Autoren während der
Umsetzung zu kämpfen hatten.
5.1 Architektur
Die Gallery dient uns als praktisches Beispiel, um das gelernte Wissen tatsächlich auch
innerhalb eines realistischen Szenarios umzusetzen und im Einsatz analysieren zu
können. In Kapitel 3 zu Oracle interMedia wurde schon erläutert, dass es mehrere
Wege gibt, um Mediadaten zu persistieren. Die Autoren haben sich dazu entschieden
die Bilder in der Datenbank zu speichern (siehe Abbildung 3).
Erläutern wir zunächst die einzelnen Komponenten in Abbildung 3. Wie für eine Galerie
im Interner üblich, wird selbstverständlich ein Browser, sowie ein für die Auslieferung
der Inhalte nötige Webserver benötigt. In unserem Fall handelte es sich dabei um einen
Apache Webserver, welcher innerhalb einer Oracle VM1 (Virtual Machine) betrieben
wird. Als Basisbetriebssystem setzten wir Ubuntu 10.04 in der LTS2 (Long Term
Support) Version ein. Der Apache musste für seine benötigte Aufgabe keine
außergewöhnliche Konfiguration aufweißen. Allerdings war es nötig für PHP ein
weiteres Modul zu installieren, um speziell den Umgang mit Oracle Datenbanken zu
erleichtern. Bei diesem Modul handelt es sich um OCI83. Hierdurch erhält der Entwickler
die Möglichkeit innerhalb seines PHP Codes etwa PL/SQL Code zu implementieren.
1
https://www.virtualbox.org/wiki/Documentation
2
http://www.ubuntu.com/download/ubuntu/download
3
http://www.php.net/manual/en/book.oci8.php
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
19
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Dieser PL/SQL Code lässt sich dadurch dynamisch mit Variablen aus dem umliegenden
PHP Code bestücken. Ebenso wird ein einfacherer Umgang mit LOBs (Large Object
Typen) ermöglicht.
Abbildung 3: Konzept des Bilder-Galerie Projekts
Wie die einzelnen Komponenten konkret zusammenspielen wird im nächsten Kapitel
erläutert.
5.2 Umsetzung
Auf Seiten der Datenbank kommt die Anwendung mit lediglich einer Tabelle aus. Sie
enthält neben einer eindeutigen ID (ID) und einer Beschreibeung des Bildes
(DESCRIPTION) mehrere Versionen der Bild-Datei (PICTURE_XY) und falls vorhanden
Meta-Informationen, welche aus den EXIF-Daten1 der Bildern gewonnen werden
(META_EXIF). Abbildung 4 zeigt die Struktur der Tabelle im Detail.
1
Exchangeable Image File Format - http://www.exif.org/
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
20
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Abbildung 4: Struktur der PICTURES Tabelle
Die Bilder werden in der Datenbank mit Hilfe des interMedia ORDImage Objekt-Typs
abgelegt. Auch die EXIF-Daten werden aus dem ORDImage Objekt ausgelesen.
Gespeichert werden sie in der Tabelle jedoch in Form eines XMLTYPE.
Soll ein neues Bild in der Datenbank gespeichert werden, so klickt der Besucher der
Galerie auf den Durchsuchen Button am oberen Rand des Bildschirmes. Anschließend
kann über einen Betriebssystem-Dialog ein Bild auf dem Rechner des Nutzers
ausgewählt werden. Er muss sich nicht darum kümmern auch die zusätzlich
angebotenen Varianten des Bildes (Thumb, Small und Mirror) bereit zu stellen. Diese
werden automatisch nach dem Drücken des Submit Buttons durch das DBMS
generiert.
Abbildung 5: Bildschirmausschnitt der Galerie mit ausgewählter Bilddatei für neuen Upload
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
21
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Nachdem der Submit Button betätigt wurde, werden im Hintergrund nun mehrere
Schritte nacheinander durchgeführt. Zunächst einmal wird das Bild vom Client (dem
Nutzer) auf den Anwendungsserver in ein Unterverzeichnis /img geladen. Dies ist nötig,
um dem Datenbank-Server später das Bild zur Verfügung stellen zu können, damit es
dort
persistiert
werden
kann.
Im
zweiten
Schritt
wird
über
die
Prozedur
STORE_PICTURE ein neuer Datensatz in der Tabelle PICTURES erzeugt.
Prozedur STORE_PICTURE zum Speichern eines neuen Datensatzes:
1
create or replace
2
PROCEDURE STORE_PICTURE
3
(description IN VARCHAR,
4
picture_url IN VARCHAR,
5
picture_name IN VARCHAR)
6
AS
7
BEGIN
8
INSERT INTO pictures (id, picture_original, description)
9
VALUES (picture_id.nextval, ORDSYS.ORDImage.init('http',
10
picture_url, picture_name), description);
11
12
13
COMMIT;
END STORE_PICTURE;
Die vorgestellte Prozedur STORE_PICTURE hat drei Übergabewerte. Alle drei Werte
sind vom Typ VARCHAR. Die Parameter description dient lediglich als weitere MetaInformation die zur Darstellung auf der GUI verwendet wird. Er enthält eine
Beschreibung des gespeicherten Bildes und wird in der gleichnamigen Spalte der
Tabelle gespeichert. Der Paramter picture_url enthält die URL des Bildes und
picture_name enthält den Namen des Bildes. Diese beiden Werte sind wichtig für den
nächsten Part der Prozedur, das INSERT-Statement. Auffällig an diesem Statement ist
die Methode init(), welche auf dem ORDSYS.ORDImage-Objekt aufgerufen wird.
Diese ist bereits aus dem dritten Kapitel bekannt. Wie zu sehen ist, werden ihr die
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
22
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
beiden angesprochenen Parameter übergeben, damit in dem ORDImage Objekt bereits
die Information vorliegt, von welcher URL das Bild später geladen werden kann.
Nachdem der leere Datensatz angelegt wurde, besorgt sich die Anwendung in einem
kleinen Zwischenschritt zunächst dessen ID, bevor dann schließlich der Ladevorgang
des Bildes in die Datenbank angestoßen wird. Auch hier exemplarisch der Code.
Bild wird vom Anwendungsserver in die Tabelle des Datenbank-Servers geladen:
1
DECLARE
2
obj ORDSYS.ORDImage;
3
ctx RAW(64) := NULL;
4
5
BEGIN
6
SELECT picture_original INTO obj FROM pictures WHERE id =
7
'.$latest_id.' FOR UPDATE;
8
9
obj.import(ctx);
10
11
12
13
UPDATE pictures SET picture_original = obj WHERE id = '.$latest_id.';
commit;
END;
Der Code erklärt sich weitgehend von selbst. In den Zeilen 1-3 findet eine Deklaration
von Variablen statt. Zeile 6 und 7 beinhalten das SELECT-Statement um das original
ORDImage-Objekt aus der Datenbank zu lesen. In Zeile 9 wird über die import()Methode das Bild in die Variable obj vom Typ ORDImage geladen, welches dann über
ein UPDATE-Statement in Zeile 11 schließlich in die Datenbank geladen wird und das
leer initiierte Objekt dort ersetzt.
Wurde dieser Schritt erfolgreich durchgeführt, werden nun über eine weitere Prozedur
(LOAD_EXIF_DATA) alle vorhandenen EXIF-Daten aus dem Bild ausgelesen und in die
entsprechende Spalte gespeichert. Wurden auch diese Daten erfolgreich gespeichert,
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
23
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
oder waren keine EXIF-Daten vorhanden, so geht es nun weiter mit den
Bildtransformationen. Für jede Bildtransformation wurde wiederum eine eigene
Prozedur
erstellt.
In
der
Reihenfolge
PICTURE_SMALL,
PICTURE_THUMB,
PICTURE_MIRROR werden diese nacheinander aufgerufen und sorgen mit Hilfe von
interMedia ORDImage Transformationen
(vgl. Kapitel 3.1.1) dafür, dass
die
gewünschten Bildversionen erstellt werden. Nachstehend wird exemplarisch noch die
Prozedur für die gespiegelte Variante abgebildet und erläutert.
Prozedur PICTURE_MIRROR welche das Originalbild spielgelt und speichert:
1
create or replace
2
PROCEDURE PICTURE_MIRROR
3
(img_id IN NUMBER)
4
AS
5
timage1 ORDSYS.ORDImage;
6
timage2 ORDSYS.ORDImage;
7
8
9
BEGIN
SELECT picture_original INTO timage1 FROM pictures
WHERE id = img_id FOR UPDATE;
10
timage2 := timage1;
11
timage1.process('mirror');
12
UPDATE pictures p SET picture_mirror = timage1,
13
picture_original = timage2 WHERE id = img_id;
14
COMMIT;
15
EXCEPTION
16
WHEN ORDSYS.ORDImageExceptions.DATA_NOT_LOCAL THEN
17
DBMS_OUTPUT.PUT_LINE('Data is not local');
18
END;
Nachdem die Prozedur STORE_PICTURE bereits vorgestellt wurde, dürfte auch dieser
Code relativ leicht zu lesen sein. Einzige Besonderheit bei dieser Prozedur ist, dass das
Originalbild zunächst in beiden Variablen timage1 und timage2 gespeichert wird. Auf
das Objekt timage1 wird dann in Zeile 11 wiederum eine process()-Methode
aufgerufen. Das Schlüsselwort mirror, welches der Methode übergeben wird,
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
24
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
identifiziert welche Art von Bearbeitung durchgeführt werden soll. Anschließend werden
in den Zeilen 12 - 13 dann die Bilder in der Datenbank gespeichert.
Jeder Schritt wird hierbei natürlich protokolliert, sodass der Nutzer sehen kann, ob der
Upload seines Bildes erfolgreich war oder nicht. Konnte wie in Abbildung 6 ein Bild nicht
erfolgreich hochgeladen werden, oder schlägt eine der Bildtransformationen fehl, so
wird ein Rollback durchgeführt und auch der initial erstellte Datensatz wird wieder
gelöscht.
Abbildung 6: Upload-Protokoll mit Hinweiß auf fehlgeschlagene Operation
Wurden die Bilder gespeichert, wollen diese anschließend in der Galerie natürlich auch
dargestellt und hierfür wieder ausgelesen werden. Innerhalb der image.php wird eine
PL/SQL Funktion aufgerufen. Der Rückgabewert der Funktion GetPictureOriginal
enthält die Bilddaten als Binary und der Browser stellt das Bild aufgrund der ContentType
Information
im
Header
entsprechend
als
solches
dar.
Aufruf eines Bildes innerhalb von HTML:
1
<img src="http://localhost/image.php?id='.$ID.'&type=Original"
2
alt="Picture '.$ID.'" title="'.$title.'" />
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
25
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Sollte ein spezielle Bildform angefordert werden, wie etwa das Spiegelbild eines
Originalbildes, ändert sich schlicht der Wert von type. Um beispielsweiße die Funktion
GetPictureMirror aufzurufen, wird einfach das Schlüsselwort Mirror eingefügt.
5.3 Probleme
Die eine oder andere Hürde während der Entwicklung ist für sich gesehen ja nichts
besonderes. Zwei Dinge sind jedoch nach Meinung der Autoren erwähnenswert und
werden daher an dieser Stelle beschrieben.
Um mit Oracle zusammen zu arbeiten, benötigt PHP eine spezielle Erweiterung mit
dem Namen OCI8. Diese wurde bereits vorher schon erwähnt. PHP dahingehend zu
erweitern, dass diese Erweiterung innerhalb des phpinfo() Befehls korrekt aufgeführt
wurde, stellte sich als nicht so trivial heraus wie erwartet. Der größte Fehler lag darin,
dass der Zusammenhang zwischen dem benötigten Oracle Instantclient und der
geforderten PHP Erweiterung viel zu spät erkannten.
Hier
werden diverse
Umgebungsvariablen benötigt, welche nicht alle gesetzt wurden. Letzteres kann man
als Kleinigkeit bezeichnen, aber in Summe sind es diese Kleinigkeiten, die erforderlich
sind, für eine vollständige Funktionalität und dennoch in manchen Guides1 nicht
beschrieben sind.
Eine weitere Problematik stellte unser erstes Architekturkonzept dar, welches Trigger
beinhaltete. Folgender Plan war vorgesehen: Ein Datenbank Trigger wird durch das
Einfügen eines neuen Bildes in die Tabelle PICTURES angestoßen. In der selben
Tabelle soll der Trigger nun den eingefügten Datensatz lesen und verändern. Hiermit
wollten
die Autoren die Transformation, beispielsweise
das Erzeugen eines
Spiegelbildes, automatisiert durch Trigger abarbeiten lassen. Eine Fehlermeldung
machte deutlich, dass dieser Zugriff eine unzulässige Aktion darstellte und dies hinderte
uns daran, diesen Weg weiter zu verfolgen. Ein Lösungsvorschlag war das
AUTONOMOUS_TRANSACTION pragma. Damit können von der Haupttransaktion weitere
1
http://www.howforge.com/how-install-oci8-php-5-ubuntu
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
26
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
unabhängige Transaktionen ausgeführt werden. Leider blieb der Fehler weiterhin
bestehen, was letztlich eine architektonische Veränderungen veranlasste. Die Logik des
Triggers wurde daraufhin mit Hilfe von Prozeduren und Funktionen innerhalb des PHP
Codes realisiert. Die PHP-Anwendung kümmert sich um die erfolgreiche Durchführung
der jeweiligen Aktionen und startet bei Misserfolg einen Rollback, um die Datenbasis
stets konsistent zu halten.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
27
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
6 Fazit
Beginnend mit dem praktischen Teil, kann nun noch ein Blick auf die fertige Galerie
geworfen werden. In diesem Bildschirmfoto sind alle wichtigen Teile zu sehen. Neben
der verkleinerten Version eines Bildes in der linken unteren Hälfte des Browsers sind
auf der rechten Seit sämtliche verfügbaren Meta-Informationen des Bildes eingeblendet.
Darüber hinaus gibt es noch Download-Links zum Bild in Original-Größe und zum
gespiegelten Bild. Am oberen Ende sind mehrerer Bilder in Thumbnail-Größe zu sehen.
Ein Klick auf eines der Thumbnails bewirkt ein Sprung zum ausgewählten Bild, sodass
die Informationen in der unteren Hälfte entsprechend ersetzt werden. Mit dem Pfeil am
rechten Bildschirmrand kann zum nächsten Satz Bilder navigiert werden.
Abbildung 7: Galerie im Überblick
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
28
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Interagiert der Nutzer nach dem Betreten der Seite gar nicht mehr mit der Seite, so
laufen die Bilder in einer langsamen Slideshow nacheinander in einer endlosen Schleife
durch. Wird manuell ein Bild auswählt wird diese Slideshow beim entsprechenden Bild
angehalten. Durch einen Klick auf den Link Play Slideshow wird diese wieder an der
aktuellen Position fortgesetzt. Die Links Previous Photo und Next Photo bieten eine
weitere Möglichkeit zur schrittweißen Navigation durch die Bilder.
Was die Performance der Datenbank im Rahmen des Projektes angeht sind sehr
unterschiedliche Werte aufgetreten. Um ein Bild zu laden lag die Dauer zwischen
100ms und 6000ms. Diese starken Schwankungen könnten auch mit dem Netz der
Hochschule oder parallelen Gruppen zu tun haben, die den Datenbank-Server
ausgelastet haben. Im praktischen Teil wurden auch keine Optimierungen der
Datenbank vorgenommen. Durch die in Kapitel 4 beschrieben Maßnahmen hätte man
die Leistung der Datenbank sicher noch deutlich steigern können.
Zum Management der Daten bleibt zu sagen, dass das Handling mit den BLOB-Dateien
auch immer wieder für Schwierigkeiten gesorgt hat, als die Anwendung noch nicht
soweit war, dass sie sowohl Bilder speichern, als auch anzeigen konnte. Ein in der
Datenbank abgelegtes BLOB-Objekt ist einfach teilweiße zu abstrakt und bei kleinen
Bildern, die kaum ein paar Kilobyte groß sind, lässt sich kaum erahnen, ob ein Bild nun
erfolgreich gespeichert wurde oder nicht.
Besonders beigeistert waren die Autoren von den Recovery-Funktionen die einem die
Datenbank bietet, wenn die Bilder auch in der Datenbank liegen. Man muss sich nicht
um zusätzliche Sicherung von Dateien auf dem File-Server kümmern. Ein Backup der
Datenbank sorgt dafür, dass alles gesichert ist. Dies nimmt einem Administrator im
Live-Betrieb durchaus Sorgen. Andererseits entsteht dadurch natürlich auch ein Single
Point of Failure. Ist ein Datenbank-Backup korrupt, so sind nicht nur MetaInformationen, sondern auch die Bilder selbst verloren.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
29
Multimedia in Datenbanken: Image und Video
______________________________________________________________________
Sehr unkomfortabel war die erforderliche Konfiguration von PHP bezüglich der
Kommunikation mit Oracle. Die in Kapitel 5.3 beschriebenen Probleme mit dem OracleTreiber haben das Team im gesamten Projekt deutlich am längsten aufgehalten.
Alles in Allem bleibt zu sagen, dass dieser Umgang mit Multimedia-Dateien eine
sinnvolle Alternative zur klassischen Vorgehensweise mit Datenbank und File-Server
darstellt. Wer die Möglichkeit hat, eine Oracle-Datenbank mit interMedia Funktionalität
zu nutzen, der kann dies bedenklos tun. In weiterer Zukunft wird sich das Team
außerdem noch mit No-SQL Datenbanken, im Speziellen mit Dokumentenorientierten
Datenbanken, für diesen Anwendungsfall beschäftigen.
______________________________________________________________________
Persistenz Management - Jörg Harr und Marvin Hoffmann
30