In dieser Arbeit präsentieren wir eine Möglichkeit, Funktionalitäten -in diesem Fall primär Indizes -in eine Datenbank einzubringen. Dies geschieht in einer Weise, dass weder die Datenbank noch eine Anwendung, welche die Datenbank nutzt, etwas davon bemerken soll. Auf diese Weise soll die aufwendige Anpassung der Anwendungen an eine zusätzliche Komponente vermieden werden. Zugleich wird auch verhindert, dass die Datenbank durch das Einbringen neuer Funktionalitäten instabiler wird.
Datenbanken sind allgegenwärtig und nicht mehr aus dem täglichen Leben wegzudenken. Sie verwalten von vertraulichen Personendaten bis hin zum Zahlungsverkehr von Banken sehr viele Bereiche der Gesellschaft. Daraus ergeben sich einige Anforderungen, denen Datenbanksysteme gerecht werden müssen. So kann erwartet werden, dass Zugangsrichtlinien eingehalten und die Daten sicher -d. h. vor fremdem Zugriff und Verlust -verwahrt werden.
Datenbanken, wie wir sie heute kennen, haben sich dabei über viele Jahre hinweg entwickelt. Angefangen von den ersten Systemen, wie z. B. System R [4] und IMS [8], bis zu den heutigen großen relationalen Datenbanksystemenbspw. Oracle [14] und IBM DB2 [3], um nur einige zu nennen -wurden immer wieder neue Funktionalitäten hinzugefügt. Entwicklungen an Datenbanksystemen finden dabei meist direkt bei den Datenbankherstellern statt. Diese integrieren neue Techniken in ihre Datenbanken, wenn diese ausreichend getestet, ausgereift und für eine breite Öffentlichkeit nutzbar und nützlich sind. Selbst einige Spezialgebiete wurden bereits abgedeckt, so z. B. die Speicherung und schnelle Abfrage von räumlichen Daten mittels Oracle Spacial [17] oder dessen Pendant bei IBM, des DB2 Spatial Extenders [12]. Beide bauen einen neuen Index -einen R-Baum [9] bei Oracle, ein Grid bei DB2 [2] -ein.
All das führt dazu, dass heutige relationale Datenbanken für sehr viele Bereiche Lösungen in Form von Indizes bereits zur Verfügung stellen. Allerdings gibt es auch Anwendungsgebiete -jene, die nicht genügend Nachfrage bieten können -bei denen diese Standardlösungen nicht anwendbar sind. Der Anwender steht dann vor der Wahl, eine komplett eigene Datenbanklösung zu erstellen oder aber eine bestehende Datenbank zu erweitern. Eine Eigenentwicklung kommt dabei für die wenigsten in Frage, da diese immens zeit-und damit kostenintensiv ist. Sie muss darüberhinaus auch selbst weiterentwickelt und mit Aktualisierungen versorgt werden, ein weiterer sehr kostenintensiver Punkt, der gegen eine solche Entwicklung spricht.
Bei der zweiten Möglichkeit -der Erweiterung eines Datenbanksystems -wird über vom Datenbankhersteller bereitgestellte Schnittstellen die Funktionalität einer bestehenden Datenbank um die geforderten Eigenschaften erweitert. Es ist schwierig, diese Erweiterungen dauerhaft in Datenbanken zu integrieren. Zum einen haben die Datenbankhersteller ein berechtigtes Interesse daran, nur gut getestete Komponenten in ihre Produkte einfließen zu lassen, zum anderen müssen diese weitestgehend allgemein einsetzbar sein.
In einigen Umgebungen ist es allerdings nicht möglich, Eingriffe in die Datenbank oder die Anwendungen, die auf sie Zugriff nehmen, vorzunehmen. Ein Szenario ist hier der Betrieb eines Rechenzentrums, welches Datenbankdienstleistungen zur Verfügung stellt. Hier können weder Eingriffe in die Datenbanken vorgenommen werden, noch ist dies bei den Anwendungen möglich, da diese den Kunden gehören.
Aus diesem Grund wollen wir einen Weg schaffen, der sich in eben diesen Situationen einsetzen lässt und der dann auch für andere offensteht. Es soll dabei möglichst erreicht werden, dass das Zusatzmodul, ein Proxy, komplett transparent in die bestehende Infrastruktur integriert werden kann.
Im nächsten Abschnitt werden wir zunächst auf andere Techniken eingehen, die genutzt werden können, neue Funktionalitäten, speziell Indizes, in Datenbanken einzufügen. Anschließend werden wir unser Konzept aufzeigen und einige Spezialfälle diskutieren.
Klassischerweise können neue Funktionalitäten in Datenbanksysteme mittels Stored Procedures und eigenen abstrakten Datentypen (ADT) implementiert werden. Die meisten Datenbanksysteme bieten diese Möglichkeiten. [11,15,18] Diese Erweiterungsmöglichkeiten sind jedoch begrenzt, da mit ihnen immer die Ablage der Daten in den vorgegebenen Strukturen der Datenbank einhergeht. Auch lassen sich so die internen Abläufe nur schwer beeinflussen. Postgres bietet beispielsweise die Möglichkeit die verfügbaren Indizes mittels Callback-Funktionen auf den ADT anwendbar zu machen. Eine komplett neue Indexstruktur lässt sich so allerdings nicht einbauen. Außerdem wird bei einer Anfrage nicht die Selektionsbedingung des WHERE-Teiles mit übergeben. Das bedeutet, dass immer der komplette Tabelleninhalt zurückgeliefert werden muss und die Datenbank die Bedingungen des WHERE-Teiles schließlich selbst auswertet.
Um nun diese Einschränkungen zu umgehen, wurden tiefergreifende Möglichkeiten geschaffen, auch eigene Indizes in Datenbanksysteme einzubringen. Allgemein wird diese Möglichkeit auch als "Extensible Indexing" bezeichnet. Oracle setzt dies im Datacartridge Framework [5], IBM DB2 mit dem DB2 Extender [19] um. Weitere Ausführungen zu u. a. Informix DataBlades [20] und GiST [10] sind auch in [1] sowie auf allgemeinerem Niveau in [13] zu finden. Beide Verfahren -Plugins und ADTs -haben einen gemeinsamen Schwachpunkt: sie müssen immer in die Datenbank selbst integriert werden. Ein solcher Eingriff, in die u. U. für ein Unternehmen kritischen Datenbestände ist, schon allein aufgrund von Sicherheitsbedenken, schwierig bis unmöglich umzusetzen. Bei einer komplett neuen Datenbank, die erst ihren Regelbetrieb aufnehmen muss, ist dieser Weg jedoch gangbar.
Einen anderen Weg geht das GreenSQL-Projekt. Ziel von GreenSQL ist es, eine Datenbank vor schädlichen SQL-Befehlen zu schützen. Dabei nutzt es auch einen Proxyansatz. Die GreenSQL kennt dabei die folgenden Betriebsmodi:
• Simulationsmodus: Es findet hierbei kein Eingriff in die Kommunikation statt. Es werden ausschließlich alle Anfragen untersucht und bei verdächtigen Anfragen ein Verantwortlicher informiert.
• Blockierung von verdächtigen Anfragen: Hier werden Heuristiken angewandt, um die eingehenden Anfragen zu beurteilen. Wird eine Anfrage als "verdächtig" eingestuft, so wird noch in einer Positivliste nachgeschaut, ob die Anfrage doch zulässig ist. Ist sie zulässig, so wird sie an den Datenbankserver weitergeleitet, ansonsten wird direkt ein leeres Ergebnis zurückgeliefert.
• Lernmodus: Um nicht auf die Heuristiken angewiesen zu sein, kann GreenSQL in diesem Modus eine Liste zugelassener Anfragen erzeugen.
• Schutz vor unbekannten Anfragen: Nachdem alle zugelassenen Anfragen "gelernt" wurden, werden in diesem Modus alle unbekannten Anfragen blockiert.
Die Anfragen werden dabei mittels Mustererkennung untersucht. Eine Anfrage wird also nicht geparst und anhand eines Syntaxbaumes untersucht, was genau bewirkt werden soll. Damit ist der Nutzen auf Anfragen beschränkt, die keine komplexe syntaktische Struktur aufweisen. Des weiteren ist GreenSQL auf MySQL zugeschnitten. Es kennt die Tabellennamen des Systemkataloges, die sich aber bei anderen Datenbanken zu denen von MySQL unterscheiden.
Da weder die Datenbank noch die Anwendung angepasst werden dürfen, muss also eine externe Lösung angestrebt werden. In Abbildung 2(a) ist nocheinmal das Ausgangszenario dargestellt. Im weiteren werden wir uns auf SQL [6] als Kommunikationssprache hin zur Datenbank beschränken. Diese Einschränkung ist insofern unkritisch, da die meisten Datenbanksysteme auf diese Art angesprochen werden und sich der folgende Ansatz auch auf andere Anfragemöglichkeiten übertragen lässt.
Der einzig verbleibende Punkt, um noch etwas zu integrieren, ist die Kopplung zwischen Anwendung und Datenbank, Es gibt mehrere Möglichkeiten, einen Proxy in eine bestehende Systemlandschaft zu integrieren:
• Nicht-transparente Integration, indem der Anwendung der Proxy als neuer Datenbankserver mitgeteilt wird. Im Idealfall ist dies nur ein einziger Eintrag in der Anwendung.
• Ersetzen des Datenbankservers durch den Proxy. Hierbei übernimmt der Proxy die Adresse des Datenbankservers und der Datenbankserver bekommt eine neue Adresse zugeteilt.
Das beschriebene Verfahren befindet sich noch in Entwicklung. Von den vorgestellten Komponenten wurde der SQL-Parser umgesetzt. Ein weiterer Punkt, das Verändern von SQL-Anfragen, stellt eine Herausforderung dar, da die Übertragungswege von und zu den Datenbanken herstellerabhängig sind. Erste Tests zeigten Prüfsummen, die sich allerdings nur auf die Länge der Anfrage bezogen. Eine Veränderung wurde erfolgreich vorgenommen. Dieser Punkt ist allerdings ein weites Feld und wir werden uns zunächst auf eine Schnittstelle festlegen, im speziellen auf das Oracle Call Interface (OCI) [16].
Auch muss die Leistungsfähigkeit der beschriebenen Veränderungsverfahren noch untersucht werden. Anfängliche Tests mit manueller Erweiterung der Anfragen zeigten bereits Geschwindigkeitssteigerungen.
Der entwickelte Proxy kann prinzipiell nicht nur einen datenbankexternen Index ermöglichen. Er erlaubt auch eine Fülle anderer Funktionen. So kann er dazu genutzt werden, Antworten auf Anfragen an die Datenbank zwischenzuspeichern, er kann Adapterfunktionen zu anderen SQL-Dialekten oder zu ganz anderen Anfrageparadigmen sein. Diese stehen nicht im direkten Fokus der Arbeit, sollen aber definitiv evaluiert werden.