Query Rewriting in NoSQL-Datenbanksystemen - fbi.h
Werbung
Query Rewriting in NoSQLDatenbanksystemen Julian Stenzel Einleitung Der Begriff NoSQL (Not only SQL) bezeichnet eine aufstrebende Datenbanktechnologie, welche nicht den relationalen Ansatz verfolgt, bei dem die Daten üblicherweise in der von relationalen Datenbanken bekannten Form modelliert und gespeichert werden. Datenbanken dieser Form existieren bereits seit einer längeren Zeitspanne, wurden jedoch erst seit einigen Jahren durch das Aufkommen von Big Data und Web 2.0 unter dem Sammelbegriff NoSQL bekannt. Ein großer Vorteil von NoSQL-Datenbanksystemen besteht in der Schemafreiheit. Liegen Daten nicht in der entsprechenden Struktur vor, ist es üblich, dass ein Datenbankmanagementsystem diese bei der Speicherung zurückweist. Eine schemafreie Datenbank ist dagegen in der Lage, auch schwächer oder unstrukturierte Daten abzuspeichern. Dieser Mechanismus spielt seine Vorteile besonders in agilen Projekten aus, die von Natur aus einer hohen Änderungsrate unterliegen. Eine fehlende Kontrolle der Struktur der Daten führt in der Praxis jedoch zu Problemen. Motivation Mit dem Ansatz des Schema-Managements existiert eine Methodik, um den Problemen entgegenzuwirken. Dabei steht das Schema-Management für die Kontrolle der kontinuierlichen Änderungen an einem Schema der Datenbank, die während der Entwicklung und im Betrieb eines Softwaresystems auftreten. Trotz einer konsequenten Kontrolle durch das Schema-Management existieren in der Praxis jedoch weiterhin Daten in unterschiedlichen Schemaversionen. Will man diese durch eine beliebige Abfragesprache beziehen, stoßen wir auf zwei Probleme. Zum einen passen historisch gestellte Abfragen nicht mehr auf die Daten der sich stetig weiterentwickelnden Schemas. Zum anderen muss eine gestellte Abfrage, welche sich gegen eine einzelne Schemaversion richtet, so erweitert werden, dass sie auf alle korrespondierenden Schemaversionen passt. Abbildung 1 Beispiel einer umgeschriebenen Abfrage anhand dreier Schemaversionen Gegenstand dieser Arbeit ist die Definition der Grundlagen und die Motivation von Query Rewriting. Es werden Konzepte für die Integration des Rewriting im Schema-Management erarbeitet, evaluiert und diese anhand eines Prototyps in eine vorliegende Schema-Management-Komponente namens Darwin implementiert. Die Query kann sich dabei auf mehrere Schemaversionen beziehen, wobei wir beispielsweise die jüngste Version wählen. Die SMO HandlerKomponente überprüft ob es zu der gefundenen Schemaversion Vorgänger- und Nachfolgeschemas gibt. Würden zu Person wie im Beispiel gezeigt drei Schemaversionen vorliegen und unsere Anwendung eine Abfrage gegen Version 2 stellen, so würde unsere Query-ParserKonzept Komponente ein Matching zu Version 1 und zu Version 3 erkennen. Aus dem Matching zwischen den verschiedenen gefundenen Vorgänger- und In Abbildung 2 ist die Grundarchitektur des in der Nachfolgeversionen erstellt die Komponente eine Arbeit erstellten Konzeptes zu sehen. An der Spit- Tabelle, welche alle Matchings enthält. ze unserer Architektur steht der Nutzer, der über eine Anwendung, welche über eine API mit unse- Die Query-Rewriting-Komponente nutzt die erstellrer Schema-Management-Komponente kommuni- te Tabelle, um die von dem Nutzer gestellte Abziert, verbunden ist und über diese Datenbankab- frage mit der Hilfe eines Algorithmus (genannt fragen gegen ein NoSQL-Datenbanksystem stel- Chase & Backchase (C&B)) umzuschreiben. Die len kann. Diese Abfragen gilt es nun auf eine nun umgeschriebene Abfrage wird auf die vermögliche Anwendung des Query Rewriting zu schiedenen Datenquellen angewandt und das Ergebnis an den Nutzer bzw. an die Anwendung untersuchen. geleitet. Basierend auf erstellten Statistiken soll der Query-Rewriting-Prozess dauerhaft überwacht werden können. Das Konzept wurde als Prototyp in die Schema-Management-Komponente Darwin implementiert. Ergebnis In Abbildung 1 ist ein passendes Beispiel zu sehen. Dabei liegt ein Objekt Person in drei unterschiedlichen Schemaversionen vor, welche sich jeweils in ihrer Struktur unterscheiden. Eine potentielle Abfrage gegen Schemaversion 2 (in der Abbildung fett gedruckt), muss jeweils so erweitert werden, dass sie zusätzlich auf die Schemaversionen 1 und 2 passt. Der Vorgang, der sich um die automatisierte Anpassung der Abfragen bezüglich der verwalteten Abbildung 2 Grundarchitektur Query Rewriting Schemaversionen kümmert, wird im Kontext des Schema-Managements Query Rewriting genannt. Zunächst wird die Abfrage in der Query ParserKomponente geparsed. Gleichzeitig wird überprüft auf welche Schemaversion sich die Abfrage bezieht (im vorangegangenen Beispiel wäre das die Schemaversion 2). Kontakt Julian Stenzel Fachbereich Informatik Schöfferstraße 8b, 64295 Darmstadt E-Mail: [email protected] Es zeigt sich, dass das Query Rewriting eine wichtige Komponente des Schema-Managements darstellt und sich das entwickelte Konzept in dieses integrieren lässt. Im Zuge verschiedener Migrationsstrategien spielt das Query Rewriting eine entscheidende Rolle und dient als Grundlage für eine effiziente Lazy Migration. In gewissen Szenarien kann das Query Rewriting eine Migration sogar teilweise ersetzen. In den nächsten Arbeiten sollten weitere Tests an der Komponente durchgeführt und diese weiter verbessert und stabilisiert werden. Des Weiteren müssen verschiedene Kostenmodelle entwickelt werden auf Grundlage dessen Performancemessungen durchgeführt werden können. Die Messungen helfen je nach Einzelfall dabei, eine geeignete Migrationsstrategie auszuwählen. Referentin Prof. Dr. Uta Störl Korreferentin Prof. Dr. Inge Schestag
