Nutzung von Proxys zur Ergänzung von Datenbankfunktionen Alexander Adam Sebastian Leuoth Wolfgang Benn Technische Universität Technische Universität Technische Universität Chemnitz Chemnitz Chemnitz Straße der Nationen 62 Straße der Nationen 62 Straße der Nationen 62 09107 Chemnitz 09107 Chemnitz 09107 Chemnitz alad@cs.tu-chemnitz.de lese@cs.tu-chemnitz.de benn@cs.tu-chemnitz.de ZUSAMMENFASSUNG oder dessen Pendant bei IBM, des DB2 Spatial Extenders In dieser Arbeit präsentieren wir eine Möglichkeit, Funk- [12]. Beide bauen einen neuen Index – einen R-Baum [9] bei tionalitäten – in diesem Fall primär Indizes – in eine Da- Oracle, ein Grid bei DB2 [2] – ein. tenbank einzubringen. Dies geschieht in einer Weise, dass weder die Datenbank noch eine Anwendung, welche die Da- All das führt dazu, dass heutige relationale Datenbanken für tenbank nutzt, etwas davon bemerken soll. Auf diese Weise sehr viele Bereiche Lösungen in Form von Indizes bereits soll die aufwendige Anpassung der Anwendungen an eine zur Verfügung stellen. Allerdings gibt es auch Anwendungs- zusätzliche Komponente vermieden werden. Zugleich wird gebiete – jene, die nicht genügend Nachfrage bieten können auch verhindert, dass die Datenbank durch das Einbringen – bei denen diese Standardlösungen nicht anwendbar sind. neuer Funktionalitäten instabiler wird. Der Anwender steht dann vor der Wahl, eine komplett eigene Datenbanklösung zu erstellen oder aber eine bestehende Da- tenbank zu erweitern. Eine Eigenentwicklung kommt dabei Keywords für die wenigsten in Frage, da diese immens zeit- und damit Datenbankerweiterung, Indizierung, Proxy kostenintensiv ist. Sie muss darüberhinaus auch selbst wei- terentwickelt und mit Aktualisierungen versorgt werden, ein 1. EINLEITUNG weiterer sehr kostenintensiver Punkt, der gegen eine solche Datenbanken sind allgegenwärtig und nicht mehr aus dem Entwicklung spricht. täglichen Leben wegzudenken. Sie verwalten von vertrauli- chen Personendaten bis hin zum Zahlungsverkehr von Ban- Bei der zweiten Möglichkeit – der Erweiterung eines Daten- ken sehr viele Bereiche der Gesellschaft. Daraus ergeben banksystems – wird über vom Datenbankhersteller bereit- sich einige Anforderungen, denen Datenbanksysteme gerecht gestellte Schnittstellen die Funktionalität einer bestehenden werden müssen. So kann erwartet werden, dass Zugangs- Datenbank um die geforderten Eigenschaften erweitert. Es richtlinien eingehalten und die Daten sicher – d. h. vor frem- ist schwierig, diese Erweiterungen dauerhaft in Datenbanken dem Zugriff und Verlust – verwahrt werden. zu integrieren. Zum einen haben die Datenbankhersteller ein berechtigtes Interesse daran, nur gut getestete Komponen- Datenbanken, wie wir sie heute kennen, haben sich dabei ten in ihre Produkte einfließen zu lassen, zum anderen müs- über viele Jahre hinweg entwickelt. Angefangen von den sen diese weitestgehend allgemein einsetzbar sein. ersten Systemen, wie z. B. System R [4] und IMS [8], bis zu den heutigen großen relationalen Datenbanksystemen – In einigen Umgebungen ist es allerdings nicht möglich, Ein- bspw. Oracle [14] und IBM DB2 [3], um nur einige zu nennen griffe in die Datenbank oder die Anwendungen, die auf sie – wurden immer wieder neue Funktionalitäten hinzugefügt. Zugriff nehmen, vorzunehmen. Ein Szenario ist hier der Be- Entwicklungen an Datenbanksystemen finden dabei meist trieb eines Rechenzentrums, welches Datenbankdienstleis- direkt bei den Datenbankherstellern statt. Diese integrie- tungen zur Verfügung stellt. Hier können weder Eingriffe ren neue Techniken in ihre Datenbanken, wenn diese ausrei- in die Datenbanken vorgenommen werden, noch ist dies bei chend getestet, ausgereift und für eine breite Öffentlichkeit den Anwendungen möglich, da diese den Kunden gehören. nutzbar und nützlich sind. Selbst einige Spezialgebiete wur- den bereits abgedeckt, so z. B. die Speicherung und schnelle Aus diesem Grund wollen wir einen Weg schaffen, der sich in Abfrage von räumlichen Daten mittels Oracle Spacial [17] eben diesen Situationen einsetzen lässt und der dann auch für andere offensteht. Es soll dabei möglichst erreicht wer- den, dass das Zusatzmodul, ein Proxy, komplett transparent in die bestehende Infrastruktur integriert werden kann. Im nächsten Abschnitt werden wir zunächst auf andere Tech- niken eingehen, die genutzt werden können, neue Funktio- nalitäten, speziell Indizes, in Datenbanken einzufügen. An- schließend werden wir unser Konzept aufzeigen und einige Spezialfälle diskutieren. 2. STAND DER TECHNIK an dieser Stelle auch alle Funktionen, die angepasst werden, und deren Seiteneffekte beachtet werden. 2.1 ADT Klassischerweise können neue Funktionalitäten in Daten- Beide Verfahren – Plugins und ADTs – haben einen gemein- banksysteme mittels Stored Procedures und eigenen abstrak- samen Schwachpunkt: sie müssen immer in die Datenbank ten Datentypen (ADT) implementiert werden. Die meisten selbst integriert werden. Ein solcher Eingriff, in die u. U. für Datenbanksysteme bieten diese Möglichkeiten. [11, 15, 18] ein Unternehmen kritischen Datenbestände ist, schon allein Diese Erweiterungsmöglichkeiten sind jedoch begrenzt, da aufgrund von Sicherheitsbedenken, schwierig bis unmöglich mit ihnen immer die Ablage der Daten in den vorgegebe- umzusetzen. Bei einer komplett neuen Datenbank, die erst nen Strukturen der Datenbank einhergeht. Auch lassen sich ihren Regelbetrieb aufnehmen muss, ist dieser Weg jedoch so die internen Abläufe nur schwer beeinflussen. Postgres gangbar. bietet beispielsweise die Möglichkeit die verfügbaren Indi- zes mittels Callback-Funktionen auf den ADT anwendbar zu machen. Eine komplett neue Indexstruktur lässt sich so 2.3 GreenSQL allerdings nicht einbauen. Außerdem wird bei einer Anfrage Einen anderen Weg geht das GreenSQL-Projekt. Ziel von nicht die Selektionsbedingung des WHERE-Teiles mit überge- GreenSQL ist es, eine Datenbank vor schädlichen SQL-Be- ben. Das bedeutet, dass immer der komplette Tabelleninhalt fehlen zu schützen. Dabei nutzt es auch einen Proxyansatz. zurückgeliefert werden muss und die Datenbank die Bedin- Die GreenSQL kennt dabei die folgenden Betriebsmodi: gungen des WHERE-Teiles schließlich selbst auswertet. • Simulationsmodus: Es findet hierbei kein Eingriff in 2.2 Plugins die Kommunikation statt. Es werden ausschließlich alle Um nun diese Einschränkungen zu umgehen, wurden tiefer- Anfragen untersucht und bei verdächtigen Anfragen greifende Möglichkeiten geschaffen, auch eigene Indizes in ein Verantwortlicher informiert. Datenbanksysteme einzubringen. Allgemein wird diese Mög- lichkeit auch als „Extensible Indexing“ bezeichnet. Oracle • Blockierung von verdächtigen Anfragen: Hier werden setzt dies im Datacartridge Framework [5], IBM DB2 mit Heuristiken angewandt, um die eingehenden Anfragen dem DB2 Extender [19] um. Weitere Ausführungen zu u. a. zu beurteilen. Wird eine Anfrage als „verdächtig“ ein- Informix DataBlades [20] und GiST [10] sind auch in [1] gestuft, so wird noch in einer Positivliste nachgeschaut, sowie auf allgemeinerem Niveau in [13] zu finden. 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. Datenbankerweiterung außerhalb der Datenbank komplett eigene • Lernmodus: Um nicht auf die Heuristiken angewiesen Datenverwaltung zu sein, kann GreenSQL in diesem Modus eine Liste Pluginschnittstelle zugelassener Anfragen erzeugen. Bereitstellung von Zugriffsfunktionen für Erweiterungen datenbankverwalteter • Schutz vor unbekannten Anfragen: Nachdem alle zuge- lassenen Anfragen „gelernt“ wurden, werden in diesem Datenbank Server Bereich Bereitstellung von Modus alle unbekannten Anfragen blockiert. − Zugriffskontrolle − ACID − SQL Schnittstelle Die Anfragen werden dabei mittels Mustererkennung un- tersucht. 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 kei- Abbildung 1: Mittels eines Datenbankplugins wie ne komplexe syntaktische Struktur aufweisen. Des weiteren hier dargestellt lassen sich neue Funktionen in ei- ist GreenSQL auf MySQL zugeschnitten. Es kennt die Ta- ne Datenbank integrieren, insbesondere Indizes (vgl. bellennamen des Systemkataloges, die sich aber bei anderen [5]). Datenbanken zu denen von MySQL unterscheiden. Diese Pluginschnittstellen ermöglichen es, komplett neben 3. UNSER ANSATZ der Datenbank Indexfunktionalitäten bereitzustellen und die 3.1 Allgemein Datenbank so auf eine reine Verwaltungskomponente zu re- Da weder die Datenbank noch die Anwendung angepasst duzieren. Die Datenbank macht weiterhin die Zugriffskon- werden dürfen, muss also eine externe Lösung angestrebt trolle, SQL-Auswertung, Transaktionen, gibt dann die ei- werden. In Abbildung 2(a) ist nocheinmal das Ausgangsze- gentliche Ausführung aber an das Plugin ab. Dieses kann nario dargestellt. Im weiteren werden wir uns auf SQL [6] als z. B. speziell strukturierte Daten sehr effizient außerhalb der Kommunikationssprache hin zur Datenbank beschränken. Datenbank vorhalten. Diese Einschränkung ist insofern unkritisch, da die meisten Datenbanksysteme auf diese Art angesprochen werden und Neben konkreten Pluginschnittstellen, steht bei Opensource- sich der folgende Ansatz auch auf andere Anfragemöglich- Projekten auch der Weg des direkten Eingriffes in den Da- keiten übertragen lässt. tenbankkern offen. Da sich interne Strukturen bei solchen Projekten allerdings häufig ändern, ist hier der Wartung- Der einzig verbleibende Punkt, um noch etwas zu integrie- aufwand für eine solche Lösung enorm. Des weiteren müssen ren, ist die Kopplung zwischen Anwendung und Datenbank, SQL Anwendung Datenbank Anwendung Datenbank Antwort (a) Datenbankhersteller−spezifische Kopplungskomponente SQL SQL Anwendung Proxy Datenbank Verwaltungskomponente Antwort Antwort (b) SQL−Parser Indizierungskomponente Abbildung 2: Integrationsszenario. In Teil (a) ist dargestellt, wie sich der bisherige Ablauf bei der Kommunikation von Anwendung und Datenbank darstellt. Teil (b) zeigt, wie sich der Proxy einfügt und die Kommunikation auf ihn umgeleitet wird. Abbildung 3: Interner Aufbau des Proxys. Der Proxy besteht im Wesentlichen aus einem SQL- sprich die Kommunikationsstrecke. Abbildung 2(b) zeigt, Parser, dem eigentlichen Index und einer Verwal- wie ein solcher Eingriff aussehen könnte. Ein Proxy nimmt tungskomponente, die diese Komponenten mitein- den Datenverkehr von der Anwendung entgegen und wertet ander koppelt. Um die Datenbankanfragen einzule- diesen aus. Er miemt also die Datenbank. Zur Beantwortung sen, wird noch eine Datenbankhersteller-spezifische der Anfrage kann der Proxy trotzdem mit der Datenbank Schnittstelle benötigt. kommunizieren. Anschließend wird geprüft, ob der Proxy überhaupt etwas Es gibt mehrere Möglichkeiten, einen Proxy in eine beste- mit dieser Anfrage anfangen kann. Im Falle eines Index wer- hende Systemlandschaft zu integrieren: den also die Tabellen, auf die sich die Anfrage bezieht, mit den indizierten Tabellen verglichen. Wenn keine indizierte • Nicht-transparente Integration, indem der Anwendung Tabelle getroffen wurde, so wird die Anfrage unbehandelt der Proxy als neuer Datenbankserver mitgeteilt wird. an die Datenbank weitergereicht, von dieser beantwortet und Im Idealfall ist dies nur ein einziger Eintrag in der An- das Ergebnis an die Anwendung zurückgeliefert. wendung. Wird die Anfrage bearbeitet, so muss der SQL-Parser diese • Ersetzen des Datenbankservers durch den Proxy. Hier- zuerst in Unteranfragen zerlegen. Abbildung 4 zeigt eine sol- bei übernimmt der Proxy die Adresse des Datenbank- che zerlegte Anfrage, die eine Unteranfrage beinhaltet. Bei servers und der Datenbankserver bekommt eine neue der Beantwortung muss der Baum, der sich aus dieser Struk- Adresse zugeteilt. tur ergibt, von den Blättern her zur Wurzel hin abgearbei- tet werden. Es muss also zunächst die Anfrage „SELECT mid • Transparentes Einklinken des Proxys. Dabei werden FROM abt WHERE nr = 3“ abgearbeitet werden. Die Ergeb- auf Netzwerkebene die Datenpakete, die für den Da- nisse dieser Teilanfrage werden dann in den darüberliegen- tenbankserver bestimmt sind, auf den Proxy umge- den Knoten eingebaut. Sobald alle Kindknoten eines Kno- leitet (Destination Network Address Translation) [7]. tens abgearbeitet wurden, kann der Knoten selbst bearbeitet Diese Variante ist vom Anpassungsaufwand für die An- werden. wendung als auch für den Datenbankserver am gerings- ten (im Idealfall Null). Dabei ist jedoch zu beachten, 0 SELECT * FROM mitarb WHERE mitarb.id IN ( 1 ) dass es sich hierbei um einen Eingriff in eventuell ver- trauliche Kommunikation handelt. 1 SELECT mid FROM abt WHERE abt.nr = 3 Ziel soll es sein, die letzte Möglichkeit zu realisieren. Bei ei- Abbildung 4: Anfragebaum für eine kleine geschach- ner Neuinstallation ist ein neues Indizierungsverfahren, egal telte SQL-Anfrage. Anfrage 1 ist in Anfrage 0 ein- ob Datenbank intern oder extern, verhältnismäßig einfach zu gebettet, ihre Ergebnisse sind für die Beantwortung integrieren. Die Integration in bestehende Systemlandschaf- von Anfrage 0 entscheidend. ten aber gestaltet sich schwierig. Eine transparente Lösung ist hier die einzig anwendbare. In eine Anfrage, die Daten aus Unteranfragen benötigt, wer- 3.2 Bearbeitung einer Anfrage den die Ergebnisse dieser Unteranfrage zunächst direkt ein- Egal für welche Integrationsvariante sich entschieden wur- gesetzt. Im vorigen Beispiel würde also bspw. eine Anfra- de, im Betrieb sind die Aufgaben der Kernkomponenten des ge wie „SELECT * FROM mitarb WHERE id IN (17,23,42)“ Proxys gleich. Diese Kernkomponenten und ihr Zusammen- erzeugt werden. spiel sind in Abbildung 3 dargestellt. Sendet die Anwendung eine Anfrage an die Datenbank, wird diese zunächst von der Im Falle eines Index ist es nicht sinnvoll, jeden Zweig im An- Verwaltungskomponente des Proxys entgegengenommen. fragebaum zu verfolgen. Es müssen nur Blätter ausgewertet werden, die auch tatsächlich an einem für den Index aus- eine um den Primärschlüssel id erweiterte Anfrage werden: wertbaren Vaterknoten direkt oder indirekt angeschlossen sind. SELECT * FROM mitarb WHERE gehalt > 2000 AND id IN (4, 18) Bei der Auswertung eines Anfragebaumes ergibt sich das in Abbildung 5 dargestellte Kommunikationsschema. Es ist zu erkennen, dass während der Beantwortung einer Anfrage Problematisch an dieser Lösung kann die begrenzte Länge u. U. mehrere Anfragen an die Datenbank abgeschickt wer- von SQL-Ausdrücken sein, die eine Datenbank verarbeiten den müssen, während die Anwendung auf die Antwort war- kann. Für den Fall einer Überschreitung dieser Maximallän- tet. Dieses Wechselspiel von Proxy und Datenbank kann bei ge muss ein anderer Weg gegangen werden. So können die entsprechend tief geschachtelten Anfragen sehr lange dau- Ergebnisse, die der Index zurückliefert, in der Datenbank in ern. Es muss noch untersucht werden, bis zu welcher Tiefe eine seperate, temporäre Tabelle eingefügt werden. Die neue sich die Ausführung der Auflösung tatsächlich lohnt und ab SQL-Anfrage hätte dann die Form: wann die gesamte Anfrage direkt an die Datenbank weiter- geleitet werden sollte. SELECT * FROM mitarb WHERE gehalt > 2000 AND id IN (SELECT * FROM temp_tabelle) Anwendung Proxy Datenbank Anfrage 4. AUSBLICK Das beschriebene Verfahren befindet sich noch in Entwick- Verarbeitung lung. Von den vorgestellten Komponenten wurde der SQL- Anfrage Parser umgesetzt. Ein weiterer Punkt, das Verändern von Verarbeitung SQL-Anfragen, stellt eine Herausforderung dar, da die Über- Antwort tragungswege von und zu den Datenbanken herstellerab- Verarbeitung hängig sind. Erste Tests zeigten Prüfsummen, die sich al- Anfrage lerdings nur auf die Länge der Anfrage bezogen. Eine Ver- änderung wurde erfolgreich vorgenommen. Dieser Punkt ist Verarbeitung Antwort allerdings ein weites Feld und wir werden uns zunächst auf eine Schnittstelle festlegen, im speziellen auf das Oracle Call Verarbeitung Antwort Interface (OCI) [16]. Auch muss die Leistungsfähigkeit der beschriebenen Verän- derungsverfahren noch untersucht werden. Anfängliche Tests Idle Warten Arbeiten mit manueller Erweiterung der Anfragen zeigten bereits Ge- schwindigkeitssteigerungen. Abbildung 5: Kommunikationsschema. Die Abbil- Der entwickelte Proxy kann prinzipiell nicht nur einen da- dung zeigt das Kommunikationsverhalten der ein- tenbankexternen Index ermöglichen. Er erlaubt auch eine zelnen Teilnehmer. Zu bemerken ist, dass nicht jede Fülle anderer Funktionen. So kann er dazu genutzt wer- Anfrage der Anwendung auch nur eine Anfrage des den, Antworten auf Anfragen an die Datenbank zwischen- Proxys bei der Datenbank bedingt, sondern auch zuspeichern, er kann Adapterfunktionen zu anderen SQL- eine Reihe solcher Anfragen an die Datenbank aus- Dialekten oder zu ganz anderen Anfrageparadigmen sein. lösen kann. Diese stehen nicht im direkten Fokus der Arbeit, sollen aber definitiv evaluiert werden. Ein Index muss nicht die Daten selbst, sondern nur Identifi- 5. LITERATUR katoren speichern, die einzelne Datensätze eindeutig identi- [1] R. Acker, R. Pieringer, and R. Bayer. Towards Truly fizieren. Sein Ergebnis sind also idealerweise Primärschlüs- Extensible Database Systems. In K. Andersen, sel der eigentlichen Tupel in der Datenbank. Werden einer J. Debenham, and R. Wagner, editors, DEXA 2005, Datenbank die Tupelidentifikatoren (TIDs) der gesuchten pages 596–605. Springer-Verlag Berlin Heidelberg, Datensätze mitgeteilt, kann diese sie sehr schnell finden. Es 2005. kann allerdings vorkommen, dass die von einem Index zu- [2] D. W. Adler. DB2 Spatial Extender - Spatial data rückgelieferten Ergebnisse unscharf, es also zu viele sind. within the RDBMS. In VLDB ’01: Proceedings of the Deshalb müssen alle WHERE-Bedingungen der originalen An- 27th International Conference on Very Large Data frage erhalten bleiben. Bases, pages 687–690, San Francisco, CA, USA, 2001. Morgan Kaufmann Publishers Inc. Eine Möglichkeit der Datenbank, die Ergebnisse eines Index [3] R. Ahuja. DB2 9 Unveiled: Overview and New mitzuteilen, ist die Erweiterung der ursprünglichen Anfra- Enhancements. IBM Software Group, July 2006. ge um seine Ergebnisse. Zum Beispiel kann so aus einem [4] M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin, einfachen K. P. Eswaran, J. N. Gray, P. P. Griffiths, W. F. King, R. A. Lorie, P. R. McJones, J. W. Mehl, G. R. Putzolu, I. L. Traiger, B. W. Wade, and V. Watson. SELECT * FROM mitarb WHERE gehalt > 2000 System R: relational approach to database management. ACM Trans. Database Syst., 1(2):97–137, 1976. [5] E. Belden, T. Chorma, D. Das, Y. Hu, S. Kotsovolos, G. Lee, R. Leyderman, S. Mavris, V. Moore, M. Morsi, C. Murray, D. Raphaely, H. Slattery, S. Sundara, and A. Yoaz. Oracle Database Data Cartridge Developers Guide, 11g Release 2 (11.2). Oracle, July 2009. [6] D. D. Chamberlin and R. F. Boyce. SEQUEL: A structured English query language. In SIGFIDET ’74: Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control, pages 249–264, New York, NY, USA, 1974. ACM. [7] K. B. Egevang and P. Francis. RFC 1631 – The IP Network Address Translator (NAT). Cray Communications, NTT Software Lab, May 1994. [8] R. L. Gilliam. The State of IMS. IBM Corporation, Department DQZA, Route 100 Box 100, Sommers NY, USA, 06877, Apr. 2005. [9] A. Guttman. R-trees: a dynamic index structure for spatial searching. In SIGMOD ’84: Proceedings of the 1984 ACM SIGMOD international conference on Management of data, pages 47–57, New York, NY, USA, 1984. ACM. [10] J. M. Hellerstein, J. F. Naughton, and A. Pfeffer. Generalized Search Trees for Database Systems. In VLDB ’95: Proceedings of the 21th International Conference on Very Large Data Bases, pages 562–573, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc. [11] IBM. SQL Reference, Volume 1. IBM Corporation, Nov. 2009. [12] IBM Deutschland GmbH. DB2 Spatial Extender und Geodetic Data Management Feature – Benutzer- und Referenzhandbuch, July 2006. [13] H.-P. Kriegel, M. Pfeifle, M. Pötke, and T. Seidl. The Paradigm of Relational Indexing: A Survey. In Proceedings of the 10th Conference on Database Systems for Business, Technology, and the Web (BTW’03), GI-Edition Lecture Notes in Informatics, pages 285–304, Leipzig, Deutschland, 2003. [14] K. Loney. Oracle Database 11g The Complete Reference. McGraw-Hill, Inc., New York, NY, USA, 2009. [15] D. Lorentz and M. B. Roeser. Oracle Database SQL Language Reference, 11g Release 2 (11.2). Oracle, Oct. 2009. [16] J. Melnick. Oracle Call Interface Programmer’s Guide, 11g Release 2 (11.2). Oracle, Oct. 2009. [17] C. Murray. Oracle Spatial Developers Guide, 11g Release 2 (11.2). Oracle, Dec. 2009. [18] The PostgresSQL Global Development Group. PostgreSQL 8.4.3 Documentation, 2009. [19] K. Stolze and T. Steinbach. DB2 Index Extensions by example and in detail, IBM Developer works DB2 library. Dec. 2003. [20] M. Ubell. The Montage extensible DataBlade architecture. SIGMOD Rec., 23(2):482, 1994.